Progressive delivery (Argo Rollouts)
Тема дорожной карты · Kubernetes
Progressive Delivery — стратегия развёртывания, постепенно выкатывающая новые версии приложений на всё большие подмножества пользователей или трафика с использованием автоматического анализа для управления продвижением и запуска отката при нарушении бюджетов ошибок. В Kubernetes Progressive Delivery реализуется инструментами Argo Rollouts и Flagger, расширяющими стандартный ресурс Deployment стратегиями canary, blue-green и A/B-тестирования, управляемыми CRD Rollout или Canary. Argo Rollouts интегрируется с Ingress-контроллерами (ingress-nginx, Traefik) и service mesh (Istio, Linkerd) для разделения трафика по процентам через spec.strategy.canary.steps — например, направляя 5% трафика на новую версию, делая паузу для анализа, затем постепенно увеличивая до 20%, 50% и 100%. Автоматический анализ запрашивает метрики Prometheus — например, частоту ошибок, p99-задержку или пользовательские бизнес-KPI — через CRD AnalysisTemplate и AnalysisRun, автоматически откатываясь при превышении пороговых значений без вмешательства человека. Progressive Delivery — критический компонент GitOps-рабочих процессов с Argo CD и Flux, где смёрженный pull request запускает контролируемую выкатку, а не немедленную полную замену.
Как это работает
Progressive delivery (Argo Rollouts) рассматривает git-репозиторий как источник истины для состояния кластера. Агент внутри кластера (Argo CD, Flux CD) непрерывно сводит состояние кластера к тому, что в git: коммит в main триггерит redeployment; ручной kubectl edit откатывается агентом. Pull request становятся deployment-предложениями с reviewer; audit trail бесплатно из git history.
Когда применять
Принимайте Progressive delivery (Argo Rollouts) когда (а) в команде больше 2-3 инженеров и прямой доступ к кластеру становится рискованным, (б) нужны audit trails для compliance, (в) хотите rollback deployment через git revert вместо ad-hoc kubectl. Пропустите GitOps для очень маленьких команд, где прямой kubectl-доступ достаточно быстрый — overhead превышает выгоду до тех пор, пока координация не становится важной.
Типичные ошибки
GitOps-ловушки: configuration drift между git и кластером (ручные изменения не откатываются, потому что агент неправильно настроен); секреты в plaintext git (используйте sealed-secrets или External Secrets); слишком много сред в одном репо (медленный CI, большой blast radius). Относитесь к GitOps-репо как к production infrastructure: PR review, branch protection, deployment workflows.