La plupart des équipes commencent à déployer sur Kubernetes de la même manière : le système de CI construit une image, puis exécute kubectl apply ou helm upgrade sur le cluster. Cela fonctionne, jusqu’à ce que le nombre d’applications et de clusters augmente. Ce guide explique ce qui change quand un agent situé dans le cluster, comme Argo CD, tire (pull) l’état souhaité depuis Git à la place, et quels compromis cela implique.

Le modèle push et ses limites

Dans un pipeline push, le job de CI est la seule chose qui touche le cluster :

1. Un commit déclenche les tests et la construction d’une image.
2. Le job met à jour un manifeste avec le nouveau tag d’image.
3. Le job exécute kubectl apply (ou helm upgrade) sur le cluster.

Trois problèmes apparaissent avec la montée en charge :

• Les identifiants vivent en dehors du cluster. Chaque pipeline a besoin d’un kubeconfig ou d’identifiants cloud, et cela se multiplie avec chaque application et chaque cluster.
• L’outillage vit sur le runner. kubectl, helm et leurs versions doivent être installés et maintenus à jour partout où les déploiements s’exécutent.
• Le retour d’information s’arrête à « appliqué ». Le job sait que l’API server a accepté le manifeste. Il ne sait pas si les Pods sont réellement devenus sains.

Inverser le sens : le pull

Avec un modèle pull, un agent s’exécute dans le cluster, surveille un dépôt Git, compare ce qui y est déclaré avec ce qui tourne, et applique la différence.

Developer ─▶ App repo ─▶ CI (test, build) ─▶ Image registry
                            │
                            └─ commits new image tag ─▶ Config repo
                                                            ▲
                                        Argo CD (in cluster) ┘ pulls, compares, applies
                                                │
                                                ▼
                                            Kubernetes

Les identifiants du cluster ne le quittent jamais, car la seule chose qui applique les changements est l’agent qui s’y exécute. Les ingénieurs et les systèmes de CI n’ont besoin que d’un accès en écriture à Git. Argo CD sait lire du YAML brut, des charts Helm et des overlays Kustomize, et les convertit en manifestes Kubernetes avant de les appliquer.

Séparer le code applicatif et la configuration dans des dépôts distincts

La recommandation habituelle est d’avoir deux dépôts : un pour le code source de l’application, un pour la configuration Kubernetes (Deployments, Services, ConfigMaps, Ingresses, etc.).

La raison est que la configuration évolue à son propre rythme. Modifier un Service ou un ConfigMap ne devrait pas déclencher un pipeline complet de build et de tests pour du code qui n’a pas changé, et vous ne voulez pas d’une logique de pipeline qui inspecte un commit pour décider quoi ignorer. La dernière étape du pipeline de CI devient « commiter le nouveau tag d’image dans le dépôt de configuration », et Argo CD prend le relais. Cela sépare aussi nettement les responsabilités : les développeurs possèdent la CI, les équipes plateforme ou d’exploitation possèdent la livraison.

Faire de Git la seule porte d’entrée : détection de dérive et self-heal

Argo CD surveille le cluster en production autant que le dépôt. Quand les deux divergent, l’application est signalée OutOfSync. Selon votre configuration, Argo CD se contente alors de vous prévenir ou ramène le cluster à l’état de Git (voir le guide sur les sync policies de cette série).

Cela a des conséquences pratiques :

• Chaque changement a un commit, un auteur et généralement une pull request relue, ce qui vous donne une piste d’audit.
• Les permissions passent dans Git. Les ingénieurs juniors peuvent ouvrir des pull requests ; seules quelques personnes fusionnent. Vous n’avez pas besoin de rôles de cluster par personne pour y parvenir.
• Un petit kubectl edit manuel en production cesse d’être invisible.

Retour en arrière et reprise deviennent des opérations Git

Comme l’état souhaité est versionné, revenir à un état sain connu est un git revert, et Argo CD y fait converger le cluster. La même idée couvre la reprise après sinistre. Si un cluster est perdu, vous en créez un nouveau, installez Argo CD, enregistrez le même dépôt, et les charges de travail sont recréées à partir de celui-ci. Tout ce qui n’est pas dans Git, comme les données persistantes ou les secrets que vous gérez ailleurs, nécessite quand même sa propre stratégie de sauvegarde.

Une seule instance d’Argo CD peut aussi gérer de nombreux clusters : un seul dépôt peut donc piloter toute une flotte.

Ce qu’Argo CD ne remplace pas

Argo CD est un outil de livraison, pas un outil de build. Vous avez toujours besoin de la CI pour tester le code, construire les images et les pousser vers un registre. Il est aussi spécifique à Kubernetes : d’autres cibles de déploiement nécessitent d’autres outils. Et ce n’est pas le seul controller GitOps : Flux applique les mêmes principes avec une conception différente. Le reste de cette série suppose Argo CD et commence par son installation. Pour la référence complète, consultez la documentation officielle d’Argo CD.