Argo CD : faire de Git la source de vérité du déploiement Kubernetes

Une chaîne CI/CD classique peut parfaitement automatiser un kubectl apply. Pourtant, cette automatisation ne répond pas à une question essentielle : qui contrôle ensuite que l’état réel du cluster correspond toujours à ce qui a été validé ?

Argo CD répond à cette question en appliquant un modèle GitOps : l’état attendu est déclaré dans Git, puis un contrôleur compare cet état à ce qui existe réellement dans Kubernetes.

Le point clé n’est pas le bouton “Sync”

Réduire Argo CD à une interface graphique de déploiement manque l’essentiel. Son intérêt principal est la réconciliation. L’Application Controller observe les définitions suivies, compare l’état désiré à l’état live et signale les écarts.

Selon la politique choisie, la synchronisation peut rester manuelle ou être automatisée. Dans les deux cas, le drift devient visible au lieu de rester caché derrière une modification directe du cluster.

CI et CD peuvent enfin avoir des responsabilités différentes

La CI reste responsable de ce qu’elle fait le mieux : tester le code, construire un artefact ou une image, produire une version identifiable et publier cette version dans un registre.

Argo CD peut ensuite prendre en charge la partie déploiement à partir d’une configuration déclarative. Cette séparation évite de transformer chaque runner CI en opérateur direct du cluster et réduit le nombre d’endroits où des credentials Kubernetes puissants doivent être manipulés.

Le drift devient un signal opérationnel

Une modification manuelle dans un cluster peut être nécessaire pour diagnostiquer un incident, mais elle ne doit pas devenir une configuration invisible. Lorsque l’état live diverge de l’état déclaré, Argo CD peut présenter l’application comme OutOfSync.

Le vrai bénéfice est alors organisationnel : soit la modification est temporaire et doit être annulée, soit elle est légitime et doit revenir dans Git. Dans les deux cas, la configuration durable retrouve une trace versionnée.

La structure Git devient une décision d’architecture

Le dépôt qui porte l’état de déploiement doit être pensé comme un composant de la plateforme. Les environnements, overlays, charts Helm, manifests Kustomize, versions d’images et droits de modification doivent rester compréhensibles.

Le choix de targetRevision mérite aussi de la précision. La documentation Argo CD recommande d’éviter les références ambiguës entre branches et tags de même nom et, lorsque nécessaire, d’utiliser des références Git pleinement qualifiées.

Argo CD ne supprime pas les décisions de promotion

L’automatisation de la synchronisation ne signifie pas que toutes les branches doivent se déployer partout automatiquement. Une équipe peut conserver des gates explicites : pull request, validation staging, changement de référence d’image, merge contrôlé vers un dépôt d’environnement ou approbation de promotion.

Le bon modèle est celui dans lequel chaque environnement possède un état désiré identifiable et une règle claire pour faire évoluer cet état.

Et sur OpenShift ?

Red Hat OpenShift GitOps utilise Argo CD comme moteur déclaratif GitOps. L’Operator fournit une intégration OpenShift et permet de gérer des applications et certaines configurations de cluster à partir de dépôts Git.

Cela relie naturellement deux sujets : OpenShift fournit le contrat de plateforme, tandis qu’Argo CD peut fournir la boucle de réconciliation entre Git et cette plateforme.

Le modèle mental à retenir

1. la CI produit une version identifiable ;
2. Git décrit la version et la configuration désirées ;
3. Argo CD observe Git et le cluster ;
4. l’écart devient visible ;
5. la synchronisation rapproche l’état live de l’état déclaré ;
6. les changements durables reviennent dans Git ;
7. la promotion entre environnements reste une décision contrôlée.