ArgoCD vs FluxCD

GitOps est une méthodologie où Git devient la source de vérité unique pour tout votre cluster Kubernetes — pas seulement le code source des applications, mais aussi la configuration de l'infrastructure, les manifests de déploiement, les secrets, les politiques réseau.

ArgoCD : la tour de contrôle visuelle

ArgoCD est un outil CNCF (gradué) qui fournit une interface web puissante pour visualiser l'état de vos déploiements. C'est le "Freelens du GitOps" : on voit tout, on gère tout depuis un dashboard.

• UI graphique : visualisation en arbre des ressources, status de sync en temps réel
• Multi-cluster : gérer plusieurs clusters depuis une seule instance
• Sources multiples : Git, Helm repos, repos OCI
• RBAC intégré : contrôle d'accès par équipe/projet

FluxCD : le puriste CLI

FluxCD adopte une approche minimaliste. Pas d'interface web — tout se gère via des Custom Resources Kubernetes et la ligne de commande. C'est le "k9s du GitOps".

• Approche déclarative : tout est un CRD Kubernetes, rien n'est externalisé
• Léger : moins de ressources consommées qu'ArgoCD
• Reconciliation : le contrôleur tourne en continu dans le cluster
• Helm Controller intégré : support natif des Helm releases

Comparaison

Mise en œuvre : installer ArgoCD

Prérequis

• Un cluster Kubernetes fonctionnel (k3s, kubeadm, Talos — cf. nos articles précédents)
• kubectl configuré et connecté au cluster
• Un dépôt Git (GitHub, Gogs, Gitea...) contenant vos manifests

Étape 1 : Créer le namespace et installer ArgoCD

# Créer le namespace dédié
kubectl create namespace argocd

# Installer ArgoCD via le manifest officiel
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Cela déploie tous les composants : le serveur API, le serveur UI, le controller de reconciliation, et le repo server.

Étape 2 : Récupérer le mot de passe initial

# Le mot de passe initial est le nom du serveur ArgoCD
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

Étape 3 : Exposer l'interface web

# Port-forward temporaire (pour tester)
kubectl port-forward svc/argocd-server -n argocd 8080:443

# Accéder à https://localhost:8080
# Login : admin / (mot de passe récupéré ci-dessus)

En production, utilisez un Ingress avec TLS :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: argocd
  namespace: argocd
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
  rules:
    - host: argocd.votre-domaine.fr
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: argocd-server
                port:
                  number: 443
  tls:
    - hosts:
        - argocd.votre-domaine.fr
      secretName: argocd-tls

Étape 4 : Installer la CLI (optionnel mais recommandé)

# Linux
curl -sSL -o argocd https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
chmod +x argocd && sudo mv argocd /usr/local/bin/

# Connexion
argocd login argocd.votre-domaine.fr --username admin

Cas pratique : déployer une app depuis Git

Supposons que vous ayez un dépôt Git avec les manifests Kubernetes de votre application :

Structure du dépôt Git

mon-app/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── configmap.yaml
├── overlays/
│   ├── staging/
│   │   └── kustomization.yaml
│   └── production/
│       └── kustomization.yaml
└── README.md

Étape 1 : Connecter le dépôt à ArgoCD

# Via CLI
argocd repo add https://github.com/mon-user/mon-app.git --username mon-user --password mon-token

# Via UI : Settings → Repositories → Connect Repo

Étape 2 : Créer une Application

argocd app create mon-app \
  --repo https://github.com/mon-user/mon-app.git \
  --path base \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace production \
  --sync-policy automated \
  --auto-prune \
  --self-heal

Étape 3 : Vérifier l'état

# Via CLI
argocd app get mon-app

# Via UI : naviguer vers l'application
# On voit l'arbre des ressources, le status de sync, et les derniers commits

Le flux de travail

# 1. Developer modifie le code → push sur Git
git commit -am "maj: scale replicas à 3"
git push

