Чем отличаются стратегии обновления Deployment RollingUpdate и Recreate, и как maxSurge/maxUnavailable влияют на процесс?

Короткий ответ

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

Как это работает подробнее

при RollingUpdate с maxSurge: 1, maxUnavailable: 0 Deployment сначала поднимает один дополнительный под новой версии, дожидается его readiness, и только потом гасит один под старой версии, повторяя цикл — это минимизирует риск простоя ценой временного превышения числа реплик. При maxUnavailable: 1, maxSurge: 0 вместо этого сначала гасится один старый под, и лишь после его удаления поднимается новый — это экономит ресурсы, но временно снижает мощность обслуживания.

Пример кода

manifest.yamlКопировать

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

Что использовать на практике

• Практика. Recreate оправдан, когда одновременная работа старой и новой версии недопустима — например, при несовместимых изменениях схемы данных в stateful-приложении с единственной репликой, или при эксклюзивном доступе к ресурсу, который не поддерживает параллельный доступ двух версий. Для большинства stateless веб-сервисов используют RollingUpdate с ненулевым maxSurge, чтобы избежать простоя при деплое.

Подводные камни

• Риски. выбирать RollingUpdate для приложения, где старая и новая версия не могут работать одновременно (например, из-за несовместимого формата сообщений в очереди), что приводит к ошибкам в проде во время самого обновления; устанавливать maxUnavailable: 0 и maxSurge: 0 одновременно — это некорректная комбинация, блокирующая прогресс rollout.