ArgoCD vs Flux : choisir un contrôleur GitOps pour openEduSuite
GitOps est devenu le modèle d'exploitation par défaut des plateformes Kubernetes : l'état souhaité d'un cluster vit dans Git, et un contrôleur rapproche le cluster de cet état. Deux projets gradués par la CNCF dominent cet espace — ArgoCD et Flux CD. Tous deux sont prêts pour la production, tous deux sont largement adoptés, et tous deux peuvent faire tourner une plateforme éducative souveraine. Ils diffèrent par leur forme, leur ergonomie et leur philosophie d'exploitation. Cet article les compare de manière neutre afin qu'une équipe choisisse délibérément plutôt que par défaut.
Ce que font les deux outils
Au cœur, ArgoCD et Flux exécutent la même boucle :
- Surveiller un dépôt Git (ou un artefact OCI) pour détecter les changements.
- Rendre les manifestes déclarés (Helm, Kustomize ou YAML brut).
- Les appliquer à un cluster Kubernetes.
- Détecter et signaler la dérive entre l'état souhaité et l'état réel.
Les deux prennent en charge les charts Helm, les overlays Kustomize, les manifestes bruts, les sources OCI, les webhooks et le polling. Les différences portent sur la structure et l'exploitation, pas sur la capacité à déployer un service.
Architecture et modèle mental
| Aspect | ArgoCD | Flux CD |
|---|---|---|
| Abstraction centrale | Ressource Application par application déployée |
Kustomization / HelmRelease composables plus une Source |
| Composants | Serveur API, serveur repo, contrôleur d'application, Redis, SSO optionnel (Dex) | source-controller, kustomize-controller, helm-controller, notification-controller, contrôleurs d'image optionnels |
| Interface utilisateur | UI web intégrée et CLI | CLI uniquement ; UI tierces optionnelles |
| Multi-cluster | Hub-and-spoke : un plan de contrôle gère plusieurs clusters | Un ensemble de contrôleurs par cluster ; agrégation via des outils externes |
| Empreinte | Plus lourde, centralisée | Plus légère, modulaire — installer seulement ce qui est nécessaire |
ArgoCD traite une application comme unité de gestion et expose la santé, le statut de synchronisation et un arbre de ressources dans son UI. Flux traite les sources et réconciliateurs comme des blocs composables qui sont des ressources Kubernetes natives. Les équipes qui pensent en « applications » préfèrent souvent ArgoCD ; celles qui pensent en « ressources Kubernetes » préfèrent souvent Flux.
Réconciliation et gestion de la dérive
| Fonctionnalité | ArgoCD | Flux |
|---|---|---|
| Synchronisation automatique | Oui (automated avec prune et self-heal) |
Oui, sur un intervalle de réconciliation |
| Élagage / garbage collection | Oui | Oui |
| Détection de dérive | Oui, avec statut de santé | Oui, avec auto-correction optionnelle |
| Stratégie de diff | Diff côté client dans le serveur repo | Server-side apply par défaut |
| Gestion des conflits | Patch / merge à trois voies | Propriété des champs via server-side apply |
L'adoption par Flux du server-side apply est un avantage réel lorsque plusieurs contrôleurs ou personnes touchent aux mêmes ressources : la propriété des champs est suivie explicitement au lieu d'être écrasée silencieusement. Le diff côté client d'ArgoCD produit des aperçus lisibles dans son UI, ce que de nombreux opérateurs apprécient pour la revue.
Packaging et templating
Les deux outils couvrent bien les cas courants :
- Helm : natif dans les deux, y compris les registries OCI.
- Kustomize : natif dans les deux.
- YAML brut : natif dans les deux.
- Jsonnet : natif dans ArgoCD ; disponible dans Flux via Kustomize.
- Plugins / transformateurs personnalisés : pris en charge par les deux, avec des mécanismes d'extension différents.
Une différence pratique : le contrôleur Helm de Flux prend en charge valuesFrom, permettant de récupérer les valeurs Helm depuis des Secrets ou ConfigMaps. ArgoCD obtient des résultats similaires via des plugins ou des opérateurs de secrets externes, ce qui ajoute des étapes.
Gestion des secrets
Les secrets ne doivent jamais être commités en clair. Les deux outils abordent cela différemment :
- Flux déchiffre nativement les fichiers chiffrés avec SOPS dans le kustomize-controller, en prenant en charge age et PGP. Cela garde la gestion des secrets dans la boucle de réconciliation sans composants supplémentaires.
- ArgoCD s'appuie couramment sur des plugins comme l'ArgoCD Vault Plugin, ou sur des opérateurs externes comme External Secrets Operator et Sealed Secrets. Cela fonctionne, mais ajoute des composants et de la configuration.
Les deux s'intègrent proprement avec External Secrets Operator et Sealed Secrets. La différence réside dans la complexité opérationnelle : le chemin SOPS de Flux est plus court, tandis que l'écosystème de plugins d'ArgoCD est plus large.
Automatisation des images
Un workflow GitOps courant consiste à mettre à jour un manifeste automatiquement lorsqu'une nouvelle image de conteneur est publiée.
- Flux fournit les contrôleurs image-reflector et image-automation qui détectent les nouveaux tags et committent le changement dans Git. C'est une fonctionnalité de premier ordre, bien documentée.
- ArgoCD propose ArgoCD Image Updater comme projet séparé. Cela fonctionne, mais est moins intégré et suit son propre cycle de release.
Pour les équipes qui veulent la promotion d'images entièrement dans GitOps, Flux offre actuellement l'expérience la plus fluide.
Multi-tenant et RBAC
| Aspect | ArgoCD | Flux |
|---|---|---|
| Modèle RBAC | RBAC intégré avec projets, rôles et policies | RBAC natif Kubernetes (ServiceAccounts, RoleBindings) |
| SSO | Intégré via Dex (OIDC, SAML, LDAP et plus) | Délégué au fournisseur d'identité du cluster |
| Isolation des tenants | AppProjects avec restrictions de source et destination | Contrôleurs à portée de namespace ; isolation forte by design |
| Clusters multi-tenants | Bon avec une configuration soignée des projets | Excellent — conçu pour les clusters partagés |
Le SSO et le RBAC intégrés d'ArgoCD réduisent l'effort de mise en place pour les organisations qui veulent un plan de contrôle avec authentification. Flux s'appuie sur les mécanismes propres de Kubernetes, ce qui est plus portable et évite un composant d'identité central, mais demande plus de câblage initial.
Notifications et événements
Les deux outils peuvent notifier des systèmes externes des résultats de réconciliation :
- ArgoCD Notifications est un contrôleur séparé avec des déclencheurs basés sur des templates.
- Flux notification-controller fait partie du toolkit standard et prend en charge Slack, Teams, Discord, Rocket.Chat, les webhooks ainsi que le statut de commit chez les fournisseurs Git.
Les deux couvrent les cibles courantes. Le contrôleur de Flux est plus uniformément intégré au cycle de vie du toolkit.
Livraison progressive
Les déploiements canary et blue-green avec promotion basée sur des métriques sont gérés par des projets compagnons :
- Argo Rollouts est mature et largement adopté, avec des templates d'analyse qui conditionnent la promotion aux métriques.
- Flagger s'intègre à Flux et prend en charge des stratégies similaires sur plusieurs fournisseurs d'ingress et de service mesh.
Argo Rollouts dispose actuellement du plus grand écosystème et de la plus grande communauté. Flagger est solide et s'intègre naturellement dans un pipeline Flux. Les deux peuvent assurer la livraison progressive ; le choix suit souvent le contrôleur GitOps déjà en place.
Observabilité et expérience utilisateur
C'est ici que les deux outils se sentent le plus différents :
- ArgoCD fournit une UI web riche : arbre d'application, diff en direct, historique de synchronisation, graphe de ressources et journal d'audit. Pour les opérateurs et les parties prenantes qui préfèrent un retour visuel, c'est un avantage majeur.
- Flux n'a pas d'UI intégrée. L'observabilité vient de la CLI, des événements Kubernetes et du statut des CRD, avec des tableaux de bord tiers optionnels.
L'UI d'ArgoCD abaisse la barrière pour les équipes nouvelles sur Kubernetes. Flux récompense les équipes à l'aise avec kubectl et le statut des CRD.
Performance et empreinte ressource
- ArgoCD peut gérer de nombreux clusters depuis un plan de contrôle unique, mais les composants centralisés (Redis, serveur repo, serveur API) consomment plus de ressources et nécessitent une configuration de sharding à grande échelle.
- Flux exécute un petit ensemble de contrôleurs par cluster et n'installe que les composants nécessaires. Son empreinte est généralement plus légère, et la mise à l'échelle se fait horizontalement en ajoutant des réplicas.
Pour les déploiements sur un ou quelques clusters, la différence est modeste. Pour de grandes flottes, le modèle par cluster de Flux peut être plus simple à appréhender, tandis que le modèle hub-and-spoke d'ArgoCD centralise l'exploitation.
Posture de sécurité
- ArgoCD expose un serveur API central qui doit être sécurisé avec ingress, authentification et TLS. Le contrôleur détient typiquement de larges privilèges sur le cluster, bien qu'ils puissent être limités par projet.
- Flux est pull-based sans serveur central exposé. Chaque contrôleur s'exécute avec un compte de service limité, et l'isolation multi-tenant est un objectif de conception de premier ordre. Les fonctionnalités de chaîne d'approvisionnement incluent les commits signés et la vérification cosign pour les sources OCI.
Un modèle pull-based réduit la surface d'attaque exposée. Un modèle centralisé concentre le contrôle et peut simplifier l'audit. Les deux peuvent être exploités de manière sécurisée avec un durcissement approprié.
Courbe d'apprentissage et exploitation
- ArgoCD est plus rapide à adopter : l'UI guide les utilisateurs pour ajouter des dépôts, créer des applications et déclencher des synchronisations.
- Flux est plus déclaratif et natif Kubernetes : tout est une CRD, et le travail quotidien se fait via YAML et la CLI. La courbe d'apprentissage initiale est plus raide, mais le résultat est une configuration entièrement reproductible.
Les mises à jour diffèrent aussi : ArgoCD met à jour une plateforme centrale, tandis que Flux met à jour des contrôleurs individuels, ce qui peut se faire de manière incrémentale.
Quand choisir lequel
ArgoCD est un bon choix lorsque :
- Un plan de contrôle visuel compte pour les opérateurs ou les parties prenantes.
- Le SSO et le RBAC intégrés doivent fonctionner out of the box.
- La livraison progressive avec Argo Rollouts est prévue.
- La gestion centralisée de nombreux clusters est souhaitée.
- L'équipe est moins à l'aise avec Kubernetes.
Flux est un bon choix lorsque :
- Un workflow purement déclaratif et natif Kubernetes est préféré.
- Le support SOPS natif et l'automatisation des images sont importants.
- Des clusters multi-tenants avec isolation stricte sont nécessaires.
- Une empreinte plus légère et modulaire est souhaitée.
- Le server-side apply et une gestion propre des conflits comptent.
- Un modèle pull-based sans serveur central est préféré.
Utiliser les deux ensemble
Les deux outils ne s'excluent pas mutuellement. Les motifs hybrides courants sont :
- Flux pour le bootstrap du cluster et la gestion des secrets, ArgoCD pour la livraison des applications avec son UI.
- L'automatisation d'images Flux alimente des manifestes que ArgoCD déploie.
- ArgoCD pour un environnement, Flux pour un autre, pendant une migration.
De nombreuses organisations font tourner les deux pendant une transition et se fixent sur l'un avec le temps, sur la base de l'expérience opérationnelle.
Conclusion
Il n'y a pas de vainqueur universel. ArgoCD optimise la visibilité et l'accessibilité ; Flux optimise la composabilité et la pureté native Kubernetes. Tous deux sont gradués par la CNCF, tous deux sont éprouvés en production, et tous deux peuvent soutenir une plateforme éducative souveraine. Le bon choix dépend des compétences de l'équipe, des exigences de sécurité et de la part du pipeline de livraison qui doit vivre dans Kubernetes lui-même.
Call to Action
- Évaluer en isolation : Provisionner un cluster de test avec chaque contrôleur et déployer un sous-ensemble représentatif de services avant de s'engager.
- Comparer selon ses propres critères : La vitesse de réconciliation, la gestion de la dérive, les workflows de secrets et l'expérience opérateur varient selon l'environnement.
- Partager l'expérience : Rejoindre le canal communautaire openEduSuite
#opendesk-ce-public:matrix.openedusuite.orgpour discuter des approches GitOps avec d'autres déployeurs. - Contribuer : Les améliorations de la documentation, des charts et des motifs de déploiement sont les bienvenues de la part de tous les contributeurs.
GitOps est une pratique, pas un produit : le contrôleur est un outil, et la discipline d'un état versionné et réconcilié est l'objectif.
