Ответ
Я выбираю ArgoCD как основное решение для GitOps в Kubernetes, когда в проекте есть следующие требования:
- Строгий GitOps-подход: Необходима гарантия, что состояние кластера всегда соответствует декларативным манифестам в Git-репозитории. ArgoCD постоянно сравнивает (
diff) живое состояние с желаемым в репозитории и автоматически синхронизирует расхождения. - Мультикластерное и мультитехнологическое развертывание: Нужно управлять приложениями в нескольких кластерах (dev, staging, prod) или развертывать не только raw YAML, но и Helm-чарты, Kustomize-оверлеи из единой точки.
- Потребность в прозрачности и самообслуживании: Командам разработки нужен понятный UI или CLI для просмотра состояния своих приложений, истории развертываний и выполнения ручных синхронизаций или откатов без прямого доступа к
kubectl. - Сложные стратегии развертывания: Требуется реализация blue-green или canary-развертываний с использованием Argo Rollouts, интегрированного с ArgoCD.
- Автоматизация на основе состояния приложения: Включение политик автоматической синхронизации (
auto-sync) и самовосстановления (self-heal) при дрейфе конфигурации.
Пример из практики: Мы использовали ArgoCD для управления инфраструктурой микросервисов. Каждый сервис имел свой каталог в Git с Kustomize-манифестами. ArgoCD Application отслеживал этот каталог. При мерже PR в основную ветку ArgoCD автоматически разворачивал новую версию в staging-кластер, а после ручного утверждения — в production.
# Пример Application для микросервиса
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: payment-service
namespace: argocd
spec:
project: default
source:
repoURL: 'git@github.com:my-org/infra.git'
targetRevision: HEAD
path: 'apps/payment-service/overlays/production' # Используем Kustomize
destination:
server: 'https://kubernetes.default.svc'
namespace: payments-prod
syncPolicy:
automated:
prune: true # Удалять ресурсы, удаленные из Git
selfHeal: true # Автоматически исправлять дрейф