Как настроить blue-green deployment или canary release?

Blue-green deployment

При blue-green есть две среды: текущая версия, например blue, и новая версия, например green. Обе версии могут работать одновременно, но Service направляет production-трафик только на одну из них. После проверки новой версии selector Service переключают с blue на green.

apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api
    version: blue
  ports:
    - port: 80
      targetPort: 8000

После валидации green-версии достаточно изменить selector Service на version: green. Откат также быстрый: selector возвращают на blue.

Canary release

Canary выпускает новую версию постепенно. Сначала небольшой процент пользователей получает новую версию, затем по метрикам оценивают error rate, p95/p99 latency, бизнес-события и ресурсы. Если всё в норме, долю трафика увеличивают до 100%; при проблемах выполняют rollback.

Как направлять часть трафика

Обычный Kubernetes Service не умеет сам распределять трафик по процентам между версиями. Для canary обычно используют Ingress controller с поддержкой weighted routing, service mesh, например Istio, или инструменты progressive delivery, например Argo Rollouts и Flagger.

Что нужно подготовить

• readiness probes, чтобы трафик получали только готовые Pod;

• метрики, логи и трассировку для сравнения старой и новой версий;

• понятные критерии успешности и автоматического rollback;

• обратно совместимые миграции базы данных;

• стратегию работы с кэшем, очередями и background jobs.

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

Blue-green запускает старую и новую версии параллельно и переключает весь трафик после проверки, поэтому откат происходит быстро. Canary постепенно направляет часть трафика на новую версию и опирается на метрики. Для процентного распределения трафика использую Ingress, service mesh или progressive delivery-инструмент, а не только стандартный Service Kubernetes.