Планирование подов: requests, taints, Pending

Запрос и лимит - разные вещи

Запрос - это бронь. Планировщик складывает запросы всех подов на узле и сравнивает с ёмкостью: если новый не помещается, узел не подходит. Фактическое потребление при этом не смотрится вовсе - узел может простаивать, но если запросы уже разобраны, новый под не встанет.

Лимит - это потолок во время работы, и ведёт он себя для двух ресурсов по-разному. Я проверил оба. Под с лимитом памяти 64 мегабайта, который ест память, был убит: статус OOMKilled, код завершения 137. Под с лимитом процессора в одну десятую ядра, который считает в полную силу, продолжил работать - его просто ЗАМЕДЛИЛИ.

// Отсюда правило, которое стоит запомнить дословно: память - жёсткий предел, за его превышение убивают; процессор - мягкий, за превышение тормозят. Поэтому лимит памяти ставят обязательно и с запасом, а лимит процессора - осторожно: слишком низкий незаметно душит приложение, и в метриках это выглядит как «медленно работает», а не как отказ.

запрос

бронь ресурса; по ней планировщик решает, влезет ли под на узел

лимит

потолок во время работы: по памяти убивают, по процессору тормозят

Классы качества и выселение

По соотношению запросов и лимитов кластер сам присваивает поду класс. Проверил на трёх подах: где запрос равен лимиту по обоим ресурсам - класс Guaranteed; где запрос есть, а лимит выше - Burstable; где не указано ничего - BestEffort.

Класс определяет очередь на выселение, когда на узле кончается память. Первыми уходят поды без запросов, потом те, кто потребляет больше своего запроса, последними - те, у кого запрос равен лимиту. То есть указанные запросы - это не бюрократия, а страховка от того, что ваш под выкинут первым.

// Отсюда практика: поды без запросов и лимитов - худший вариант из возможных. Они и планируются куда попало, и вылетают первыми, и мешают соседям. Поэтому в пространствах включают пределы по умолчанию: под без явных значений получает их автоматически, а не остаётся безклассовым.

класс качества

присваивается автоматически по запросам и лимитам; задаёт очередь на выселение

выселение

кластер выгоняет поды с узла, когда на нём кончается память

Куда именно поставить под

Кроме ресурсов у планировщика есть правила размещения. Простейшее - выбор по метке узла: ставить только туда, где есть быстрый диск или нужный процессор. Более гибкое - предпочтения, когда правило желательно, но при невозможности под всё равно разместится.

Обратный механизм - пометки на узлах, которые ОТТАЛКИВАЮТ поды. Узел с такой пометкой принимает только те поды, которые явно согласны на неё. Так выделяют узлы под особые задачи и так же кластер помечает больные узлы, чтобы на них ничего не ставили.

// И самое практичное правило - разнесение. Без него все реплики одного сервиса могут оказаться на одном узле, и его падение унесёт весь сервис разом. Правило равномерного распределения по узлам или по зонам - отдельным площадкам дата-центра - решает это одной настройкой в описании. Проверять полезно не по документации, а глазами: посмотреть, на каких узлах реально стоят поды.

выбор по метке узла

жёсткое условие: ставить только на узлы с такой меткой

отталкивающая пометка

узел принимает только поды, явно согласные на неё

разнесение

правило раскладывать реплики по разным узлам или зонам

Как отвечать: «Под висит в состоянии ожидания. Что смотреть?»

Смотрю события пода - там прямым текстом написана причина. Самая частая: ни один узел не подходит по ресурсам. Я это воспроизводил: попросил 64 гигабайта и 32 ядра на узле с двумя ядрами и получил «0 из 1 узлов доступны: недостаточно процессора и памяти». Причём планировщик считает по ЗАПРОСАМ, а не по фактическому потреблению - узел может простаивать, но если запросы уже разобраны, новый под не встанет. Дальше по списку причин: правила размещения, которым не соответствует ни один узел; отталкивающие пометки на узлах, на которые под не согласен; отсутствие свободного тома нужной зоны; исчерпанная квота пространства. Все они видны в событиях, поэтому первое действие всегда одно - прочитать события, а не гадать.

Ответ начинается с источника правды, даёт главную причину с измеренным примером и перечисляет остальные. Уточнение про запросы против потребления - то, что путают чаще всего.

На чём валятся

• −Думают, что планировщик смотрит на фактическую загрузку узла. Он смотрит на сумму запросов.
• −Не ставят запросы и лимиты вовсе: такие поды вылетают первыми при нехватке памяти.
• −Ставят слишком низкий лимит процессора и получают незаметное замедление вместо отказа.
• −Считают, что превышение лимита процессора убивает под. Убивает только память.
• −Не разносят реплики по узлам и теряют весь сервис при падении одного.