Argo CD в продакшне: три приложения переведены, дрейф конфигурации стал видимым

В июле мы разобрались с выбором между Flux и Argo CD и остановились на Argo CD. С тех пор прошло несколько месяцев, и мы наконец-то перевели три продакшн-приложения одного из клиентов с ручного kubectl apply на полноценный GitOps через Argo CD 1.2. Пора написать, что из этого вышло.

Почему именно сейчас

Версия 1.2 вышла в августе и принесла несколько вещей, которые нас тормозили раньше. RBAC стал нормально работать с несколькими проектами - раньше приходилось либо давать слишком широкие права, либо мириться с тем, что разработчики видят чужие приложения. Теперь Project-абстракция в Argo CD достаточно зрелая, чтобы разграничить окружения одного клиента между командами.

Второй момент - health checks для кастомных ресурсов. У клиента в кластере живёт несколько CRD от сторонних операторов, и до 1.2 Argo CD честно говорил Healthy для всего подряд, не умея заглянуть внутрь. Теперь можно описать свою логику проверки на Lua.

Что и как переводили

Выбрали три сервиса: два бэкенда и один воркер. Все три уже жили в Helm-чартах, что упростило задачу - Argo CD умеет рендерить Helm и хранить только values.yaml в Git, без зафиксированных манифестов.

Схема получилась такая:

Git-репо (values.yaml, kustomize-оверлеи)
        |
     Argo CD
        |
  Kubernetes-кластер (prod namespace)

На каждый сервис - отдельный Application-ресурс в Argo CD. Политика синхронизации поначалу выставили в ручную: Argo CD показывает дрейф, но сам не применяет. Хотели сначала посмотреть, как часто будет что-то расходиться.

Дрейф - вот где неожиданно интересно

Первое, что бросилось в глаза после подключения - кластер уже расходился с Git. Не сильно, но несколько мест нашлось сразу.

Ресурсные лимиты на одном из деплойментов кто-то подправил руками kubectl edit две недели назад - видимо, во время инцидента, а обратно в чарт не вернул. В Git были одни значения, в кластере другие.

ConfigMap с feature-флагами содержал ключ, которого в репозитории не существовало вовсе. Откуда взялся - никто уже не помнил. Скорее всего, кто-то добавил для отладки и забыл.

Количество реплик воркера расходилось: в Git стояло 2, в кластере крутилось 3. Кто-то масштабировал руками и не зафиксировал.

Всё это жило в кластере тихо и никому не мешало, пока Argo CD не сделал это видимым. Раньше такое всплывало либо при следующем деплое (когда всё перезатиралось), либо случайно - когда кто-то смотрел на kubectl get и замечал несоответствие. Теперь дашборд сразу показывает жёлтым: вот три ресурса не совпадают с репозиторием.

Автосинк: осторожно включили

После двух недель в режиме наблюдения включили автоматическую синхронизацию - но только для двух из трёх сервисов. Воркер оставили на ручной: у него есть состояние в Redis, и автоматическое пересоздание пода в неудачный момент может привести к потере задач из очереди. Это не ограничение Argo CD, просто специфика приложения.

Для остальных двух автосинк работает с опцией selfHeal: true - если кто-то залезет руками в кластер и поменяет что-то, Argo CD через несколько минут вернёт всё в соответствие с Git. Психологически это немного непривычно: инженеры первое время рефлекторно тянулись к kubectl edit, а потом обнаруживали, что их правки откатились. Пришлось объяснить: хочешь изменить - меняй в Git.

Про health checks

Для стандартных ресурсов - Deployment, Service, Ingress - Argo CD определяет состояние корректно из коробки. Для одного кастомного оператора написали простую Lua-функцию: смотрит на .status.phase и возвращает Healthy/Progressing/Degraded. Заняло минут двадцать, работает нормально.

Отдельный плюс - в момент деплоя видно, как поды поочерёдно пересоздаются, и Argo CD ждёт, пока каждый не перейдёт в Ready, прежде чем считать синхронизацию завершённой. Раньше CI/CD-пайплайн у клиента просто применял манифесты и считал задачу выполненной, не проверяя реальное состояние.

Что дальше

Четвёртое приложение - фронтенд со статикой через CDN - пока держим отдельно: там немного другая схема деплоя, и нужно аккуратнее интегрировать со сборочным пайплайном в GitLab CI.

В managed-инфраструктуре мы теперь используем Argo CD как стандартный инструмент для новых клиентских кластеров. Установка занимает около часа включая настройку RBAC и подключение репозитория, что вполне разумно.

Главное, что мы вынесли за эти месяцы: ценность GitOps не в том, что деплои стали быстрее или удобнее. Ценность в том, что расхождение между тем, что есть в кластере, и тем, что должно быть по документам, перестало быть невидимым. Дрейф конфигурации существовал всегда - просто теперь он не может тихо жить месяцами.