На примере Kubernetes Deployment объясните, как работает rolling update и что регулируют параметры maxSurge и maxUnavailable

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

Rolling update постепенно заменяет старые поды новыми: `maxSurge` ограничивает, сколько дополнительных подов сверх желаемого количества можно создать во время обновления, а `maxUnavailable` — сколько подов может быть недоступно одновременно; вместе они регулируют скорость и безопасность обновления.

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

контроллер Deployment создаёт новые поды с обновлённым образом и дожидается, пока они станут Ready (через readinessProbe), прежде чем начать удалять старые, сохраняя баланс согласно указанным значениям `maxSurge`/`maxUnavailable` (по умолчанию по 25% от желаемого числа реплик).

Пример кода

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

spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

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

• На практике. увеличение `maxSurge` ускоряет обновление за счёт временного роста потребления ресурсов кластера; уменьшение `maxUnavailable` до `0` гарантирует, что сервис никогда не останется без доступных подов, но делает обновление медленнее. Для корректной работы критично настроить readinessProbe — иначе Kubernetes может посчитать нерабочий под готовым.
• Пример. Ожидаемое поведение: при обновлении образа Kubernetes сначала создаёт 1 дополнительный под (всего 5), дожидается его готовности, затем удаляет один старый под, и так до полной замены — доступных подов всегда минимум 4.

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

• Частые ошибки. выставляют `maxUnavailable: 100%` «для скорости», что по сути превращает rolling update в recreate-стратегию с простоем; не настраивают readinessProbe, из-за чего новый под с ошибкой запуска считается готовым и получает трафик раньше времени.