GitOps переносит желаемое состояние инфраструктуры в Git, а кластер приводит себя к нему автоматически. Argo CD — распространённый инструмент такого подхода: он живёт внутри Kubernetes, следит за репозиторием и показывает расхождения между Git и реальными объектами. В статье — установка, первый Application, политика синхронизации, структура репозитория и диагностика ошибок.

Как работает Argo CD

В отличие от push-модели, где CI-система получает доступ к кластеру и применяет манифесты, Argo CD работает по pull-модели. Контроллер внутри кластера сам обращается к Git-репозиторию, рендерит манифесты и сравнивает их с живыми объектами. Если кластер отклонился от Git, приложение получает статус OutOfSync; если включена автоматическая синхронизация, контроллер исправляет расхождение.

В состав входят API-сервер с веб-интерфейсом и CLI, repo-server для Git и Helm, application-controller для сравнения и синхронизации, Redis и компонент аутентификации. Приложение описывается ресурсом Application, а права и границы — AppProject.

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

Для знакомства подойдёт официальный манифест stable. В продакшене лучше зафиксировать конкретную версию и хранить манифест установки в своём репозитории, чтобы обновление было осознанным.

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl -n argocd get pods -w
kubectl -n argocd port-forward svc/argocd-server 8080:443

После запуска откройте https://localhost:8080. Начальный пароль администратора лежит в секрете; получите его командой и сразу смените. Не оставляйте сервер с самоподписанным сертификатом и паролем по умолчанию в публичной сети.

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath='{.data.password}' | base64 -d
argocd login localhost:8080 --username admin --insecure
argocd account update-password
argocd version

Флаг --insecure отключает проверку сертификата; для локального port-forward это допустимо, для постоянного адреса настройте TLS.

Первый Application

Application связывает Git-источник, путь внутри репозитория и целевой кластер с пространством имён. Минимальный манифест выглядит так:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: web
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://git.example.com/platform/apps.git
    targetRevision: main
    path: apps/web/overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: web
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Поле path указывает на каталог с Kustomize или Helm-чартом. targetRevision может быть веткой, тегом или конкретным коммитом; для продакшена тег или коммит надёжнее плавающей ветки. CreateNamespace=true разрешает Argo CD создать пространство имён, если его нет.

kubectl apply -f application.yaml
argocd app list
argocd app get web
argocd app sync web

Автоматическая синхронизация и волны

Автоматическая синхронизация избавляет от ручных запусков, но prune: true удаляет объекты, которых больше нет в Git. В продакшене включайте prune после того, как убедились в корректности разметки и бэкапов. selfHeal: true возвращает кластер к состоянию Git при ручных изменениях, что полезно, но может мешать отладке.

syncPolicy:
  automated:
    prune: true
    selfHeal: true
  retry:
    limit: 5
    backoff:
      duration: 10s
      factor: 2
      maxDuration: 5m

Порядок применения задаётся аннотацией argocd.argoproj.io/sync-wave. Объекты с меньшим номером создаются раньше: сначала namespace и CRD, затем операторы, потом приложения. Хуки PreSync и PostSync позволяют выполнить миграцию или проверку, но злоупотреблять ими не стоит: долгие задачи усложняют откат.

Структура репозитория

Рабочая схема — приложения и окружения поверх общих base-манифестов. Kustomize переопределяет образ, реплики и параметры для staging и production без копирования YAML. Helm-чарты подключаются через helm.valueFiles и releaseName.

apps/web/base/deployment.yaml
apps/web/base/service.yaml
apps/web/overlays/staging/kustomization.yaml
apps/web/overlays/prod/kustomization.yaml
argocd/applications/web-prod.yaml

Не храните в Git пароли, токены и приватные ключи. Для секретов используйте External Secrets Operator, Sealed Secrets или аналогичное решение, а в репозитории держите только ссылки на хранилище. Отдельно проверяйте, что в Git не попали kubeconfig и значения с паролями.

Если приложений и кластеров много, ApplicationSet генерирует Application по шаблону из списка кластеров или каталогов. Это уменьшает копипаст, но ошибка в шаблоне сразу размножается на все окружения.

RBAC, проекты и доступ

AppProject ограничивает, из каких репозиториев можно брать манифесты и в какие кластеры и namespace разрешено деплоить. Даже в небольшой команде лучше создать отдельные проекты для команд или окружений, чем давать всем доступ к default.

kubectl -n argocd get configmap argocd-rbac-cm -o yaml
kubectl -n argocd get appproject default -o yaml
argocd proj list
argocd account list

Аутентификацию удобно вынести в OIDC-провайдера, а роли описать в policy.csv. Встроенный admin оставьте для аварийного доступа и храните его пароль в менеджере секретов. Для Git-репозиториев используйте deploy key с правом чтения, а не личный токен администратора.

Диагностика расхождений

При проблеме смотрите статус приложения и события. argocd app get показывает синхронизированное и живое состояние, а --refresh заставляет перечитать Git. Если приложение застряло в Progressing, проверьте health-статусы объектов и события в namespace.

argocd app get web --refresh
argocd app diff web
argocd app history web
kubectl -n argocd logs deploy/argocd-repo-server --tail=100

Типичные причины: недоступен репозиторий или неверный путь; Kustomize не собирает манифест; в кластере есть admission webhook, который меняет объект после применения; не хватает RBAC; Helm-чарт требует значений, которых нет. Для ошибок repo-server смотрите его логи, для ошибок применения — kubectl describe и события.

Откат делается через историю: argocd app rollback web с номером ревизии. Помните, что откат возвращает манифесты, но не данные приложения; миграции базы данных нужно продумывать отдельно и делать совместимыми с предыдущей версией.

Чек-лист перед продакшеном

  • Версия Argo CD зафиксирована, манифест установки хранится в Git.
  • Настроены TLS, SSO и роли; admin используется только для аварий.
  • Секреты не лежат в Git в открытом виде.
  • Автоматический prune включён только после проверки разметки и бэкапов.
  • Настроены уведомления о деградации приложений и ошибках синхронизации.
  • Есть регламент обновления Argo CD и проверки совместимости CRD.

Argo CD не заменяет CI: сборка образов, тесты и сканирование уязвимостей остаются за конвейером. Его задача — доставить проверенное состояние в кластер и не дать ему отклониться. Начните с одного приложения и окружения, затем добавляйте проекты и автоматизацию.

Итог

Argo CD даёт прозрачную модель GitOps: Git хранит желаемое состояние, кластер постоянно сверяется с ним, а все изменения проходят через историю коммитов. Для старта достаточно установить контроллер, описать Application и включить синхронизацию вручную; автоматизацию и prune добавляйте после того, как научились читать diff и статусы. Главные риски — секреты в репозитории, слишком широкие права и необдуманный автоматический prune. При аккуратной настройке Argo CD заметно снижает долю ручных kubectl apply и делает деплой воспроизводимым.

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

Поделиться: Telegram ВКонтакте