ArgoCD et Flux sont tous deux des projets CNCF graduated qui résolvent exactement le même problème : synchroniser en continu l’état d’un cluster Kubernetes avec ce que déclare un dépôt Git. Le GitOps qu’ils appliquent est identique dans le principe ; ce qui diffère, et qui décide vraiment lequel choisir, c’est le modèle d’architecture derrière.

ArgoCD : une application centralisée avec UI

ArgoCD tourne comme une application unique (serveur API, contrôleur de réconciliation, interface web) qui garde en mémoire l’état de chaque Application qu’elle gère. L’UI n’est pas un bonus cosmétique : elle affiche l’arbre complet des ressources déployées par une Application, leur état de santé, et l’historique des synchronisations, ce qui en fait un outil de diagnostic autant qu’un outil de déploiement.

# L'état complet d'une Application, y compris chaque ressource enfant,
# est interrogeable en une commande
argocd app get payment-api --show-managed-resources

Ce modèle centralisé a un coût structurel : le serveur ArgoCD est un point de passage unique pour toutes les opérations, ce qui demande d’y penser en termes de haute disponibilité et de dimensionnement dès qu’un cluster gère plusieurs centaines d’Applications.

Flux : un ensemble de contrôleurs composables

Flux prend le chemin inverse : pas d’application centrale, mais une collection de contrôleurs Kubernetes indépendants (source-controller pour récupérer les sources Git/Helm/OCI, kustomize-controller pour appliquer les manifests, helm-controller pour les charts Helm), chacun réconciliant son propre périmètre via des Custom Resources standard.

# Flux : chaque contrôleur réconcilie sa propre CRD, sans état
# centralisé partagé entre eux
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: payment-api
spec:
  url: https://github.com/acme/payment-api-config
  interval: 1m

Cette architecture élimine le point de passage unique par construction : chaque contrôleur reste indépendant, scale et redémarre séparément. Le prix à payer est l’absence d’UI native aussi riche que celle d’ArgoCD ; l’observabilité de l’état GitOps passe par kubectl et les CRD elles-mêmes, ou par un outil tiers (Weave GitOps, Headlamp) branché par-dessus.

Là où la différence pèse vraiment

Une organisation avec plusieurs équipes qui veulent une vue centralisée de tous les déploiements, avec un contrôle d’accès fin par projet (couvert dans l’article sur les ApplicationSets à l’échelle), tire un vrai bénéfice de l’UI et du modèle AppProject d’ArgoCD. Une équipe de plateforme qui préfère composer son propre outillage GitOps à partir de briques Kubernetes natives, sans dépendre d’une application centrale à opérer, penche naturellement vers Flux : chaque contrôleur se déploie, se met à jour et se debug indépendamment des autres.

L’écosystème, pas seulement le cœur

Les deux projets ont des extensions qui comptent dans la décision. ArgoCD Image Updater automatise la mise à jour d’image sans passer par un pipeline CI externe, utile pour un flux de déploiement continu simple. Flux propose Flagger, un contrôleur de rollout progressif (canary, blue/green) qui s’intègre nativement à ses propres CRD, sans outil tiers séparé comme Argo Rollouts l’est pour ArgoCD. Le choix d’un cœur GitOps entraîne souvent, par cohérence d’écosystème, le choix des outils satellites qui vont avec.

À retenir

ArgoCD et Flux appliquent le même GitOps par deux modèles opposés : une application centralisée avec UI riche contre un ensemble de contrôleurs composables sans état partagé. Le critère qui décide n’est pas « lequel est meilleur » mais la préférence organisationnelle entre visibilité centralisée immédiate et modularité native Kubernetes. Les deux se déploient dans le cadre d’une migration Kubernetes sans que l’un ne soit un choix par défaut plus sûr que l’autre.