ArgoCD и GitOps: основы

MAATRIX

Если у вас уже есть Kubernetes-кластер и в него деплоят через kubectl apply вручную с ноутбука разработчика — рано или поздно это ударит по вам: кто-то накатил не тот манифест, кто-то забыл откатить хотфикс, а через месяц никто не может сказать, что вообще сейчас крутится в проде. GitOps решает именно эту проблему, а ArgoCD — самый распространённый инструмент, который эту идею реализует для Kubernetes. Разберём, что это такое, чем полезно и когда вообще не нужно.

Что такое GitOps на самом деле

GitOps — это не инструмент и не продукт, а подход к управлению инфраструктурой, где git-репозиторий объявлен единственным источником истины (source of truth) о желаемом состоянии системы. Звучит абстрактно, поэтому разложим на три конкретных следствия.

Во-первых, всё описание инфраструктуры — манифесты Kubernetes, Helm-чарты, Kustomize-оверлеи — лежит в git как обычный код. Не в head у DevOps-инженера, не в закладках Confluence, а в репозитории с историей коммитов.

Во-вторых, любое изменение состояния попадает в кластер через pull request, а не через прямой kubectl apply на проде. Хотите изменить количество реплик сервиса или обновить образ — открываете PR, кто-то его ревьюит, мержите в основную ветку. Ручной доступ к продакшен-кластеру для рутинных изменений в идеале вообще не нужен.

В-третьих, есть агент (в нашем случае ArgoCD), который постоянно сравнивает фактическое состояние кластера с тем, что описано в git, и либо сам приводит кластер в соответствие, либо просто сигнализирует о расхождении (drift) — это зависит от режима синхронизации.

Разница с классическим CI/CD-подходом (push-модель) принципиальная. В push-модели CI-раннер (например, GitLab CI) после сборки образа сам стучится в кластер и что-то в нём меняет — у раннера должны быть credentials с правами на кластер, и он инициирует изменение. В GitOps-модели (pull-модель) наоборот: агент внутри кластера сам вытягивает изменения из git, credentials наружу утекать не должны в принципе, а инициатор изменения — сам кластер, а не внешняя система.

Push-модель (классический CI/CD):
  CI-раннер --[credentials, kubectl apply]--> Kubernetes-кластер

Pull-модель (GitOps):
  Kubernetes-кластер --[ArgoCD тянет манифесты]--> git-репозиторий

Зачем это нужно: реальные проблемы, которые решает GitOps

Разберём конкретные боли, из-за которых команды приходят к GitOps.

Drift и «а что вообще сейчас в проде». Без GitOps со временем накапливается расхождение между тем, что описано в манифестах (если они вообще актуальны), и тем, что реально запущено. Кто-то через kubectl edit поправил ConfigMap на живую, забыл зафиксировать в репозитории — и через полгода никто не помнит, почему сервис ведёт себя именно так.

Аудит и откат. Git-история — это готовый журнал изменений инфраструктуры с автором, временем и причиной (commit message, PR-обсуждение). Откат — это git revert, а не попытка вспомнить, что было час назад.

Права доступа. CI-раннеру или разработчику не нужен прямой kubectl-доступ к продакшен-кластеру — доступ есть только у ArgoCD внутри кластера, а снаружи всё происходит через git с обычным PR-флоу и review.

Множественные окружения. Staging, prod, разные регионы описываются как отдельные Kustomize-оверлеи или Helm-values поверх общей базы — различия видны в diff, а не разбросаны по головам команды.

Здесь важна честность: GitOps не решает проблему плохих манифестов и не заменяет тестирование. Если в PR замержили конфиг с ошибкой — ArgoCD его так же исправно раскатит, просто теперь откат будет быстрее и прозрачнее.

Как работает ArgoCD

ArgoCD — это контроллер, который сам работает как набор подов внутри Kubernetes-кластера (или подключается к нескольким кластерам с одного управляющего). Логика работы простая и цикличная.

1. Вы описываете Application — CRD ArgoCD, где указываете: откуда брать манифесты (git-репозиторий, ветка/тег, путь), куда деплоить (кластер, namespace) и как синхронизировать (auto или manual).
2. ArgoCD с заданным интервалом (по умолчанию около 3 минут, плюс webhook для мгновенного триггера) опрашивает git-репозиторий и сравнивает его содержимое с реальным состоянием ресурсов в кластере.
3. Если есть расхождение — ArgoCD показывает статус OutOfSync. В режиме manual sync здесь всё останавливается, и человек вручную нажимает «Sync» в UI или через CLI. В режиме auto sync ArgoCD применяет изменения сам.
4. После применения ArgoCD проверяет здоровье ресурсов (Health) — учитывает readiness/liveness подов, состояние Deployment, Ingress и так далее — и показывает статус Healthy или Degraded.

