Как спроектировать стратегию zero-downtime деплоя (blue-green или canary) поверх примитивов Kubernetes, и какие здесь компромиссы по сравнению с обычным RollingUpdate?

Короткий ответ

Однозначно лучшей стратегии нет: обычный RollingUpdate Deployment достаточен для большинства случаев и прост в эксплуатации, canary (постепенный перевод небольшой доли трафика на новую версию с метриками до полного переключения) снижает blast radius ошибки ценой дополнительной инфраструктуры (service mesh или специализированный контроллер вроде Argo Rollouts/Flagger), а blue-green (две полностью параллельные версии с мгновенным переключением трафика) даёт самый быстрый откат ценой удвоенного потребления ресурсов на время деплоя.

Как это работает подробнее

RollingUpdate постепенно подменяет поды одной версии на другую без возможности тонко контролировать долю трафика на новую версию отдельно от доли подов — на практике доля трафика примерно пропорциональна доле подов новой версии, и нет встроенного механизма автоматической остановки по метрикам ошибок. Canary и blue-green требуют дополнительного уровня управления трафиком независимо от количества подов (через service mesh с weighted routing, Ingress с canary-аннотациями, или специализированный контроллер), что позволяет, например, направить всего 5% трафика на новую версию, автоматически анализировать метрики ошибок/латентности, и либо продолжить раскатку, либо автоматически откатиться при аномалии.

• Компромисс. усложнение пайплайна деплоя должно быть оправдано реальной частотой проблемных релизов и стоимостью инцидента при плохом деплое — для внутреннего низконагруженного сервиса обычный RollingUpdate с хорошими readiness probe и мониторингом может быть достаточен, тогда как для высоконагруженного customer-facing сервиса с историей проблемных релизов инвестиция в canary-инфраструктуру может окупиться; это решение стоит обсуждать предметно для каждого сервиса, а не внедрять одну стратегию деплоя универсально для всей платформы.

Пример кода

manifest.yamlКопировать

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata: { name: checkout }
spec:
  strategy:
    canary:
      steps:
        - setWeight: 5
        - pause: { duration: 10m }
        - setWeight: 25
        - pause: { duration: 10m }
        - setWeight: 100

Что использовать на практике

• Практика. canary particularly полезен для сервисов с высоким трафиком и историей проблем, не ловящихся в staging (где нагрузка и данные отличаются от прод); blue-green особенно ценен, когда критична скорость отката (мгновенное переключение трафика обратно на полностью готовую старую версию) и когда можно себе позволить временно удвоенное потребление ресурсов. Оба подхода усложняют конфигурацию и требуют дополнительных инструментов и экспертизы команды (например, Argo Rollouts с анализом метрик через Prometheus), что увеличивает когнитивную нагрузку и поверхность отказа самой платформы деплоя.

Подводные камни

• Риски. частая ошибка — путать canary и blue-green или считать, что RollingUpdate даёт точный контроль доли трафика на новую версию независимо от доли подов; также кандидаты нередко предлагают canary/blue-green как универсальное решение для всех сервисов, не упоминая стоимость дополнительной инфраструктуры и экспертизы.