Почему стоит использовать Argo CD вместо (или вместе) с Helm в среде Kubernetes

В облачно-ориентированной разработке платформа Kubernetes стала де-факто стандартом для оркестровки контейнеров.

Однако эффективное и автоматическое обеспечение того, чтобы состояние кластера соответствовало требуемой конфигурации, является постоянной проблемой.

GitOps — практика, при которой источник достоверности для развертываний хранится в репозитории Git, — предлагает декларативный, проверяемый и контролируемый по версиям подход к управлению конфигурациями.

Среди доступных инструментов, ориентированных на GitOps, Argo CD выделяется как мощное решение.

В этой статье обсудим, почему стоит использовать Argo CD, не ограничиваясь Helm, ознакомимся с альтернативными инструментами, рассмотрим процесс настройки Argo CD и покажем пример того, как Argo CD отслеживает YAML-файлы в Git.

Почему стоит выбрать Argo CD, не ограничиваясь использованием Helm

Аспекты	Helm	Argo CD
Основная функция	Менеджер пакетов и движок-шаблонизатор для манифестов Kubernetes	Непрерывная доставка на основе GitOps и управление жизненным циклом приложений
Метод развертывания	Обычно запускается вручную через CLI или интегрируется в конвейеры CI/CD	Декларативное управление конфигурацией, постоянная синхронизация кластера с источником доверия Git
Управление состоянием	Не отслеживает и не поддерживает желаемое состояние кластера; пользователи должны вручную повторно применять или обновлять состояние	Постоянный мониторинг и согласование состояние кластера с желаемым состоянием, определенным в Git
Возвраты	Требуется ручной возврат с помощью команды helm rollback; может потребоваться самостоятельное отслеживание конкретных версий	Встроенный контроль версий через историю Git; легко осуществляемый автоматический возврат к предыдущим известным состояниям
Обнаружение дрейфа	Ограниченное обнаружение дрейфа; пользователи должны вручную выполнять команды для сравнения	Автоматическое обнаружение дрейфа и согласование, снижение риска дрейфа конфигурации и «скрытых» различий текущего и желаемого состояния
Интеграция с GitOps	Не является GitOps-ориентированным, однако может быть интегрирован как часть GitOps-конвейера с помощью внешних инструментов	Нативный GitOps-инструмент; Git-репозиторий является единым источником доверия, обеспечивающий аудитопригодность и отслеживаемость
Безопасность и соответствие нормативным требованиям	Необходимость полагаться на процесс и лучшие практики для целей аудита и обеспечения безопасности	Предоставляет строгие следы аудита, контроль доступа и прозрачную историю всех изменений через Git
Прогрессивная доставка	Требуется ручная настройка или дополнительные инструменты для достижения пробных (canary), бесшовных (blue-green) или поэтапных развертываний (progressive rollouts)	Легко интегрируется с Argo Rollouts, упрощая прогрессивную доставку и продвинутые стратегии релиза

1. GitOps-модель и единый источник достоверности. Helm фокусируется на упаковке и шаблонизации манифестов Kubernetes. Argo CD, напротив, реализует GitOps-модель, в которой «желаемое состояние» («desired state») приложений хранится в Git. Argo CD постоянно следит за целевым кластером Kubernetes и сравнивает его с Git-репозиторием. Если появляются какие-либо расхождения, он автоматически (или по требованию) их устраняет. Таким образом, кластер всегда отражает правильную, запланированную конфигурацию. Такой подход снижает риск дрейфа конфигурации, упрощает аудит и обеспечивает прозрачную историю изменений.

2. Непрерывная поставка и декларативное управление. В Helm развертывание и обновление приложений часто зависит от ручных операций CLI или конвейеров CI/CD для запуска команд helm upgrade. Однако Argo CD непрерывно синхронизирует кластер с желаемым состоянием, заданным в Git. Это эффективно устраняет ручное вмешательство, оптимизирует непрерывную поставку и гарантирует, что живая среда кластера никогда не отклонится от задокументированной конфигурации.

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

4. Интеграция с Helm, Kustomize и другими инструментами. Argo CD не является заменой возможностей шаблонизатора Helm. Однако он может напрямую использовать диаграммы Helm, а также оверлеи Kustomize, Jsonnet и обычные YAML-манифесты. Включение диаграмм Helm в рабочий GitOps-процесс Argo CD позволяет объединить преимущества обоих инструментов: мощную шаблонизацию Helm и непрерывную автоматическую синхронизацию Argo CD.

Альтернативы Argo CD

Хотя Argo CD является ведущим GitOps-инструментом, стоит упомянуть и другие аналогичные решения.

Flux CD

