Optimiser le déploiement continu avec Kubernetes et ArgoCD
ArgoCD + Kubernetes : le duo GitOps que je déploie partout
ArgoCD est l'outil qui a le plus transformé ma façon de déployer sur Kubernetes. Depuis que je l'ai adopté il y a 4 ans, je l'ai déployé sur chaque mission K8s : KNDS (Défense), F2R2 (AWS Multi-Compte), Bloomflow (multi-cloud), Padam Mobility (dev bout-en-bout), et Earny SA (migration GCP vers AWS). Voici un guide approfondi basé sur cette expérience.
Le GitOps : Git comme source de vérité unique
Le principe du GitOps est simple : l'état désiré de votre infrastructure est déclaré dans Git. ArgoCD surveille le repo et synchronise le cluster Kubernetes pour correspondre à cet état. Si quelqu'un modifie une ressource manuellement via kubectl, ArgoCD détecte le drift et peut soit alerter, soit rétablir automatiquement l'état déclaré.
Chez KNDS dans la Défense, ce principe n'était pas optionnel mais réglementaire. Chaque changement devait être traçable, approuvé par un pair, et réversible. ArgoCD cochait toutes les cases : chaque déploiement correspond à un commit Git, approuvé via PR, et un rollback se fait en revertant le commit.
Architecture ArgoCD : mono-repo vs multi-repos
J'ai expérimenté les deux approches. Le mono-repo GitOps (un seul repo contenant tous les manifestes/Helm charts de toutes les applications) fonctionne bien pour les petites équipes. C'est ce que j'utilise sur WizOps.fr : un repo unique avec les Helm charts pour le frontend et le backend.
Le multi-repos (un repo GitOps par application ou par équipe) convient mieux aux organisations plus grandes. Chez Bloomflow, avec 15 microservices et 3 équipes, chaque équipe avait son propre repo GitOps. ArgoCD utilisait un ApplicationSet pour découvrir et gérer automatiquement toutes les applications.
Chez F2R2, l'architecture était hybride : un repo pour l'infrastructure (add-ons K8s, cert-manager, external-secrets, ingress controller) géré par l'équipe SRE, et des repos séparés pour les applications gérés par les équipes de développement.
Gestion des secrets avec ArgoCD
ArgoCD ne gère pas les secrets directement (et c'est bien). Les secrets ne doivent jamais être stockés en clair dans Git. Mes deux approches selon le contexte :
Chez KNDS, les secrets étaient stockés dans l'OKMS d'OVH Cloud et injectés dans Kubernetes via External Secrets Operator. ArgoCD déployait les ExternalSecret resources, et l'opérateur se chargeait de créer les Secret Kubernetes correspondants.
Chez Bloomflow (ISO 27001), HashiCorp Vault était le backend de secrets. External Secrets Operator synchronisait les secrets de Vault vers Kubernetes. Cette approche offrait une rotation automatique des secrets et un audit trail complet des accès.
Les Application Sets : le scaling d'ArgoCD
Pour gérer des dizaines d'applications, les ApplicationSets d'ArgoCD sont indispensables. Plutôt que de créer manuellement une Application ArgoCD pour chaque microservice, un ApplicationSet génère les Applications dynamiquement à partir d'un pattern.
Chez Bloomflow, un ApplicationSet Git generator scannait le repo GitOps et créait automatiquement une Application ArgoCD pour chaque répertoire trouvé. Ajouter un nouveau microservice revenait à créer un répertoire dans le repo GitOps avec les manifestes Helm. ArgoCD le détectait en quelques secondes et commençait la synchronisation.
Sync waves et hooks : orchestrer les déploiements complexes
Quand l'ordre de déploiement importe (migrations de base de données avant le déploiement de l'application, par exemple), ArgoCD offre les sync waves et les resource hooks.
Chez Earny SA, lors de la migration GCP vers AWS, nous avons utilisé les sync waves pour orchestrer le déploiement : wave 0 pour les ConfigMaps et Secrets, wave 1 pour les migrations de base de données (Job Kubernetes), wave 2 pour les Deployments applicatifs, wave 3 pour les CronJobs. Cette orchestration garantissait que les migrations étaient terminées avant que l'application ne démarre avec le nouveau schéma.
Monitoring d'ArgoCD
ArgoCD expose des métriques Prometheus (nombre d'applications, état de synchronisation, durée des syncs, nombre de drifts détectés). Chez Bloomflow, ces métriques étaient intégrées dans notre dashboard Grafana d'observabilité. Une alerte se déclenchait si une application restait en état "OutOfSync" pendant plus de 5 minutes, signalant un problème de déploiement à investiguer.