Поды и контроллеры Kubernetes

Взаимозаменяемые и именованные

Развёртывание рассчитано на одинаковые взаимозаменяемые экземпляры. Имена случайны, порядок запуска не гарантирован, поды поднимаются все разом. Это подходит приложениям без собственного состояния: любой экземпляр обслужит любой запрос.

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

// Нужно это ровно там, где экземпляры НЕ взаимозаменяемы: базы с репликацией, очереди, кластеры с выбором главного. Для обычного веб-сервиса набор с состоянием - лишняя сложность: он медленнее обновляется и болезненнее переживает падение узла.

развёртывание

одинаковые взаимозаменяемые поды со случайными именами

набор с состоянием

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

По одному на узел и разовые задачи

Набор по узлам ставит ровно один под на каждый узел кластера и сам добавляет его на новые узлы. Это форма для инфраструктурных вещей: сборщик логов, агент мониторинга, сетевой компонент. Число реплик тут не задают - оно равно числу узлов по определению.

Разовая задача запускает под и следит, чтобы он ДОШЁЛ ДО КОНЦА успешно. Отличие от развёртывания принципиальное: там под, завершившийся с нулевым кодом, будет перезапущен, потому что желаемое состояние - «работает». В разовой задаче успешное завершение и есть цель. Ей задают число попыток при неудаче и предел времени.

// Задача по расписанию - та же разовая, но запускаемая по календарю. Две настройки, которые спасают от боли: политика на случай, когда предыдущий запуск ещё идёт (пропустить, запустить рядом или заменить), и предел времени выполнения. Без них повторяется классика планировщика: задача накладывается сама на себя, пока не кончатся ресурсы.

набор по узлам

ровно один под на каждом узле; для агентов и сборщиков

разовая задача

под должен успешно завершиться; завершение - это цель, а не сбой

Обновление и откат

При обновлении развёртывание не гасит всё разом. Оно создаёт новый набор реплик и переводит поды по чуть-чуть. Две настройки задают темп: сколько подов можно поднять СВЕРХ нормы и сколько можно держать недоступными. По умолчанию у меня стояло по 25% на обе.

Замерил, как это выглядит на четырёх репликах. Через 2 секунды после команды: готово 3 из 4, актуальной версии 2, доступно 3. Через 8 секунд: актуальных уже 4, доступно 3. Через 10 секунд: 4 из 4 готовы, все актуальные. Доступность ни разу не опустилась ниже трёх из четырёх - именно это и обещают настройки.

// Откат работает потому, что старый набор реплик не удаляется, а остаётся с нулём подов. Команда отката просто наполняет его обратно. История версий хранится, у меня после одного обновления в ней было две записи. ⚠Но обещание «без простоя» держится только при работающей пробе готовности - это регулярный запрос, по ответу на который кластер решает, можно ли пускать на под трафик. Без неё кластер считает под готовым сразу после старта процесса и переводит на него трафик раньше, чем приложение способно отвечать.

максимум сверх нормы

сколько подов разрешено поднять поверх заданного числа во время обновления

максимум недоступных

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

Как отвечать: «Чем StatefulSet отличается от Deployment и когда он нужен?»

Тремя вещами, и все три я проверял на стенде. Стабильные имена: у развёртывания поды получили случайные хвосты, а у набора с состоянием - номера, ноль и один. Устойчивость этих имён: я удалил нулевой под, и вернулся под ровно с тем же именем, тогда как у развёртывания взамен удалённого пришёл под с новым именем. Плюс личный том, который переживает пересоздание и подключается обратно к экземпляру с тем же номером, и строгий порядок запуска и остановки. Нужно это там, где экземпляры не взаимозаменяемы: базы с репликацией, очереди, кластеры с выбором главного узла. Для обычного веб-сервиса это лишняя сложность - обновляется медленнее и хуже переживает падение узла, а взамен даёт свойства, которые сервису без состояния не нужны.

Ответ называет ровно три отличия с проверенными примерами и заканчивается тем, когда этого делать НЕ надо. Второе не менее важно: набор с состоянием часто ставят по привычке.

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

• −Берут набор с состоянием для сервиса без состояния и получают медленное обновление.
• −Ждут от развёртывания стабильных имён подов.
• −Запускают разовые задачи развёртыванием: завершившийся под будет перезапущен.
• −Не ставят задаче по расписанию предел времени и политику наложения запусков.
• −Обещают обновление без простоя, не настроив пробу готовности.