Что такое Rolling Update?

Что такое Rolling Update?

Rolling Update (постепенное обновление) — это стратегия развертывания обновлений в контейнеризированных и оркестрированных средах (таких как Kubernetes, Docker Swarm, облачные платформы), при которой новые версии приложения (Pods, контейнеры, инстансы) запускаются постепенно, заменяя старые, без полной остановки сервиса. Это обеспечивает нулевое время простоя (zero-downtime) и позволяет поддерживать доступность приложения во время деплоя.

Основная идея — избежать "большого взрыва", когда все инстансы обновляются одновременно, что может привести к полному отказу сервиса в случае ошибки в новой версии. Вместо этого обновление происходит небольшими партиями (batches) или по одному узлу, что минимизирует риски и упрощает откат.

Ключевые принципы Rolling Update

• Постепенность: Обновление разбивается на шаги. Сначала создается один или несколько новых Pods с новой версией, затем они проходят проверку готовности (readiness probes), и только после успеха — старые Pods удаляются. Этот процесс повторяется, пока все Pods не будут обновлены.
• Контролируемая доступность: На каждом этапе гарантируется, что минимальное количество Pods (определяемое настройками) остается доступным для обслуживания трафика. В Kubernetes это управляется параметрами maxUnavailable и maxSurge.
• Здоровье и готовность: Стратегия сильно зависит от корректно настроенных liveness и readiness probes. Они сигнализируют оркестратору, когда новый Pod готов принимать трафик, а когда — неисправен и требует отката.
• Автоматический откат (Rollback): Если новые Pods не переходят в состояние "Ready" в течение заданного времени (progressDeadlineSeconds в Kubernetes) или не проходят проверки здоровья, развертывание может быть автоматически остановлено и откачено до предыдущей стабильной версии.

Параметры управления Rolling Update в Kubernetes

В манифесте Deployment Kubernetes стратегия определяется в секции strategy. Вот ключевые поля:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # Максимальное количество Pods сверх желаемого количества (replicas), которые могут быть созданы. Может быть числом или процентом (например, "25%").
      maxUnavailable: 0    # Максимальное количество Pods, которые могут быть недоступны во время обновления. "0" означает, что доступность должна быть 100%.
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:v2.0.0 # Новая версия для деплоя
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5

• maxSurge: 1: При обновлении 4 реплик сначала будет создана 1 новая Pod (всего станет 5), затем 1 старая удалится, и так далее. Это ускоряет процесс.
• maxUnavailable: 0: Гарантирует, что в любой момент времени будут доступны все 4 реплики (старые + новые). Это самый безопасный, но медленный вариант.

Пример пошагового процесса

Для Deployment с replicas: 4, maxSurge: 1, maxUnavailable: 0:

1. Шаг 1: Создается 1 новый Pod (myapp:v2). Доступны 4 старых Pods (myapp:v1) и 1 новый (всего 5). Новый Pod проходит проверки готовности.
2. Шаг 2: После успешного перехода нового Pod в Ready, одна из старых Pods (v1) удаляется. Теперь доступны 3 старых Pods и 1 новый (всего 4, что соответствует replicas: 4).
3. Шаг 3: Создается следующий новый Pod (v2). Доступны 3 старых, 2 новых (всего 5). После его готовности удаляется вторая старая Pod.
4. Процесс повторяется, пока все 4 Pods не будут работать на версии v2.

Преимущества Rolling Update

• Минимальный Downtime: Приложение остается доступным для пользователей на протяжении всего обновления.
• Снижение рисков: Позволяет выявить проблемы в новой версии на небольшом подмножестве инстансов до полного развертывания.
• Автоматизация и стандартизация: Процесс полностью управляется оркестратором по декларативным правилам.
• Простота отката: В случае сбоя можно быстро вернуться к предыдущей версии, откатив Deployment (kubectl rollout undo deployment/myapp-deployment).

Недостатки и соображения

• Совместимость версий: На время обновления одновременно работают две версии приложения. Это требует обеспечения обратной совместимости API, схем баз данных и форматов сообщений между микросервисами.
• Сложность мониторинга: Необходимо тщательно следить за метриками (ошибки, latency) как новых, так и старых Pods, чтобы оперативно выявлять проблемы.
• Более длительное развертывание: По сравнению с полной заменой (Recreate), процесс занимает больше времени.
• Требования к ресурсам: В пиковые моменты (maxSurge > 0) требуется дополнительная вычислительная мощность для работы "лишних" Pods.

Практическая команда для Kubernetes

Чтобы инициировать Rolling Update в Kubernetes, обычно достаточно обновить образ контейнера в манифесте и применить его или использовать команду:

# Обновление образа через команду
kubectl set image deployment/myapp-deployment myapp=myapp:v2.0.0

# Мониторинг статуса обновления
kubectl rollout status deployment/myapp-deployment

# Просмотр истории ревизий
kubectl rollout history deployment/myapp-deployment

# Откат к предыдущей версии
kubectl rollout undo deployment/myapp-deployment

Итог: Rolling Update — это фундаментальная стратегия непрерывного развертывания (CI/CD) и надежной эксплуатации в DevOps-практике. Она представляет собой баланс между скоростью доставки новых фич и стабильностью production-среды, позволяя обновлять приложения безопасно, предсказуемо и с минимальным воздействием на конечных пользователей.