Optimisation de Kubernetes avec ArgoCD pour un Déploiement Continu
Introduction
ArgoCD est l'outil GitOps que j'ai déployé sur le plus grand nombre de clusters. De KNDS (Défense) à Bloomflow (multi-cloud), en passant par Padam Mobility et Metronome, il a prouvé sa fiabilité dans des contextes très variés. Voici comment optimiser cette combinaison pour un déploiement continu de qualité production.
Le GitOps avec ArgoCD : au-delà du sync automatique
Le GitOps, c'est plus que "ArgoCD déploie ce qui est dans Git". C'est une philosophie : Git est la source de vérité unique pour l'état de l'infrastructure. Chez Padam Mobility, j'ai construit des environnements de développement bout-en-bout déployés depuis des branches Git. Chaque développeur avait son propre namespace Kubernetes, déployé automatiquement par ArgoCD quand il créait une branche. La PR incluait un lien vers l'environnement de preview. Quand la branche était mergée ou supprimée, ArgoCD nettoyait automatiquement l'environnement. Zéro intervention manuelle, zéro namespace orphelin.
Sécurité ArgoCD en contexte Défense
Chez KNDS, la sécurité d'ArgoCD était un sujet critique. J'ai implémenté plusieurs couches. D'abord, le RBAC ArgoCD limitait chaque équipe à ses propres applications. Ensuite, les secrets n'étaient jamais stockés dans Git : External Secrets Operator récupérait les secrets depuis OKMS (OVH Key Management Service) et les injectait dans les pods. Le RBAC Kubernetes complétait celui d'ArgoCD : un namespace par équipe, des NetworkPolicies pour l'isolation réseau. Les profils seccomp durcissaient les conteneurs en limitant les appels système autorisés. Cette défense en profondeur est indispensable dans les environnements sensibles.
Tests et validation avant déploiement
ArgoCD supporte les hooks pre-sync et post-sync, que j'utilise systématiquement. Le hook pre-sync peut exécuter des migrations de base de données ou des validations de schéma. Le hook post-sync peut lancer des smoke tests pour vérifier que l'application fonctionne. Chez Bloomflow, le hook post-sync exécutait un job Kubernetes qui testait les endpoints principaux de l'application et reportait le résultat dans Slack. Si le smoke test échouait, l'équipe était alertée immédiatement. Chez Okeiro, les hooks validaient que le chart FHIR se déployait correctement avec les bonnes configurations de Workload Identity sur GKE.
Gestion multi-cluster avec ArgoCD
Sur les projets multi-cloud, ArgoCD gère plusieurs clusters depuis une seule instance. Chez Bloomflow, une instance ArgoCD centrale déployait sur des clusters AWS EKS, Scaleway Kapsule et Outscale Cloud. Les ApplicationSets généraient automatiquement les applications pour chaque cluster en fonction de la structure du repository Git. Un répertoire par cluster, un fichier values par environnement. Le pattern App of Apps orchestrait les dépendances : l'infrastructure de base (cert-manager, External Secrets) se déployait avant les applications métier. Cette architecture a tenu pendant 5 ans sans refonte majeure.
Monitoring d'ArgoCD : surveiller le surveillant
ArgoCD expose ses propres métriques Prometheus : nombre de syncs, durée des syncs, applications out-of-sync, erreurs de réconciliation. Chez Metronome, un dashboard Grafana dédié à ArgoCD montrait en temps réel l'état de toutes les applications : synced, out-of-sync, degraded, healthy. Une alerte partait si une application restait out-of-sync plus de 5 minutes (ce qui pouvait indiquer un problème de permissions ou un manifest invalide). Cette surveillance du système de déploiement lui-même est souvent négligée mais essentielle.
Conclusion
ArgoCD sur Kubernetes est une combinaison éprouvée que j'ai déployée dans des contextes allant de la startup au secteur Défense. Les clés du succès : GitOps rigoureux, sécurité en profondeur, hooks de validation, et monitoring d'ArgoCD lui-même. Si vous déployez sur Kubernetes, ArgoCD devrait être votre premier choix pour le CD.