Canary Deployment (Канареечное развертывание)

Canary Deployment — это стратегия поэтапного выката новой версии приложения, при которой обновление сначала получают только небольшая часть пользователей или трафика. Остальная часть продолжает использовать стабильную версию. Такой подход минимизирует риски, позволяя проверить стабильность и поведение новой версии в реальных условиях до масштабного внедрения.

Название “canary” (канарейка) отсылает к историческому способу раннего обнаружения проблем — как шахтёры брали канареек для выявления утечек газа, так и DevOps-команды используют canary-релиз для раннего выявления сбоев.

Ключевые цели Canary Deployment

Мягкий запуск новой функциональности;
Раннее обнаружение багов и регрессий до массового обновления;
Минимальный риск: сбой затрагивает только малую часть пользователей;
A/B-тестирование новых гипотез без создания отдельных окружений;
Возможность автоматического или ручного отката при деградации метрик.

Реализация в Kubernetes

Canary-деплой в Kubernetes реализуется с помощью:

Разных версий Deployment/ReplicaSet с метками (version: v1, version: v2);
Service или Ingress с ручным или автоматизированным распределением трафика;
Istio, Linkerd, Traefik или NGINX Ingress Controller для L7-канареек;
Argo Rollouts или Flagger — инструменты для автоматизации canary-процессов с интеграцией в CI/CD.

Пример с Istio VirtualService:

http:
  - route:
      - destination:
          host: app
          subset: stable
        weight: 80
      - destination:
          host: app
          subset: canary
        weight: 20

Здесь 20% трафика направляется на новую версию, 80% — на стабильную.

Отличие от Blue-Green Deployment

Подход	Переключение	Преимущества	Подходит для
Canary	Постепенное	Гибкость, контроль, снижение рисков	Частые релизы, A/B тесты
Blue-Green	Мгновенное	Простота, быстрый откат	Продакшн с жёсткими SLA

Интеграция с CI/CD

Canary-процесс может быть:

ручным — переключение веса трафика поэтапно вручную;
автоматическим — через Argo Rollouts, Flagger или Spinnaker:
- мониторинг метрик (например, HTTP 5xx, latency);
- автоматическое принятие решения о продвижении или откате;
- полная GitOps-совместимость.

Инструменты Canary Deployment

Инструмент	Описание	Поддержка автоотката	GitOps
Argo Rollouts	CRD + controller для пошагового деплоя	Да	Да
Flagger	Operator для canary через Ingress/Mesh	Да	Да
Istio	Ручное управление через VirtualService	Нет (вручную)	Да
NGINX Ingress	Аннотации canary-weight	Частично	Да

Canary Deployment — это один из самых гибких и безопасных способов выката изменений в Kubernetes. Он даёт командам контроль над рисками, интеграцию с мониторингом и возможностью быстро откатиться, если новая версия работает нестабильно.

Вот практический набор для внедрения canary deployment с Argo Rollouts в Kubernetes:

1. `Rollout` манифест (Argo Rollouts + canary)

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  replicas: 4
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - setWeight: 50
        - pause: { duration: 10m }
        - setWeight: 100
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: app
          image: myregistry/my-app:{{ .Values.image.tag }}
          ports:
            - containerPort: 8080

Вес трафика растёт поэтапно. Argo контролирует переключения и может откатить в любой момент.

2. PrometheusRule: откат при росте ошибок

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: canary-failures
  namespace: monitoring
spec:
  groups:
    - name: canary-errors
      rules:
        - alert: Canary5xxSpike
          expr: |
            increase(http_requests_total{status=~"5..", app="my-app"}[5m]) > 10
          for: 2m
          labels:
            severity: critical
          annotations:
            summary: "Canary 5xx spike"
            description: "5xx errors increased after canary rollout. Rollback recommended."

Этот алерт может быть привязан к webhook, который инициирует откат через Argo Rollouts API.

3. Helm-параметры `values.yaml`

image:
  tag: "v2.1.3"

canary:
  enabled: true
  weightSteps:
    - 10
    - 50
    - 100
  pauseDurations:
    - 5m
    - 10m

Можно сделать Helm-чарт, где эти значения динамически подставляются в Rollout.

4. GitOps-интеграция с Argo CD

rollout.yaml коммитится в gitops/ репозиторий;
Argo CD отслеживает изменения;
Команда CI (например, в GitLab/GitHub Actions) коммитит изменение тега и триггерит rollout;
Метрики Prometheus → алерт → webhook → откат через Argo Rollouts Controller.

Было полезно?