RollingUpdate и Recreate — что это и в чём разница

RollingUpdate и Recreate — это две стратегии развёртывания, которые описываются в spec.strategy у Deployment (и у некоторых других контроллеров). Они определяют, как контроллер будет заменять старые Pod'ы новой версией приложения.

RollingUpdate (по умолчанию)

Описание:

• Контроллер создаёт новый ReplicaSet с обновлённым шаблоном Pod и постепенно заменяет старые Pod'ы новыми, соблюдая ограничения на количество одновременно созданных и недоступных Pod'ов.
  Параметры:

• maxSurge — сколько дополнительных Pod'ов разрешено создать сверх .spec.replicas (можно задать абсолютным числом или процентом).

• maxUnavailable — сколько Pod'ов может быть одновременно недоступно (также число или процент).

Формулы (упрощённо):

• Максимальное число Pod'ов в кластере в процессе обновления = replicas + maxSurge.

• Минимально доступных Pod'ов (Ready) во время обновления ≥ replicas - maxUnavailable.

Пример:

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

При replicas: 5 в любой момент будет максимум 6 Pod'ов, и не менее 4 будут доступны (5 - 1).

Поведение:

• Контроллер поднимает новые Pod'ы (в пределах maxSurge), ждёт readiness, затем удаляет старые, повторяет цикл.

• Уменьшает простой сервиса — подходит для веб-сервисов, API и т.п.

• Чувствителен к readinessProbe, scheduling/rsrc-ограничениям, проблемам с imagePull и CrashLoopBackOff — если новые Pod'ы не становятся Ready, rollout остановится.

Команды:

• kubectl rollout status deployment/<name>

• kubectl rollout pause|resume deployment/<name>

• kubectl rollout undo deployment/<name>

Ограничения:

• При использовании PersistentVolume с ReadWriteOnce нужно учитывать, что maxSurge>0 может попытаться запустить новый Pod на другой ноде — монтирование RWO на второй ноде может быть невозможно. Для stateful-хранилищ лучше использовать StatefulSet или выставить maxSurge: 0.

Recreate

Описание:

• Контроллер удаляет все старые Pod'ы и только потом создаёт новые. Происходит явный простоj: старые инстансы завершаются перед созданием новых.

Пример:

strategy:
type: Recreate

Поведение и сценарии:

• Гарантирует, что старые и новые Pod'ы никогда не работают одновременно — полезно если версия приложения не совместима с предыдущей, если оба экземпляра одновременно приведут к конфликтам (например, миграции схемы, блокировки ресурсов) или при необходимости гарантировать эксклюзивный доступ к локальным ресурсам.

• Обеспечивает простой во время обновления — не годится для критичных по доступности приложений без компенсирующих мер (maintenance window, read-only режимы и т.д.).

Особенности:

• Простая и предсказуемая стратегия, но с даунтаймом.

• Для stateful-приложений с RWO томами поведение Recreate может быть безопаснее, чем RollingUpdate с maxSurge>0.

Как выбрать

• Используйте RollingUpdate для большинства stateless-сервисов, когда важна непрерывная доступность.

• Используйте Recreate если одновременная работа старой и новой версии недопустима (миграции, эксклюзивные ресурсы) или если приложение stateful и вы не можете обеспечить безопасный параллелизм.

• Для сложных сценариев (canary, blue/green) лучше сочетать Deployments с traffic-routing (Ingress/Service mesh) или применять дополнительные контроллеры/инструменты.

Практические советы

• Всегда настраивайте корректные readinessProbe, чтобы RollingUpdate не выводил в трафик неготовые Pod'ы.

• Проверяйте ресурсы кластера перед масштабированием/обновлением (чтобы новые Pod'ы не остались в Pending).

• Для PV с ограничениями доступа планируйте стратегию так, чтобы избежать конфликтов при одновременной попытке монтирования.