Как происходит остановка и замена контейнеров при деплое?

Процесс остановки и замены контейнеров при деплое — это ключевой механизм в современных DevOps-практиках, обеспечивающий обновление приложений без простоев (zero-downtime deployment). Основная цель — заменить работающие экземпляры приложения на новые версии, минимизируя влияние на конечных пользователей.

Основные стратегии обновления

Оркестраторы контейнеров, такие как Kubernetes, поддерживают несколько стратегий, наиболее распространённой из которых является Rolling Update.

• Rolling Update: Новые контейнеры (поды) создаются постепенно, а старые удаляются после успешного запуска новых. Это позволяет поддерживать заданное количество доступных реплик.
• Blue-Green Deployment: Разворачивается две идентичные среды ("синяя" — текущая, "зелёная" — новая). После тестирования новой версии весь трафик переключается на "зелёную" среду.
• Canary Release: Новая версия разворачивается для небольшого процента пользователей, чтобы проверить стабильность, перед полным rollout.

Типичный процесс Rolling Update в Kubernetes

Рассмотрим на примере обновления Deployment в Kubernetes.

# 1. Изначально работает 3 пода (реплики) с версией v1.0
kubectl get pods
# NAME                     READY   STATUS    RESTARTS   AGE
# my-app-v1-abcde         1/1     Running   0          5d
# my-app-v1-fghij         1/1     Running   0          5d
# my-app-v1-klmno         1/1     Running   0          5d

# 2. Пользователь обновляет образ в манифесте Deployment на v2.0
kubectl set image deployment/my-app my-app=my-registry/app:v2.0

# 3. Kubernetes начинает процесс:
#    - Создаёт новый под с версией v2.0.
#    - Ждёт, пока он перейдёт в состояние Ready (проходят проверки readinessProbe).
#    - Удаляет один старый под с v1.0.
#    - Повторяет шаги, пока все поды не будут заменены.

# 4. В любой момент времени минимум 2 пода остаются доступными,
#    что обеспечивает непрерывность сервиса.

Критические этапы и настройки

Для корректной работы процесса необходимо настроить несколько параметров в спецификации Deployment.

• readinessProbe: Проверка, что контейнер готов принимать трафик. Новый контейнер начнёт получать запросы только после успешного прохождения этой проверки.
• livenessProbe: Проверка, что контейнер работает. Если проверка fails, контейнер будет перезапущен.
• strategy.rollingUpdate.maxUnavailable: Максимальное количество подов, которые могут быть недоступны во время обновления (например, 25% или 1).
• strategy.rollingUpdate.maxSurge: Максимальное количество подов, которые могут быть созданы сверх желаемого количества реплик (например, 25% или 1).

Перед остановкой старого контейнера оркестратор обычно отправляет ему сигнал SIGTERM, давая время на graceful shutdown (корректное завершение работы). Приложение должно уметь обрабатывать этот сигнал, завершая текущие соединения и освобождая ресурсы.

Вывод: Механизм плавной замены контейнеров через Rolling Update (или аналогичные стратегии) является стандартом для деплоя в production-средах, так как позволяет безопасно обновлять приложения, сохраняя доступность сервиса и обеспечивая быстрый откат при необходимости.