Опишите желаемое состояние
Deployment управляет набором Pod на основе шаблона и желаемого количества реплик. Изменение шаблона, например версии образа, запускает обновление управляемых экземпляров. Отдельный Pod не стоит рассматривать как постоянную машину, которую необходимо вручную сохранять любой ценой. Полезнее проверить, может ли приложение корректно запускаться заново, получать настройки и завершать работу. Данные, которые должны пережить замену экземпляра, требуют отдельного решения хранения. Сначала убедитесь, что новая и прежняя версии способны временно работать рядом с совместимыми данными и зависимостями.
Различайте готовность, жизнеспособность и запуск
Readiness probe сообщает, готов ли экземпляр принимать обычный рабочий трафик. При отрицательном результате он исключается из готовых адресов обычного Service. Liveness probe служит для обнаружения состояния, при котором контейнер требуется перезапустить. Startup probe позволяет отдельно учесть длительную инициализацию: до её успешного завершения проверки liveness и readiness не выполняются. Неподходящая проверка может сама создать проблему. Например, временная недоступность внешней зависимости не всегда должна приводить к постоянному перезапуску всех контейнеров. Смысл каждого сигнала следует согласовать с поведением приложения.
Настройте ограничения постепенной замены
При RollingUpdate параметр maxUnavailable ограничивает допустимое уменьшение числа доступных реплик, а maxSurge задаёт, насколько можно увеличить число реплик сверх желаемого во время обновления. В учебной модели с тремя репликами можно рассмотреть maxUnavailable равным нулю и maxSurge равным единице. Сначала потребуется место для дополнительного нового экземпляра. Если ресурсов нет или новая версия не достигает готовности, продвижение остановится. Завершающиеся Pod могут ещё потреблять ресурсы, поэтому реальный пик нагрузки нельзя оценивать только по простой сумме желаемых реплик и дополнительного экземпляра.
Проверяйте пользовательский результат и откат
Готовность контейнера не обязательно означает исправность всей услуги. Вместе со статусами обновления наблюдайте ошибки, задержки и контрольное действие пользователя. Заранее определите признаки остановки и условия возврата к прежней версии. Откат шаблона Deployment не отменяет автоматически изменения внешней базы данных, поэтому совместимость требует отдельного плана. Приложение также должно корректно обрабатывать завершение процесса и уже принятые запросы. После обновления сравните фактическую работу с ожидаемой, а не ограничивайтесь сообщением о создании новых Pod.
Попробуйте на практике
На бумаге смоделируйте обновление трёх экземпляров приложения без подключения к реальному кластеру.
- Обозначьте три готовых старых экземпляра и условие maxUnavailable равное нулю, maxSurge равное единице.
- Добавьте новый экземпляр в состоянии запуска и объясните, почему его ещё нельзя считать готовым к рабочему трафику.
- Рассмотрите два исхода: новая версия проходит readiness или остаётся неготовой. Запишите допустимое следующее действие в каждом случае.
- Добавьте проверку пользовательского запроса и условие остановки при росте ошибок, даже если readiness остаётся успешной.
Как проверить результат. В модели новая реплика не заменяет доступную старую до выполнения условий готовности, а успешный запуск отделён от проверки полезного результата для пользователя.
Частые вопросы
Почему обновление может остановиться без падения старой версии?
Для следующего шага может не хватать ресурсов или готовой новой реплики. Такая остановка требует диагностики условий, а не немедленного удаления всех работающих экземпляров.
Достаточно ли одной проверки HTTP-ответа?
Это зависит от того, что именно проверяется. Простой ответ процесса может ничего не говорить о важной операции приложения. Проверки следует делать осмысленными и не чрезмерно тяжёлыми.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.