Как выполнить rolling update и rollback Deployment в Kubernetes

Rolling update в Deployment постепенно заменяет Pods новой версией приложения. Но сама стратегия не гарантирует отсутствие простоя: нужны работающие проверки готовности, достаточные ресурсы, корректное завершение запросов и совместимость новой версии с данными. Поэтому обновление включает подготовку, наблюдение и заранее понятный способ отката.

Ниже авторский учебный сценарий для приложения с HTTP-портом 8080 и проверками /ready и /live. Имена образов registry.example.com/training/web:v1 и v2 — заполнители: замените их своими доступными образами. Пример не запускался в реальном кластере и не является отчётом об успешном выпуске.

Что проверить до изменения образа

Убедитесь, что kubectl обращается к нужному контексту и namespace. Запишите текущий образ, состояние Deployment и историю ревизий. Приложение должно действительно обслуживать указанные health-endpoints; произвольное добавление /ready в YAML не создаёт такой маршрут внутри контейнера.

Если трафик идёт через Service, его selector должен выбирать нужные Pods. Согласуйте метки между selector Deployment и шаблоном Pod. В API apps/v1 selector Deployment неизменяем: ошибка в нём не исправляется обычной сменой образа.

kubectl config current-context
kubectl -n rollout-demo get deployment demo -o wide
kubectl -n rollout-demo rollout history deployment/demo

Команды предполагают уже существующий учебный namespace rollout-demo. Для нового упражнения его и доступы готовят отдельно. Не переносите пример в рабочее окружение, не проверив контекст и реальные имена ресурсов.

Минимальный шаблон Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
  namespace: rollout-demo
spec:
  replicas: 3
  revisionHistoryLimit: 3
  progressDeadlineSeconds: 120
  selector:
    matchLabels:
      app: demo
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
        - name: web
          image: registry.example.com/training/web:v1
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /live
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 10

Числа выбраны для объяснения механизма. Периоды probes и deadline подбирают по реальному времени запуска и поведению приложения. Для рабочего развёртывания дополнительно определяют ресурсы, права, секреты реестра и завершение процесса; этот шаблон их не настраивает.

Если приложение долго запускается, рассмотрите startupProbe. Согласно документации Kubernetes, пока она не прошла успешно, liveness и readiness не начинают свои проверки. Не заменяйте разбор времени старта случайным увеличением всех таймеров.

Как читаются replicas и стратегия

replicas: 3 задаёт желаемое число экземпляров. maxUnavailable: 0 ограничивает допустимую недоступность при обновлении, а maxSurge: 1 разрешает дополнительный Pod сверх желаемого количества. В идеальном ходе сначала появляется новый готовый экземпляр, затем освобождается место за счёт старого.

Нужно место для дополнительного экземпляра. Если scheduler не может его разместить, выбранная стратегия может остановить продвижение. При этом terminating Pods способны временно занимать ресурсы сверх ожидаемой суммы replicas + maxSurge; документация отдельно отмечает это поведение.

Новая ревизия Deployment связана с изменением шаблона Pod, например образа контейнера. Простое изменение replicas не создаёт новую ревизию шаблона. revisionHistoryLimit определяет, сколько старых ReplicaSets хранить для истории; при нуле старые ReplicaSets с нулём реплик очищаются, поэтому рассчитывать на откат к удалённой ревизии нельзя. Документация уточняет: очистка начинается после завершения Deployment.

Как читать промежуточные количества

В авторском разборе предположим, что три старых Pod исправны, ресурсов достаточно, а новая версия проходит readiness. Тогда часть последовательности может выглядеть так:

Момент	Старых активных Pod	Новых Pod	Из новых Ready
До обновления	3	0	0
Новый экземпляр создан	3	1	0
Он прошёл readiness	3	1	1
Один старый выведен	2	1	1
Замена завершена	0	3	3

Таблица упрощает промежуточные переходы и не учитывает ещё завершающиеся Pods; это не ожидаемый дословный вывод kubectl. Если первый новый экземпляр не становится Ready, полезно исследовать именно его, пока старые продолжают обслуживать запросы. Не делайте вывод «обновление закончено» только потому, что новый Pod появился в списке: состояние Running и готовность к трафику не совпадают автоматически.

Запуск обновления и наблюдение

После подготовки и проверки исходной версии смените образ контейнера web. Имя контейнера берётся из шаблона, а не из имени Deployment.

kubectl -n rollout-demo set image deployment/demo   web=registry.example.com/training/web:v2
kubectl -n rollout-demo rollout status deployment/demo --timeout=90s
kubectl -n rollout-demo get pods -l app=demo -o wide
kubectl -n rollout-demo get deployment demo

Команда rollout status ожидает результат обновления. Параметр --timeout=90s ограничивает ожидание клиента kubectl. Он не отменяет обновление и не запускает rollback. В нашем шаблоне progressDeadlineSeconds: 120 — отдельное ограничение времени прогресса Deployment, а не другое написание того же параметра.

Даже успешный rollout дополните проверкой приложения через его обычную точку входа: откройте контрольный запрос и посмотрите ошибки, задержки и логи. Готовность Pods подтверждает настроенные проверки, но не исчерпывает все пользовательские сценарии.

Почему rollout может зависнуть

Наблюдение	Куда смотреть
Новые Pods остаются Pending	События планирования, ресурсы, ограничения размещения
Образ не загружается	Имя и наличие образа, доступ к реестру, секреты
Контейнер стартует, но Pod не Ready	Адрес, порт и ответ readinessProbe, журнал приложения
Контейнер повторно перезапускается	Причина завершения, liveness и реальная работа приложения

kubectl -n rollout-demo describe deployment demo
kubectl -n rollout-demo describe pod POD_NAME
kubectl -n rollout-demo logs POD_NAME -c web --tail=50

Замените POD_NAME именем проблемного нового Pod. Не исправляйте ошибку readiness удалением проверки только ради зелёного статуса. Сначала выясните, почему приложение не соответствует условию готовности.

При превышении срока прогресса Kubernetes сообщает условие ProgressDeadlineExceeded. Сам контроллер Deployment при этом не выполняет автоматический откат. Решение об откате принимает оператор либо настроенный внешний оркестратор.

Откат и его границы

kubectl -n rollout-demo rollout history deployment/demo
kubectl -n rollout-demo rollout undo deployment/demo
kubectl -n rollout-demo rollout status deployment/demo --timeout=90s

Для конкретной сохранившейся ревизии используют rollout undo deployment/demo --to-revision=2. Сначала проверьте историю: номер 2 здесь пример, а не гарантированная хорошая версия. После отката снова проверьте образ, Pods и фактический ответ приложения.

Deployment откатывает шаблон Pod. Он не возвращает автоматически базу данных, выполненную миграцию или отдельно изменённый ConfigMap. Если старая версия несовместима с новым состоянием данных, обратная смена образа может не восстановить работу. Возможность возврата нужно продумать до релиза.

Readiness и liveness также решают разные задачи. Неуспешная readiness исключает неготовый Pod из обслуживания через соответствующие Services; liveness при выполнении условий отказа приводит к перезапуску контейнера. Для завершения обновления важно не просто увеличить число probes, а выбрать проверки, которые отражают реальное состояние сервиса.