Стратегия по умолчанию — RollingUpdate: создаётся новый ReplicaSet, поды постепенно заменяются. maxSurge — сколько подов сверх нужного числа можно поднять, maxUnavailable — сколько можно потерять во время обновления. Новый под получает трафик только после readiness. Откат: kubectl rollout undo deployment/orders — возвращается предыдущий ReplicaSet (хранятся revisionHistoryLimit ревизий).
А ещё Старая и новая версии работают одновременно — API и схема БД должны быть совместимы
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
Ход выкатки (3 реплики, maxSurge 1, maxUnavailable 0):
Команды:
sottokubectl set image deployment/orders app=orders:1.4.3
kubectl rollout status deployment/orders
kubectl rollout history deployment/orders
kubectl rollout undo deployment/orders --to-revision=4Ограничения rolling update: нет автоматического отката по метрикам ошибок, трафик переключается пропорционально числу подов. Для canary и автоматического анализа используют Argo Rollouts или Flagger.
Стратегия Recreate — убить все старые, потом поднять новые: простой, но нужна, когда две версии одновременно работать не могут.
Откат в GitOps делается откатом коммита в репозитории конфигурации, иначе контроллер вернёт «сломанное» желаемое состояние.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.