Как организовать zero-downtime deployment

Что нужно для отсутствия простоя

минимум две реплики stateless-приложения;
корректный readiness check, который отражает готовность принимать трафик;
graceful shutdown: процесс перестаёт принимать новые запросы, но завершает текущие;
connection draining на load balancer или ingress;
backward-compatible API и миграции данных;
мониторинг rollout и быстрый rollback.

Rolling deployment

Rolling update постепенно запускает новые экземпляры и удаляет старые. В Kubernetes можно не снижать доступное число реплик ниже желаемого значения.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      terminationGracePeriodSeconds: 60
      containers:
        - name: api
          image: ghcr.io/acme/api:1.1.0
          readinessProbe:
            httpGet:
              path: /health/ready
              port: 8000

Blue-green deployment

Blue-green поддерживает две полноценные версии. Новую green-версию разворачивают и проверяют без production-трафика, затем load balancer или Service переключают на неё. Откат быстрый: трафик возвращают на blue. Недостаток — требуется примерно вдвое больше ресурсов на время релиза.

Canary deployment

Canary постепенно направляет небольшой процент трафика на новую версию. Если error rate, latency и бизнес-метрики в норме, долю увеличивают. При проблемах rollout останавливают и откатывают до того, как ошибка затронет всех пользователей.

Миграции базы данных

Частая причина downtime — несовместимая миграция. Нужно применять expand-contract подход: сначала добавить новые таблицы, поля или индексы в обратно совместимом виде, затем развернуть код, потом перенести данные и только после полного перехода удалить старую схему.

1. Expand: add nullable field or new table
2. Deploy: code reads old and new schema safely
3. Migrate: backfill data asynchronously
4. Switch: use new schema
5. Contract: remove old field in a later release

Проверка релиза

Перед релизом и во время него нужно проверять readiness, error rate, p95/p99 latency, saturation, queue lag и бизнес-метрики. Rollback должен быть заранее описан и проверен, а не придуман во время инцидента.

Как ответить на собеседовании

Для zero-downtime deployment использую несколько реплик, readiness probes, graceful shutdown и connection draining. Выбираю rolling update, blue-green или canary в зависимости от риска и ресурсов. Самая важная часть — обратная совместимость API и схемы БД: миграции делаю по expand-contract, а rollout контролирую через метрики и заранее проверенный rollback.

Как организовать zero-downtime deployment?