Выбор стратегии выката влияет на доступность сервиса, скорость отката и стоимость инфраструктуры. Ниже — практическое сравнение трёх распространённых подходов в экосистеме Kubernetes.
Rolling update
По умолчанию в Deployment Kubernetes постепенно заменяет старые поды новыми (maxUnavailable, maxSurge). Плюсы: простота, не нужен второй полный набор ресурсов. Минусы: в переходный момент в кластере сосуществуют две версии; при ошибке в образе часть трафика уже на новой версии. Подходит для большинства stateless-сервисов с хорошими health checks.
Blue-green
Две полные «среды» (blue = текущая, green = новая). Переключение трафика — одно действие (Service selector, Ingress или service mesh). Плюсы: мгновенный откат переключением обратно, чёткая изоляция версий. Минусы: удвоение ресурсов на время выката, сложнее для stateful-нагрузок. Хорошо для критичных релизов с коротким окном проверки.
Canary
Небольшой процент трафика на новую версию; при стабильных метриках долю увеличивают. Реализуется через Ingress controller, Istio/Linkerd, Argo Rollouts и т.п. Плюсы: ограниченный blast radius, можно привязать к SLO. Минусы: нужна дисциплина метрик и автоматизации; дольше полный выкат. Оптимально для высоканагруженных сервисов с чувствительностью к регрессиям.
Как выбрать
Начните с rolling для типовых сервисов. Переходите к blue-green, если нужен быстрый «всё или ничего» откат и бюджет на дублирование. Canary — когда важны постепенность и наблюдаемость. Инструменты вроде Opsy помогают унифицировать описание деплоя и снизить ручную работу с манифестами независимо от выбранной стратегии.