Какие стратегии деплоя (развертывания) вы знаете?

В CI/CD пайплайнах я применял следующие стратегии развертывания, в основном используя Kubernetes и инструменты вроде ArgoCD или Flux для их оркестрации:

1. Rolling Update (Постепенное обновление) Стандартная стратегия в Kubernetes. Новые поды (pods) постепенно заменяют старые, обеспечивая нулевое время простоя (zero-downtime). Недостаток — временное сосуществование двух версий приложения.

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Можно создать на 1 под больше желаемого количества
      maxUnavailable: 0  # Гарантирует, что всегда доступно 100% подов

2. Blue-Green Deployment Разворачиваются два идентичных окружения (синее — текущее, зеленое — новое). После тестирования зеленого окружения трафик переключается на него одним действием (например, сменой веса в сервисе или обновлением Ingress). Позволяет мгновенный откат. Требует двойных ресурсов.

3. Canary Deployment Новая версия разворачивается для небольшого процента пользователей (например, 5%). Постепенно, после мониторинга метрик (ошибки, latency), трафик увеличивается до 100%. Реализуется через Istio/Linkerd (service mesh) или функции облачных балансировщиков.

4. Recreate Deployment Все старые поды убиваются, затем создаются новые. Приводит к простою (downtime). Используется, когда приложение не поддерживает работу двух версий одновременно (например, из-за миграций БД).

5. A/B Testing с Feature Flags Разные функциональности разворачиваются параллельно, а управление доступом пользователей к ним осуществляется через системы feature flags (LaunchDarkly, Flagsmith). Это больше методика тестирования, чем деплоя.

На практике в Kubernetes чаще всего используется Rolling Update, а для критичных продакшен-сервисов — Canary или Blue-Green, настроенные через GitOps-инструменты.