Optimisation du Déploiement Continu avec ArgoCD et Kubernetes
Introduction
J'ai deploye ArgoCD pour la premiere fois en 2020 chez Bloomflow, et ca a immediatement change ma facon de travailler avec Kubernetes. Avant, le deploiement etait un acte technique : quelqu'un executait helm upgrade depuis son poste ou via Jenkins. Avec ArgoCD, le deploiement est devenu un acte de gouvernance : un merge sur Git suffit, la reconciliation est automatique et tracable. Depuis, j'ai implemente ArgoCD chez KNDS, Padam Mobility, F2R2 et Earny SA. Chaque mission a affine mon approche.
Le GitOps en production : au-dela du concept
Le GitOps repose sur un principe simple : Git est la source unique de verite pour l'etat du cluster. ArgoCD materialise ce principe en surveillant un repository Git et en reconciliant en permanence l'etat reel du cluster avec l'etat declare. Chez Padam Mobility, on gerait 15 microservices dans un monorepo Helm. Un merge sur main declenchait le deploiement en staging. La promotion en production passait par un tag Git, revue par un tech lead. Le temps de deploiement est passe de 25 minutes (Jenkins + scripts shell custom) a 3 minutes. Mais le vrai gain n'etait pas la vitesse, c'etait l'auditabilite : chaque deploiement est un commit, avec un auteur, une date et un diff lisible.
Architecture multi-clusters chez F2R2
Le projet F2R2 m'a permis de pousser ArgoCD a son potentiel maximum. Architecture AWS Multi-Compte avec un ArgoCD centralise sur le compte Management. Trois comptes distincts (dev, staging, prod), chacun hebergeant son cluster EKS Fargate. ArgoCD deploie sur les trois clusters distants via des cluster secrets enregistres dans sa configuration.
La fonctionnalite decisive a ete les ApplicationSets. Un seul template ApplicationSet generait automatiquement une Application par cluster et par service. Quand on ajoutait un nouveau microservice dans le repo Helm, ArgoCD le deployait sur les trois environnements sans aucune configuration supplementaire. Resultat concret : 25 modules Terraform pour l'infra et une trentaine de Helm Charts geres depuis un seul point d'entree. L'equipe pouvait visualiser l'etat de synchronisation de chaque service sur chaque cluster dans un seul dashboard.
Secrets en contexte Defense
Chez KNDS, la gestion des secrets etait une exigence contractuelle. Aucun secret en clair dans Git, meme pas chiffre avec SOPS (le risque residuel etait juge inacceptable). J'ai mis en place External Secrets Operator connecte a OKMS, le Key Management Service d'OVH Cloud. Les manifestes Git contiennent uniquement des ExternalSecret (des references vers OKMS), jamais les valeurs. L'operateur synchronise les vrais secrets dans les Kubernetes Secrets au moment du deploiement.
Chez Bloomflow, le setup etait similaire avec HashiCorp Vault et le plugin ArgoCD Vault Plugin, qui resolvait les placeholders directement dans les manifestes au moment du sync. Cette architecture (ArgoCD + External Secrets + Vault/KMS) est devenue mon standard. Le principe : les manifestes declarent "je veux le secret X depuis le coffre Y", jamais la valeur.
Rollback : l'assurance vie du vendredi soir
Le moment qui m'a le plus convaincu de la valeur d'ArgoCD s'est passe chez Earny SA, pendant la migration GCP vers AWS. Un deploiement sur le nouveau cluster EKS a provoque une regression de performance un vendredi a 18h : le temps de reponse du service principal est passe de 200ms a 3 secondes. En deux clics dans l'interface ArgoCD (History, puis Rollback), l'application est revenue a la version precedente en 25 secondes. Sans GitOps, il aurait fallu identifier le bon tag Helm, trouver les bonnes values, executer manuellement le rollback. Au moins 15 minutes de stress.
L'integration avec Grafana rend la boucle de feedback encore plus rapide. Je configure systematiquement un dashboard qui affiche le statut de sync ArgoCD correle aux metriques applicatives (taux d'erreurs, latence p95). Quand un pic d'erreurs coincide avec un sync ArgoCD, la decision de rollback prend 10 secondes.
Cinq regles ArgoCD forgees sur le terrain
Pruning automatique : automated.prune: true supprime les ressources orphelines. Sans ca, chaque renommage de ressource laisse un fantome dans le cluster qui consomme des ressources et peut creer des conflits.
Sync waves : les annotations argocd.argoproj.io/sync-wave ordonnent les deploiements. CRDs en wave -2, namespaces en wave -1, operateurs en wave 0, applications en wave 1. Chez F2R2, cette stratification evitait les erreurs de deploiement liees a des CRDs non encore installees.
Health checks custom : par defaut, ArgoCD ne sait pas evaluer la sante de vos CRDs metier (ExternalSecret, Certificate, etc.). Un script Lua de 10 lignes par CRD resout le probleme et evite les faux positifs de sync.
Separation des repos : le code applicatif et la configuration K8s vivent dans des repos distincts. Cycles de vie differents, permissions differentes, reviews independantes.
Notifications : ArgoCD Notifications envoie un message Discord ou Slack a chaque sync. Chez Metronome, le canal Discord CI/CD affichait un resume du deploiement avec lien direct vers le dashboard ArgoCD.
Conclusion
ArgoCD a transforme le deploiement Kubernetes d'une operation technique risquee en un processus gouvernable et tracable. Le GitOps n'est plus une tendance, c'est un standard que j'applique chez chaque client. La combinaison ArgoCD + Helm + un repo bien structure offre auditabilite, rollbacks instantanes et collaboration fluide. Si vous gerez des clusters K8s en production sans ArgoCD, c'est probablement le chantier le plus impactant que vous puissiez lancer.