← Back to notes

Стратегии развертывания
(Deployment Strategies)

2025-11-04

#deployment

Стратегия определяет downtime, риск и скорость доставки. В Kubernetes Deployment поддерживает только два встроенных значения spec.strategy.type: Recreate и RollingUpdate (default). Blue-Green, Canary, Shadow реализуются через дополнительный routing-слой (Service/Ingress, Service Mesh) или контроллеры типа Argo Rollouts/Flagger.

1. Recreate (с даунтаймом)

Старая версия полностью останавливается, затем разворачивается новая.

v1 ──────────────╳───────────────
                        ↓
                     Deploy v2
                        ↓
v2 ──────────────────────────────▶

Плюсы:

  • Простота настройки
  • Минимальные ресурсы (одна версия в каждый момент времени)

Минусы:

  • Полный даунтайм во время деплоя
  • Риск неудачного обновления без возможности мгновенного отката

Пример (Kubernetes):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  strategy:
    type: Recreate

kubectl rollout restart сам по себе не означает Recreate: он перезапускает Pod'ы по стратегии, заданной в spec.strategy.

2. Rolling Update (без даунтайма)

Default стратегия Deployment в Kubernetes. Параметры:

  • maxSurge — сколько подов можно создать сверх replicas (default 25%);
  • maxUnavailable — сколько подов может быть недоступно во время rollout (default 25%).

Оба принимают абсолютные значения или проценты, но не могут быть одновременно 0.

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%

Плюсы: без даунтайма, плавный переход, остановка через kubectl rollout pause. Минусы: одновременно работают обе версии — нужна обратная совместимость API/схемы БД; контроль трафика по версиям ограничен.

kubectl set image deployment/my-app my-app=repo/app:v2
kubectl rollout status deployment/my-app
kubectl rollout undo deployment/my-app

3. Blue-Green Deployment

Поддерживаются две среды:

  • Blue — текущая версия
  • Green — новая версия

После развертывания новой версии, трафик просто переключается с Blue на Green.

Users → Blue (v1)
       ↓ switch
Users → Green (v2)

Плюсы:

  • Без даунтайма
  • Легкий откат (просто вернуть трафик на старую среду)

Минусы:

  • Удвоенные ресурсы (две среды активны)
  • Необходима интеграция с балансировщиком или proxy

Пример:

# Пример nginx reverse proxy
server {
    location / {
        proxy_pass http://green_backend; # переключаем с blue_backend на green_backend
    }
}

4. Canary Deployment

Новая версия выкатывается ограниченной группе пользователей.
Если всё хорошо — процент трафика постепенно увеличивается.

5% → 25% → 50% → 100%

Плюсы:

  • Минимальный риск
  • Контролируемое тестирование в реальной среде

Минусы:

  • Требует сложной маршрутизации (feature flags, service mesh)
  • Более длительный процесс развертывания

Пример (Kubernetes + Istio):

apiVersion: networking.istio.io/v1
kind: VirtualService
spec:
  http:
  - route:
    - destination:
        host: my-app
        subset: v1
      weight: 90
    - destination:
        host: my-app
        subset: v2
      weight: 10

5. Shadow Deployment (тестирование в фоне)

Новая версия получает копию реального трафика, но ответы не видны пользователям.
Используется для тестирования производительности и регрессий.

Users → v1 (реальный ответ)
       ↳ v2 (анализ ответов)

Плюсы:

  • Полностью без даунтайма
  • Можно тестировать новую версию под боевой нагрузкой

Минусы:

  • Требует сложной инфраструктуры для дублирования запросов
  • Данные должны быть консистентны

Сравнение стратегий

Когда что выбирать

  • Recreate — простые системы без SLA, batch-jobs;
  • Rolling Update — стандарт для stateless workloads в Kubernetes;
  • Blue-Green — мгновенный rollback, готовы платить ×2 ресурсов;
  • Canary — постепенный rollout с метриками (Argo Rollouts, Flagger);
  • Shadow — нагрузочные/регрессионные тесты на проде без влияния на пользователей.

Ссылки

Стратегии развертывания (Deployment Strategies) | Aleksandr Suprun