Argo CD — это инструмент, который берёт идею GitOps и доводит её до удобного для человека состояния. Он следит за Git-репозиториями с манифестами Kubernetes и делает так, чтобы кластеры автоматически приходили к тому виду, который описан в этих репозиториях. Конфигурация живёт в Git, а Argo просто не даёт кластерам самопроизвольно «уплывать» от этого описания.
Логика работы примерно такая: у вас есть «правильное» состояние в Git — набор конфигов, helm-чартов, kustomize-патчей. Argo CD периодически сравнивает его с тем, что реально задеплоено в кластере. Если видит расхождения, то либо автоматически применяет недостающие изменения, либо помечает приложение как OutOfSync и ждёт вашей команды.
Что Argo CD умеет из полезного:
- Синхронизация с Git — как только в репозитории появляется новый коммит, можно автоматически подтянуть его в кластер;
- Автовосстановление — если кто-то руками поправил ресурсы в кластере, Argo может вернуть всё к состоянию из Git;
- Визуализация — удобный веб-интерфейс с деревом ресурсов, статусов, логами и историей;
- Поддержка разных форматов — работает с Helm, Kustomize, обычным YAML, Jsonnet;
- Откаты — состояние можно откатить через
git revert, а Argo подтянет соответствующую версию; - RBAC и SSO — можно нормально разграничить доступы и привязать Argo CD к корпоративной авторизации.
Все эти настройки Argo видит через собственный CRD-ресурс Application. В нём вы описываете, откуда брать манифесты (репозиторий, ветка, путь), куда их класть (кластер, namespace) и как именно синхронизировать (авто или вручную, с prune/selfHeal и так далее).
Особенно выгодно Argo CD смотреться начинает, когда у вас несколько окружений и команд: dev, stage, prod, отдельные проекты. Всё лежит в Git, Argo разруливает, кто куда деплоится, следит за здоровьем и показывает картинку в UI.
Argo CD спокойно стыкуется с другими компонентами экосистемы Argo (Workflows, Events) и CI-системами — GitHub Actions, GitLab CI, Jenkins. Получается полностью GitOps-пайплайн: CI проверил код и манифесты, залил в Git, Argo CD подхватил и развернул.
Во многих командах, где Kubernetes — основной runtime, Argo CD уже воспринимается как стандартный способ доставки: понятно, кто что сделал, когда обновилось, и всегда можно вернуться на шаг назад без танцев с бубном.
Пример Application (Argo CD + Helm) #
Пример ресурса Application, который разворачивает Redis через Helm-чарт:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: redis-app
namespace: argocd
spec:
project: default
source:
repoURL: https://charts.bitnami.com/bitnami
chart: redis
targetRevision: 17.10.1
helm:
values: |
architecture: standalone
auth:
enabled: false
destination:
server: https://kubernetes.default.svc
namespace: redis
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
Что здесь происходит #
- Argo CD подтягивает Helm-чарт Redis из внешнего репозитория Bitnami.
- Используется конкретная версия чарта —
17.10.1, а не «последняя, какая есть». - Часть значений Helm задаётся прямо внутри манифеста через блок
helm.values. - Namespace
redisбудет создан автоматически, если его ещё нет (опцияCreateNamespace=true). - Автосинхронизация включена:
prune: true— очищает лишние ресурсы, которые больше не описаны в Git;selfHeal: true— возвращает состояние, если кто-то руками поменял ресурсы в кластере.
Памятка: режимы синхронизации в Argo CD #
У Argo CD есть несколько режимов поведения при синхронизации:
- Manual — ничего само не применяется, вы жмёте Sync в UI или через CLI, когда готовы;
- Automated — любые изменения из Git автоматически накатываются в кластер;
- Prune — при синхронизации удаляются объекты, которые исчезли из конфигов в Git;
- SelfHeal — если кто-то руками поправил ресурсы в кластере, Argo вернёт их к состоянию из Git.