Flux — еще один GitOps-инструмент, который непрерывно мониторит Git-репозиторий и сверяет его с кластером Kubernetes. Он предлагает бесшовную интеграцию с Helm и Kustomize. Хотя Flux известен своей простотой и легким дизайном, Argo CD часто предоставляет более богатый пользовательский интерфейс, улучшенные визуализации и расширенные стратегии «из коробки».

Jenkins X

Jenkins X объединяет принципы CI/CD и GitOps, предоставляя комплексное решение для создания и развертывания приложений. Он сложнее, чем Argo CD, и может оказаться излишеством, если вам нужна только непрерывная доставка с GitOps.

Flagger (с Flux)

Flagger ориентирован на прогрессивную доставку и канареечные релизы. В паре с Flux он может предложить опыт, схожий с Argo CD в сочетании с Argo Rollouts, обеспечивая контролируемое и инкрементное развертывание новых релизов.

Spinnaker

Spinnaker, изначально разработанный Netflix, — мощная мультиоблачная платформа непрерывной доставки. Не являясь чистым GitOps-инструментом, она отлично справляется с управлением сложными развертываниями в нескольких средах и облаках. Ее сложность и кривая обучения выше по сравнению с Argo CD.

Настройка Argo CD в среде Kubernetes

Необходимые условия

• Функционирующий кластер Kubernetes (локальный или облачный).

• Установленный и настроенный kubectl для доступа к кластеру.

• Git-репозиторий, содержащий манифесты Kubernetes или диаграммы Helm.

Этапы настройки

1. Установление области управления Argo CD:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

• Подтверждение установки:

kubectl get pods -n argocd

Убедитесь, что все модули (pod’ы) находятся в состоянии Running (выполнения).

2. Вход в пользовательский интерфейс Argo CD:

kubectl port-forward svc/argocd-server -n argocd 8080:443

Затем откройте https://localhost:8080 в браузере. Первоначальное имя пользователя — admin. Получите пароль отсюда:

kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath="{.data.password}" | base64 -d

Войдите в систему и немедленно измените пароль.

3. Регистрация целевого кластера (опционально). Если необходимо управлять отдельным кластером, можете добавить его:

argocd cluster add <context-name>

4. Создание приложения в Argo CD:

argocd app create my-app \
--repo https://github.com/example-org/my-app-config.git \
--path manifests \
--dest-server https://kubernetes.default.svc \
--dest-namespace default

Затем выполните следующее:

argocd app sync my-app

Это гарантирует, что желаемое состояние приложения (из Git) будет применено к вашему кластеру.

Какие YAML-файлы отслеживает Argo CD?

Argo CD отслеживает файлы на пути Git-репозитория, который вы указываете при создании ресурса Application. Эти файлы могут включать:

• обычные YAML-манифесты Kubernetes;

• конфигурации Kustomize (с kustomization.yaml);

• диаграммы Helm (с Chart.yaml и шаблонами);

• Файлы Jsonnet.

Argo CD автоматически обнаруживает и преобразует эти манифесты в конечные ресурсы Kubernetes, постоянно отслеживая обновления. Когда вы фиксируете новые изменения в Git с помощью коммитов, Argo CD обнаруживает их и синхронизирует кластер, поддерживая всегда точное желаемое состояние.

Пример: структура каталога и определение приложения

Рассмотрим Git-репозиторий с такой структурой:

Если хотите использовать каталог kustomize/overlays/staging для приложения, выполните команду:

argocd app create awesome-app \
  --repo https://github.com/example-org/awesome-app-config.git \
  --path kustomize/overlays/staging \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace default

Argo CD находит kustomization.yaml по указанному пути, использует Kustomize для рендеринга финальных YAML-манифестов и развертывает их на кластере. Любые изменения, вносимые в этот каталог в Git, автоматически обнаруживаются и могут быть синхронизированы с кластером.

Заключение

Argo CD использует GitOps-модель для поддержания кластера Kubernetes в соответствии с конфигурациями, хранящимися в Git. По сравнению с использованием только Helm, Argo CD обеспечивает автоматическое согласование состояний, простой возврат версий, непрерывную доставку и улучшенные возможности проверки. Он может интегрироваться с такими инструментами, как Helm и Kustomize, создавая более надежный, декларативный рабочий процесс. Если вы только начинаете работать с GitOps или хотите усовершенствовать существующий конвейер, Argo CD предлагает безопасный, надежный и автоматизированный подход к управлению развертываниями в среде Kubernetes.

Читайте также:

• Nelm — полноценная замена Helm
• Руководство по устранению неполадок в Kubernetes
• Итоги 8 лет с Kubernetes в продакшене: два крупных сбоя кластера, отказ от самостоятельного управления, сокращение затрат на кластер, инструментарий и многое другое

Читайте нас в Telegram, VK и Дзен

---

Перевод статьи Boqiang & Henry: Why Use Argo CD in Kubernetes Environment | by Boqiang & Henry | Dec, 2024 | Medium