# 2. ArgoCD détecte le changement dans le repo Git
# 3. ArgoCD resynchronise le cluster automatiquement
# 4. Le cluster atteint l'état déclaré dans Git

C'est tout. Plus besoin de kubectl apply. Git est la seule interface.

GitOps avec Helm

Si vous utilisez Helm (ce qui est recommandé pour les apps complexes comme Supabase), ArgoCD gère ça nativement.

Créer une Application Helm dans ArgoCD

# Exemple : déployer Supabase via son Helm chart officiel
argocd app create supabase \
  --repo https://github.com/supabase/supabase \
  --path helm/supabase \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace supabase \
  --helm-set postgresql.password=votre_secret \
  --helm-set apiKey=votre_api_key

Ou via un fichier YAML ArgoCD (démarrant aussi à Git) :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: supabase
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/supabase/supabase
    path: helm/supabase
    helm:
      valueFiles:
        - values-production.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: supabase
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Gestion des environnements

Un des vrais cas d'usage de GitOps est la gestion multi-environnements (staging, production).

Avec Kustomize

# overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
patchesStrategicMerge:
  - replicas-patch.yaml
  - resources-patch.yaml

# replicas-patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mon-app
spec:
  replicas: 5

# Créer deux apps ArgoCD : staging + production
argocd app create mon-app-staging \
  --path overlays/staging \
  --dest-namespace staging

argocd app create mon-app-production \
  --path overlays/production \
  --dest-namespace production

Pièges à éviter

1. Les secrets dans Git

2. Ignorer le self-heal

Sans --self-heal, un kubectl edit urgent modifie l'état du cluster, et ArgoCD ne le corrige pas. Vous perdez le bénéfice du GitOps. Activez-le toujours.

3. Trop de permissions

ArgoCD a besoin de droits pour créer des ressources dans le cluster. Mais ne lui donnez pas cluster-admin — utilisez des rôles RBAC dédiés par namespace.

# Limiter ArgoCD à un namespace
argocd app create mon-app \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace production \
  --project default

4. Oublier le .argocd

ArgoCD a besoin de savoir quel format de manifests vous utilisez (YAML brut, Kustomize, Helm). Assurez-vous que la structure de votre dépôt est claire, ou utilisez le champ directory dans la définition de l'application.

Monitoring des déploiements

ArgoCD expose des métriques Prometheus nativement :

# Métriques disponibles
argocd_app_info                      # info sur chaque app
argocd_app_sync_total                # nombre de syncs
argocd_app_reconcile_total           # nombre de reconciliations
argocd_app_health_total              # état de santé des apps

Intégrable directement dans votre kube-prometheus-stack existant.

Conclusion

GitOps n'est pas un gadget — c'est la méthodologie naturelle de Kubernetes. Le cluster est déclaratif, Git est déclaratif, et ArgoCD fait le pont entre les deux.

• Avant : kubectl apply → pas de trace, pas de reproductibilité
• Après : git push → ArgoCD sync → cluster à jour → tout documenté

Checklist de mise en place

• ☐ Cluster Kubernetes opérationnel (k3s, kubeadm, Talos)
• ☐ Dépôt Git dédié aux manifests Kubernetes
• ☐ ArgoCD installé dans le namespace argocd
• ☐ Interface web exposée (Ingress ou port-forward)
• ☐ Dépôt connecté à ArgoCD (repo credential)
• ☐ Première Application créée avec sync automated
• ☐ Secrets chiffrés (Sealed Secrets ou SOPS)
• ☐ RBAC ArgoCD configuré (pas cluster-admin !)
• ☐ Métriques Prometheus intégrées
• ☐ Workflow documenté pour l'équipe

Ressources

• ArgoCD : https://argo-cd.readthedocs.io/
• FluxCD : https://fluxcd.io/
• GitOps Alliance : https://www.gitops.tech/
• Articles précédents : Talos Linux, k9s vs Freelens, Migration Swarm → K8s

Vous utilisez déjà GitOps ? ArgoCD ou FluxCD ? Partagez votre retour d'expérience !