ArgoCD 0.x: GitOps-контроллер для Kubernetes, первое знакомство

Несколько недель назад в одном из managed-проектов нам понадобилось разобраться с дрейфом конфигурации. Сценарий классический: в кластере что-то поменяли руками - «временно», разумеется, - потом это «временно» прожило несколько месяцев и успело стать частью реальности, о которой знал ровно один человек. Когда тот человек ушёл в отпуск, выяснять что происходит пришлось через kubectl describe и историю терминала.

Именно тогда мы решили наконец потрогать ArgoCD руками.

Что такое ArgoCD и почему сейчас

ArgoCD - это GitOps-контроллер для Kubernetes. Идея простая: есть git-репозиторий с манифестами (или Helm-чартами, или Kustomize), и есть кластер. ArgoCD следит за тем, чтобы состояние кластера соответствовало тому, что написано в репозитории. Расхождение - значит OutOfSync, можно синхронизировать вручную или автоматически.

Проект сейчас на версии 0.x - в production у него довольно активное коммьюнити и несколько серьёзных адаптеров из CNCF-экосистемы. Но называть его боевым инструментом без оговорок мы бы не стали: это 0.x, API ещё может меняться. Тем не менее для тестового кластера - самое то.

Как разворачивали

Поставили в отдельный namespace argocd, всё через официальные манифесты из репозитория проекта. Занял процесс от kubectl apply до рабочего UI примерно двадцать минут, включая время разобраться с ingress - нам нужен был внешний доступ, а не только port-forward.

ArgoCD разворачивается как несколько компонентов:

• argocd-server - API-сервер и UI, через него ведётся вся работа.
• argocd-repo-server - отдельный сервис для работы с git-репозиториями и рендеринга манифестов.
• argocd-application-controller - собственно контроллер, который следит за состоянием приложений в кластере.
• argocd-dex-server - SSO-интеграция, если нужна; в нашем случае пока просто базовая аутентификация.

Подключили тестовый репозиторий с несколькими Helm-чартами, создали первое Application через UI. Кластер-цель - тот же, где живёт ArgoCD. Через минуту приложение появилось в Synced состоянии.

Что изменилось в ощущениях

Первое и самое важное: ты видишь расхождение. Если кто-то сделал kubectl edit deployment или применил манифест вне git - ArgoCD это покажет как OutOfSync. Это не ловит нарушителей и не запрещает руками не трогать, но теперь видно, что факт расхождения есть. Раньше такого видения не было вообще.

Второе: git становится фактическим source of truth, а не декларативным намерением на листочке. Когда у тебя автоматическая синхронизация включена - кластер сам возвращается к состоянию из репозитория, если кто-то что-то руками поменял. Это двойственное ощущение: с одной стороны, порядок; с другой, «а вдруг кто-то правил по делу?» - и тут важно договориться о процессе заранее.

Третье: история деплоев видна через git. Коммит - деплой. Откат - это git revert плюс синхронизация, а не helm rollback с его артефактами в памяти tiller (который в Helm 2 живёт в кластере и тоже является состоянием вне git).

Что не всё так гладко

ArgoCD 0.x - это 0.x. Мы словили пару странных поведений. Одно из них: при определённых конфигурациях Helm-чарта с условными блоками внутри шаблона ArgoCD не всегда корректно рендерил diff - показывал изменение там, где его не было. Неприятно, но не критично для тестовой установки.

RBAC в самом ArgoCD настроен довольно грубо по умолчанию - нужно потратить время на проекты и политики, если у тебя не один человек работает с системой. Мы пока оставили базовую конфигурацию, но для production так явно не пойдёт.

Интеграция с Helm происходит через встроенный рендер манифестов - ArgoCD сам вызывает helm template, поэтому tiller не нужен. Это плюс с точки зрения безопасности, но означает, что некоторые Helm-хуки (post-install, pre-upgrade) не срабатывают - ArgoCD работает только с итоговыми манифестами.

Куда смотреть дальше

Нас сейчас интересуют две вещи. Первая - шаблонизация Application-объектов: при нескольких однотипных проектах хочется не дублировать конфиги вручную, и мы смотрим, как это решается на уровне CI или внешних скриптов. Вторая - разграничение доступа через Projects: у нас несколько команд, и каждой нужен свой namespace с ограниченными правами на синхронизацию.

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

Пока впечатление положительное. Главное что мы вынесли: инженеры перестают быть живыми носителями состояния кластера - оно теперь в репозитории, и туда можно заглянуть.