Пример минимального Application-манифеста:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-service
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example/my-service-manifests.git
    targetRevision: main
    path: overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: my-service
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Обратите внимание на два флага в automated: prune: true значит, что ArgoCD удалит из кластера ресурсы, которых больше нет в git (а не просто оставит висеть), а selfHeal: true значит, что если кто-то вручную поправит ресурс через kubectl edit в обход git — ArgoCD откатит это изменение обратно к состоянию из репозитория при следующей проверке. Это и есть механизм, который реально держит кластер и git в соответствии друг другу, а не просто сигнализирует о расхождении.

Установка ArgoCD в кластер

Коротко — сам процесс несложный, если Kubernetes-кластер уже поднят и kubectl настроен на доступ к нему.

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Дождитесь, пока все поды в namespace argocd перейдут в Running:

kubectl get pods -n argocd -w

Для доступа к веб-интерфейсу проще всего временно пробросить порт:

kubectl port-forward svc/argocd-server -n argocd 8080:443

Начальный пароль admin-пользователя лежит в секрете, который ArgoCD создаёт при первом старте:

kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d

Для продакшена port-forward, конечно, не вариант — обычно перед ArgoCD ставят Ingress с TLS-терминацией (тот же nginx-ingress или Traefik, которые вы, скорее всего, и так используете в кластере для остальных сервисов) либо LoadBalancer-сервис.

После входа под admin первым делом стоит сменить пароль через CLI (argocd account update-password) и подключить SSO, если он у вас уже настроен для команды — держать общий admin-пароль на несколько человек в проде не лучшая идея.

Веб-интерфейс и повседневная работа

UI ArgoCD — это, пожалуй, главная причина его популярности по сравнению с более минималистичными альтернативами вроде Flux. На главном экране — карточки всех Application'ов с их статусом Sync (Synced / OutOfSync) и Health (Healthy / Degraded / Progressing).

Открыв конкретное приложение, вы видите граф ресурсов: Deployment, ReplicaSet, поды, Service, Ingress — всё как дерево с наглядной связью «кто из чего порождён». Это удобно, когда нужно быстро понять, почему под не стартует: не нужно вручную бегать по kubectl describe, всё видно на графе с цветовой индикацией проблемного узла.

Там же доступны:

• ручной Sync с превью диффа (что именно изменится) перед применением;
• просмотр логов пода прямо из UI;
• History and Rollback — список предыдущих синхронизаций с возможностью в один клик откатиться на любую из них;
• сравнение желаемого манифеста (из git) и живого состояния ресурса построчно.

Для команд, где кластером пользуется несколько человек с разным уровнем доступа, ArgoCD поддерживает RBAC поверх Projects — можно ограничить, кто какие Application'ы видит и может синхронизировать, и из каких репозиториев/namespace вообще разрешено разворачивать.

Кому эта статья реально полезна — и когда ArgoCD не нужен

Важный честный момент: ArgoCD — инструмент экосистемы Kubernetes. Он работает через Kubernetes API, оперирует CRD и ресурсами кластера. Если у вас нет и не планируется Kubernetes — устанавливать ArgoCD незачем, это решение конкретной проблемы (управление состоянием десятков и сотен ресурсов в кластере через декларативный git-источник), которой у вас просто нет.

Эта статья полезна вам, если:

• вы уже используете Kubernetes (в том числе k3s — легковесный дистрибутив, который тоже отлично работает с ArgoCD) в проде или на стадии подготовки к продакшену;
• у вас несколько окружений (dev/staging/prod) или несколько кластеров, и вручную синхронизировать их состояние стало утомительно;
• команда выросла настолько, что прямой kubectl-доступ к проду у каждого стал риском, а не удобством.

Если у вас классический VPS-деплой без Kubernetes — один или несколько серверов, Docker Compose, systemd-сервисы — то ArgoCD не подходит по архитектуре, но сама идея GitOps (git как источник истины, автодеплой по пушу) реализуется значительно проще: связка webhook + git pull + перезапуск сервиса. Например, GitHub/Gitea webhook дёргает небольшой скрипт на сервере, который тянет изменения из репозитория и перезапускает контейнер через docker compose up -d — это тот же принцип pull-модели без Kubernetes и без CRD-контроллеров. Мы разбирали такой подход в статье про автодеплой из git на сервере и типичные грабли этого сценария — частые ошибки автодеплоя.

Если вы ещё выбираете между полноценным Kubernetes и более лёгкими вариантами (или между Kubernetes и Docker Swarm) для своего VPS — посмотрите сравнение k3s против Docker Swarm: ArgoCD одинаково хорошо работает с полноценным Kubernetes и с k3s, разница только в том, что k3s проще поднять на одном-двух серверах.

Частые вопросы