GitOps в Kubernetes: выбираем между Flux и Argo CD для продакшна

Слово «GitOps» уже год как ходит по конференциям и статьям - принцип понятен: Git-репозиторий является единственным источником правды о состоянии кластера, а специальный оператор следит за тем, чтобы реальность совпадала с тем, что лежит в репо. Звучит просто, но как только доходит до выбора конкретного инструмента, начинается «ну смотря что вам нужно».

Нам нужно было нечто конкретное: managed-инфраструктура нескольких клиентов, Kubernetes, деплои по несколько раз в день, и инженеры заказчика, которые хотят видеть, что происходит с их кластером, не залезая в kubectl.

Мы посмотрели на двух основных кандидатов - Flux от Weaveworks и Argo CD от Intuit.

Flux: работает через пятнадцать минут

Flux устроен просто. Один оператор в кластере, один git-репозиторий, один namespace по умолчанию. Установка - несколько строчек через Helm или kubectl apply. Оператор опрашивает репозиторий по интервалу, видит изменения манифестов, применяет их. Всё.

Дополнительно Flux умеет следить за container registry: появился новый образ с нужным тегом - оператор сам обновит манифест в репо и закоммитит. Это нетривиальная фича, которая убирает отдельный шаг из CI-пайплайна.

На тестовом кластере Flux запустился без единой проблемы. Helm-оператор (Helm Operator, отдельный компонент) подхватил HelmRelease-ресурсы, всё задеплоилось. Мы потратили на это, с учётом экспериментов с конфигурацией, порядка часа.

Что неудобно: нет UI вообще. Статус синхронизации - только через fluxctl или через логи оператора. Для нашей команды это норм, но клиент, который хочет посмотреть «а что сейчас деплоится и почему», будет смотреть в пустоту. Аудит - только git-история, что в целом честно, но не интерактивно.

Ещё момент: Flux в текущем виде работает на уровне одного репозитория и одного кластера как основная единица. Для нескольких кластеров нужно несколько инсталляций с отдельной конфигурацией каждой - никакого centralized view.

Argo CD: чуть больше возни, зато есть что показать клиенту

Argo CD - другой класс инструмента. Это полноценное приложение: API-сервер, репозиторий состояния, UI, CLI. Установка занимает больше времени - не потому что сложно, а потому что нужно разобраться с тем, как устроена аутентификация, как настроить ingress для UI, как выдать нужные роли.

После установки открывается веб-интерфейс, где видно каждое приложение, его текущий статус синхронизации, дерево ресурсов, лог последней синхронизации, diff между тем, что в Git, и тем, что в кластере.

Вот этот diff - отдельная ценность. Когда кто-то вручную поправил конфиг в кластере (это происходит, как ни запрещай), Argo CD это видит и показывает как «OutOfSync». Flux тоже это видит и молча перезапишет, но у него нет интерфейса, где можно это заметить до перезаписи.

RBAC в Argo CD тоже есть - можно выдать клиентской команде read-only доступ к своему проекту и не выдавать kubectl вообще. Это удобно, особенно когда у одного экземпляра Argo CD несколько приложений от разных команд.

Минус, который мы почувствовали сразу: ресурсоёмкость. На небольшом кластере Argo CD съедает заметно больше, чем Flux. Для dev-окружения на трёх нодах это уже ощутимо.

Что мы решили

Для продакшн-кластеров клиентов выбрали Argo CD. Аргументы: клиент хочет видеть состояние деплоя без доступа к kubectl; аудит синхронизаций важен для отчётности; OutOfSync-детекция защищает от тихих ручных изменений.

Для внутреннего dev-контура, где живут наши собственные тестовые окружения, оставим Flux - там проще, быстрее поднимается и не нужен UI.

Несколько практических наблюдений по итогам:

• Начальная настройка Argo CD. Самое неочевидное - это Dex как Identity Provider по умолчанию. Если нет OIDC, его проще отключить и перейти на local users. Документация это описывает, но не очень явно.
• Структура репозитория. Argo CD хорошо работает с kustomize из коробки. Мы разложили манифесты по директориям base/ и overlays/{staging,prod}/ - это чисто и понятно.
• Автосинхронизация. Включать ли автоматическую синхронизацию или требовать ручного подтверждения - вопрос политики. Для продакшна оставили manual sync с уведомлением в Slack, когда есть что синхронизировать.
• SSH-ключи к репозиторию. Argo CD хранит их в Kubernetes secrets. После нашей работы по RBAC-харденингу это не выглядит проблемой, но стоит убедиться, что секреты в нужном namespace не доступны лишним субъектам.

Пайплайн в итоге выглядит так: CI собирает образ, пушит в registry с тегом по sha коммита, обновляет значение в git-репозитории с манифестами, Argo CD это видит и предлагает синхронизировать (или синхронизирует сам в зависимости от среды). Секреты в пайплайн не попадают - это отдельная история, которую мы разбирали ещё в контексте обнаружения секретов в CI.

GitOps как подход нам нравится: git-история становится историей деплоев, откат - это revert коммита, состояние инфраструктуры всегда можно воспроизвести из репо. Выбор между Flux и Argo CD - это скорее вопрос того, нужен ли вам UI и multi-tenancy, или достаточно простого оператора.