Kargo: GitOps-продвижение релизов по окружениям поверх Argo CD

Argo CD отлично отвечает на вопрос «привести кластер к состоянию из git». Но он не отвечает на вопрос «а как одна и та же версия аккуратно проезжает по цепочке окружений dev → stage → prod, с проверками на каждом шаге». Этот кусок обычно склеивают вручную: скрипты в CI, которые бампают тег образа в нужном каталоге, PR-ы «подними версию в prod», и надежда, что никто не перепутает. Kargo закрывает ровно этот пробел.

Оригинал и документация — kargo.io и docs.kargo.io . Kargo — open source (Apache-2.0) от Akuity , создателей Argo. Текст ниже — мой разбор своими словами, не перевод.

Что такое Kargo

Kargo — это слой оркестрации промоушенов поверх GitOps: он управляет тем, какая версия приложения, в какое окружение и когда едет — а фактическую раскатку по-прежнему делает Argo CD. То есть Kargo не заменяет Argo CD, а дополняет его: Kargo редактирует GitOps-репозиторий (теги образов, values), Argo CD видит изменение и синхронизирует кластер.

Ключевая идея — сделать продвижение релиза first-class-объектом, а не набором ad-hoc скриптов: с историей, проверками, откатами и наглядной картиной «что где сейчас стоит».

Ключевые понятия

Kargo вводит несколько CRD. Их немного, и они логично складываются в конвейер:

• Warehouse (склад) — источник артефактов. Следит за подписками: git-репозиторием, реестром образов, Helm-чартами. Когда появляется что-то новое, Warehouse производит Freight.
• Freight (груз) — иммутабельный снимок набора артефактов: конкретные git-коммит, тег образа и версия чарта, зафиксированные вместе. Именно Freight «едет» по окружениям — как единое целое, а не по отдельности.
• Stage (стадия) — окружение или фаза (dev, stage, prod). Подписывается на Freight — либо напрямую из Warehouse, либо на выход предыдущей стадии. У стадии есть шаги промоушена и (опционально) проверка.
• Promotion (промоушен) — операция «применить этот Freight к этой стадии»: например, отредактировать git (обновить тег/values), дождаться синхронизации Argo CD, прогнать шаги.
• Verification (проверка) — тесты после промоушена (через AnalysisRun из Argo Rollouts или свои job-ы). Прошло — Freight становится пригодным для следующей стадии; не прошло — дальше не едет.

Как груз едет по конвейеру

  flowchart LR
    subgraph SRC["Источники"]
        GIT["git"]
        IMG["image registry"]
        HELM["Helm chart"]
    end
    WH["Warehouse<br/>следит за источниками"]
    FR["Freight<br/>снимок: commit + image + chart"]
    GIT & IMG & HELM --> WH --> FR

    FR --> DEV["Stage: dev<br/>promotion → verify"]
    DEV -->|прошло| TST["Stage: stage<br/>promotion → verify"]
    TST -->|прошло + approval| PRD["Stage: prod"]

    DEV -.правит git.-> ACD["Argo CD<br/>синхронизирует кластер"]
    TST -.правит git.-> ACD
    PRD -.правит git.-> ACD

Поток по шагам:

1. Warehouse замечает новый образ/коммит/чарт → собирает Freight (фиксирует версии вместе).
2. Стадия dev подписана на этот Warehouse → Promotion правит git (тег образа), Argo CD синхронизирует dev.
3. Проходит Verification (тесты, AnalysisRun). Если ок — этот Freight помечается пригодным для следующей стадии.
4. Стадия stage подписана на выход dev → тот же Freight едет дальше (авто или по approval).
5. prod обычно требует ручного подтверждения. Версия, доехавшая до prod, — ровно та же, что проверялась на dev/stage, а не «пересобранная заново».

Главное здесь — иммутабельность Freight: по всей цепочке едет один и тот же зафиксированный набор артефактов, поэтому «на проде другое, чем на stage» становится структурно невозможным.

Как это ложится на Argo CD

Разделение ответственности простое:

• Argo CD — «привести кластер к состоянию git» (reconcile, sync, self-heal).
• Kargo — «решить, какая версия и когда попадает в git каждого окружения» (промоушен, проверки, порядок, approvals).

Kargo не лезет напрямую в кластер вместо Argo CD — он работает через тот же GitOps-репозиторий. Поэтому его можно добавить к существующему Argo CD-сетапу, не переписывая раскатку.

Когда стоит и когда нет

Стоит присмотреться, если:

• у вас несколько окружений и продвижение версий склеено скриптами в CI или ручными PR-ами;
• нужна воспроизводимость «то, что на проде, — это ровно то, что проверяли»;
• хочется наглядной картины «какой Freight на какой стадии» и истории промоушенов;
• уже есть Argo CD и progressive delivery (Argo Rollouts) — Kargo встаёт рядом естественно.

Скорее не нужен, если:

• окружение одно, и «промоушена» как процесса нет — тогда это лишние CRD;
• команда не готова к ещё одному набору абстракций (Warehouse/Freight/Stage) поверх Argo CD;
• нужен стабильный «скучный» прод прямо сейчас: проект живой и молодой (хоть и от команды Argo) — стоит закладывать чтение changelog и тесты обновлений.

Итог

Kargo берёт на себя то, что Argo CD сознательно оставляет за скобками, — продвижение релиза по цепочке окружений — и превращает его из россыпи CI-скриптов в декларативный GitOps-конвейер с иммутабельным Freight и проверками на каждом шаге. Если вы уже на Argo CD и промоушены болят — это самый органичный кандидат посмотреть. Если окружение одно — не усложняйте.

Ссылки: kargo.io · docs.kargo.io · github.com/akuity/kargo .