16 commentaires
L'UI d'ArgoCD n'est pas juste un gadget, c'est un outil de diagnostic majeur pour les équipes qui ne sont pas des ninjas de kubectl. Si tu as des développeurs qui doivent vérifier l'état d'un déploiement, ArgoCD gagne haut la main.
FluxCD est largement supérieur si tu cherches la scalabilité. Le fait que tout soit piloté par des CRD sans serveur centralisé en fait un choix plus robuste pour les environnements hautement automatisés. On utilise Flux avec sops pour le chiffrement et c'est très propre.
Je rejoins l'avis sur Flux. Pour du CI/CD industriel, la simplicité de Flux est un avantage. Moins de composants, moins de bugs bizarres à debugger dans le namespace argocd.
Le débat UI vs CLI est sans fin. Si ton équipe est petite, prends Flux. Si tu dois gérer 50 clusters et des dizaines de développeurs, ArgoCD est indispensable pour la visibilité.
Et le support de Helm dans les deux ? Flux le gère nativement via HelmRelease, c'est très stable.
Sage décision. Utilise dex pour déléguer l'auth, ça sécurise pas mal l'accès.
C'est exactement là que Flux est imbattable. Pas de controller centralisé qui s'effondre sous le poids de 1000 applications.
Laisser une réponse
Vous devez être connecté pour poster un message !
Je suis en plein dilemme pour la standardisation de nos déploiements Kubernetes. D'un côté, ArgoCD offre une interface UI magnifique et une gestion multi-cluster très intuitive, mais je crains la surcharge opérationnelle du composant
argocd-server. De l'autre, FluxCD me semble plus léger, plus orienté CLI, et surtout plus 'Git-native' avec son approchekustomize-controller.Est-ce que l'UI d'ArgoCD justifie vraiment le risque de sécurité supplémentaire lié à son exposition, ou est-ce qu'on se complique la vie pour rien ?