Каскадный деплой в GitOps: два подхода на FluxCD

В GitOps-модели FluxCD быстро и предсказуемо приводит кластеры к desired state. Но в multi-cluster и multi-env инфраструктуре эта же автоматизация может стать источником широкого blast radius: один ошибочный коммит, неправильный overlay или удаление ресурса способны волной пройти по dev, stage, pre-prod и production.

В докладе я покажу два практических подхода к каскадному деплою на FluxCD. Первый — Git-centric: Kargo.io управляет promotion flow между окружениями, обновляет GitOps-репозиторий, а Flux выполняет reconciliation в нужном кластере. Второй — Gitless для runtime path: CI валидирует manifests, публикует их как OCI artifacts, а окружения получают релиз через управляемые env-specific tags.

Отдельно разберем, почему каскадный деплой не должен быть просто цепочкой job'ов с задержкой. Следующий stage должен открываться только после проверки состояния предыдущего окружения: Flux metrics, состояние Kustomization/ HelmRelease/OCIRepository, application SLI и Prometheus-based stop/go gates.