За последнее время я вижу всё больше споров на тему двух популярных GitOps инструментов: Argo CD и Flux CD.
На самом деле я считаю такие споры необоснованными, потому что глубоко убеждён что внимания заслуживают оба инструмента и каждый из них хорош для решения своего круга задач.
В своей профессиональной деятельности я активно использую и тот и другой. Я хочу поделиться с вами своим мнением и кейсами использования. Надеюсь эта статья поможет вам выбрать наиболее подходящий инструмент под ваши нужды.
На самом деле тема Argo CD vs Flux CD повсеместна и порождает огромное количество лулзов, так например на KubeCon'е популярность инструментов пытались определить раздавая кексики с их логотипами. Смели их, конечно, моментально все :)
Можно придумать и менее абсурдные методы, например сравнить проекты по количеству звёзд на GitHub:
В целом нельзя отрицать что популярность Argo CD в два-три раза выше чем у Flux CD, но этому есть объяснение. Во первых Flux начинал раньше, и уже провёл работу над ошибками, выпустив вторую версию, которая теперь является основной. Так как разработка Flux2 ведется в новом репозитории то и звёздочки ему пришлось набирать заново.
Есть и другое объяснение такой популярности. ArgoCD делает ставку на графический интерфейс, а это значимый фактор по которому новички делают выбор в пользу него.
Но давайте разберёмся как следует
Встречают по одёжке
Интерфейс Argo CD и правда заслуживает отдельной похвалы. Вы только посмотрите на эту классную визуализацию ресурсов:
Важно заметить что интерфейс Argo CD позволяет не только доставлять ваши приложения, но и в некотором виде ими управлять. Например с помощью Argo CD вы можете посмотреть логи подов, поменять манифест, или даже выполнить exec в контейнер.
А с последних релизов даже настраивать свои кастомные действия.
С одной стороны это идёт немного вразрез с тем что диктуют нам практики GitOps, где Git-репозиторий должен выступать в роли источника правды. Но не стоит отрицать того факта что эти возможности не лишены смысла. Наоборот, иногда они бывают весьма полезны и очевидны для пользователя.
Хотя бы из-за того что они понятны и удобны разработчикам. Да, большинство людей предпочло бы иметь единый интерфейс для наблюдения за статусом деплоя, вместо того чтобы идти, казалось бы, более правильным путём, т.е. использования Grafana-дашборд для наблюдения за статусом деплоя, получением алертов в Slack, и чтением логов в системе логирования.
Тем не менее я считаю что инструменты должны упрощать работу, а не усложнять её. Таким образом типичному разработчику будет куда удобнее тыкать кнопочки и наблюдать за статусом деплоя в интерфейсе Argo CD чем нескольких отдельных системах, которые ещё и нужно определённым образом настроить.
С другой стороны Flux CD имплементирует что ни на есть стандартные паттерны в Kubernetes. И будучи реализованным в виде нескольких контроллеров, предлагает удобные CRD-ресурсы для настройки.
Использование данного подхода позволяет использовать Flux CD не только в качестве GitOps-инструмента, но и в качестве базы для построения других систем. На базе Flux CD основывается огромное количество сторонних решений, в том числе и наша платформа Cozystack, которая использует Flux CD как основной способ для деплоя всех системных компонентов и пользовательских приложений.
Используя Flux CD вы можете реализовать любую логику взаимодействия вашего пользователя с кластером.
Кстати, вы знали что подход GitOps не привязывает вас к использованию лишь только Git? Вместо этого GitOps просто декларирует использование паттерна оператора и метода реконсиляции для внешних источников, а такими источниками могут являться не только Git, но так же и S3 бакет, Helm-репозиторий или вообще что угодно.
Порог входа
Оба инструмента устанавливаются очень просто, и предлагают быстрый старт. Но делают это разными путями. Argo CD даёт вам интуитивно понятный графический интерфейс.
Flux CD предлагает простой и интуитивный CLI, который автоматически настраивает токены в GitHub / GitLab и интеграцию с вашим Kubernetes кластером, а так же умеет генерировать YAML-манифесты и складывать их в вашем репозитория, приучая, тем самым к правильной организации.
Безопасность
Оба инструмента используют разные подходы в организации безопасности.
Модель деплоя
В Argo CD у вас есть две стадии: сначала у вас вызывается configuration плагин, который рендерит манифесты в YAML (например, с помощью команды helm template), уже потом отрендеренные YAML применяются в кластер (ака. kubectl apply).
Очень удобно что вы можете описывать конфигурацию в удобном вам формате, и на моменте применения этой конфигурации, видеть что конкретно применяется в кластер. Его live и desired состояние и diff между ними.
Но данный подход имеет и минусы, потому что GitOps Engine, так называется движок применения манифестов в кластер, который использует Argo CD, не всегда полностью совместим со всеми Helm-хуками, лукапами и прочим.
Кроме того в ваших Helm-чартах не должно быть дрифта, это когда два вызова helm template возвращают чуть-чуть разные манифесты. Такое можно часто наблюдать если в Helm-чарте предусмотрена генерация случайных паролей или сертификатов. В противном случае вы будете видеть постоянный рассихрон.
В FluxCD используются нативные методы установки, поэтому установленные таким образом Helm чарты поддерживают все заложенные в них функции. Но следить за изменениями уже не так просто и придётся отлавливать их на этапе код ревью.
К примеру, вы не всегда сможете понять к какому конкретно состоянию приведёт установка того или-иного Helm-чарта с go-темплейтами. Вам придётся их рендерить у себя в голове, либо придумывать дополнительную логику для вашего пайплайна.
Модель доступа
Отдельно хочется уточнить что для управления доступом Flux CD переиспользует стандартную модель RBAC, что не может не радовать.
ArgoCD имплементирует свою собственную модель, а группы и права доступа настраиваются в CSV-подобном формате, что неудобно использовать как-либо кроме как через веб-интерфейс.
Несмотря на это, своим функционалом Argo CD закрывает почти все потребности среднестатистического Kubernetes-пользователя, именно поэтому у вас появляется возможность закрыть доступ разработчиков к Kubernetes и контролировать их доступы только полагаясь на примитивы Argo CD.
Со стороны Flux CD тоже часто практикуется запрет прямого доступа разработчиков в Kubernetes, но на практике он чуть более сложно применим, ввиду того что вам нужно предложить что-то взамен, какой-то другой удобный путь для просмотра логов и состояния деплоя. Ведь удобство локальной разработки - это очень важная вещь прежде чем вы сможете "продать" это решение вашим разработчикам.
Во Flux CD можно также отключить деплой под кластер админом, и требовать обязательного указания сервис аккаунта с ограниченными правами для установки релизов.
Расширяемость
Argo CD расширяется не легко, а очень легко! На уровне кластера вы можете описать дополнительные плагины, для запуска которых будет достаточно запустить бинарник с аргументами или выполнить произвольный shell-скрипт. Задача которого - получить на вход директорию с исходниками проекта и вернуть из неё протой набор YAML-манифестов готовых для применения в кластер.
Стоит отметить что Argo CD по умолчанию никак не решает вопрос менеджмента секретов, ссылаясь на сторонние решения. Именно поэтому такие configuration плагины чаще всего используются для того чтобы обучить Argo CD хоть как-то работать с секретами. Например внедрить helm secrets чтобы автоматически расшифровывать их из репозитория.
Flux CD в свою очередь расширяется не так просто, но уже из коробки имеет всё необходимое, есть поддержка SOPS (для хранения секретов в репозитории в зашифрованном виде), а также часто предлагает использовать возможность накладывать патчи Kustomize на Helm, когда вам не хватает стандартной логики заложенной в чарт.
Написать отдельный Flux CD контроллер можно, но для этого нужны серьёзные усилия, потому что это уже будет являться отдельным проектом, а не простым dirty-хаком как в Argo CD.
Масштабируемость
Оба решения могут масштабироваться путём увеличения числа инстансов. ArgoCD по умолчанию хранит все свои ресурсы в одном неймспейсе. Flux CD умеет выбирать и обслуживать ресурсы по лейблам, тем самым реализуя шардирование.
Здесь стоит упомянуть про две разные парадигмы использования этих двух решений. Когда Flux CD обычно устанавливается отдельно в каждый кластер, и выполняет роль GitOps-оператора, который непременно устанавливает всё в свой локальный кластер. Argo CD чаще подразумевает единый интерфейс для управления множеством кластеров.
Но когда у вас несколько проектов и/или команд разработчиков, лучше деплоить несколько независимых инстансов Argo CD для каждой из них. Причины две: смысла держать в одном Argo CD два независимых проекта особо нет, но так лучше масштабируемость и реже конфликты связанные с названием приложений.
Другими словми:
Argo CD я бы деплоил per-tenant, где каждый тенант - это независимая команда разработчиков со своими приложениями, но кластеров в нём может быть несколько, например dev/stage/prod и т.п.
Flux CD я бы деплоил per-cluster, потому что Flux CD скорее расширяет Kubernetes, привнося в него примитивы для деплоя из Git и других источников.
Заключение
Вот мы и подобрались к самому интересному, к заключению. Теперь вам стоит принять выбор в пользу Argo CD или Flux CD. Для этого я предлагаю сначала задать вам самому себе вопрос: какую конкретно задачу вы хотите решить.
Вам нужен инструмент для кого, чтобы упростить администрирование кластеров или чтобы упростить разработчикам доставку их приложения?
К примеру, если вы собираетесь деплоить множество готовых инфраструктурных чартов через Argo CD, готовьтесь к тому что их придётся допиливать напильником. Всё потому что далеко не все чарты пишутся с учётом что бы они работали со сторонними configuration management системами, вроде Argo CD
Flux CD при деплое использует нативный Helm, поэтому все lookup'ы, хуки и capabilities работают просто из коробки. Вам не придётся допиливать чарты - поэтому его любят в первую очередь админы.
Argo CD очень любят разработчики, к тому же за ненадобностью можно отобрать у них все права в Kubernetes и предоставить готовый интерфейс для управления деплоем, где они смогут: и за процессом понаблюдать, и логи посмотреть, и рестартануть какой-нибудь под. Уверяю вас, они будут просто счастливы!
Ещё есть несколько корнер-кейсов, к примеру:
Если вы хотите деплоить унифицировано, одинаковый набор компонентов в большое количество кластеров, то лучше сделать выбор в пользу Flux CD. Ввиду использования парадигмы, где чаще всего используется отдельный независимый контроллер на каждый Kubernetes кластер.
Если вы желаете поскорее внедрить GitOps, а ваша команда разработчиков и инфраструктура к этому ещё не готова. Если ваши разработчики хотят выполнять операции вроде рестарта отдельных подов, exec в контейнеры, а также возможность выполнять роллбэки без коммита в Git - то Argo CD может стать для вас хорошим выбором.
В любом случае, ничто не мешает вам использовать и то и другое.
