Как происходит процесс обновления в Kubernetes и какие политики rollout используются

Что проверяют

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

Как отвечать

Обновление запускается изменением шаблона пода в Deployment (spec.template), чаще всего сменой образа. Контроллер создаёт новый ReplicaSet и по выбранной стратегии переводит поды на него. Изменение числа реплик выкатку не запускает.

Стратегии Deployment:

• RollingUpdate: стратегия по умолчанию, поды меняются постепенно. Темп задают maxSurge (сколько подов можно создать сверх нужного числа) и maxUnavailable (сколько может быть недоступно), оба по умолчанию 25%;
• Recreate: сначала гасятся все старые поды, потом стартуют новые. Будет простой, зато две версии никогда не работают одновременно.

У StatefulSet и DaemonSet стратегии RollingUpdate и OnDelete, у StatefulSet есть ещё partition, чтобы обновить только часть подов.

Трафик на новый под идёт только после успешной readinessProbe, поэтому ошибка в пробе частая причина провальной выкатки. Если выкатка не продвигается дольше progressDeadlineSeconds (по умолчанию 600 секунд), она помечается неуспешной, но сама не откатывается.

Команды: kubectl rollout status, history, undo, pause, resume. Канареечный и blue-green релизы штатным Deployment не делаются: их строят двумя деплойментами с переключением Service, через Argo Rollouts, Flagger или service mesh.

Для QA отсюда практика: во время RollingUpdate часть запросов обслуживает старая версия, часть новая, поэтому проверяется обратная совместимость API и миграций базы. После выкатки гоняется смоук, и стоит смотреть, какая версия ответила.

Где спотыкаются

Думают, что Kubernetes сам откатит сломанную версию. Он только остановит выкатку, откат делает человек или внешний инструмент.

Не проверяют смешанное состояние: новый фронт ходит в старый бэкенд, старый под пишет в базу после миграции.

Называют канареечный релиз встроенной стратегией Deployment и теряются, когда просят показать её в манифесте.