Plateforme GitOps multi-cluster
Socle Argo CD pilotant plusieurs clusters Kubernetes depuis un dépôt unique, avec charts Helm versionnés dans un registre OCI.
Technologies employées
- Argo CD
- Helm
- Kubernetes
- GitLab CI
- Kustomize
Résumé
Un dépôt Git unique décrit l’état souhaité de plusieurs clusters. Argo CD réconcilie en continu, et aucune commande impérative n’est appliquée en production.
Contexte
Multiplier les clusters multiplie les dérives. Sans source de vérité unique, une correction appliquée à chaud sur un cluster est oubliée sur les autres, et personne ne sait plus quelle version tourne où.
Objectifs
- Rendre l’état de chaque cluster lisible depuis Git, sans accès au cluster.
- Séparer strictement les charts d’infrastructure des charts applicatifs.
- Interdire tout déploiement impératif vers la production.
Contraintes
- Les secrets ne doivent jamais transiter par Git.
- Une montée de version doit être réversible par simple retour arrière Git.
Architecture
Le dépôt est organisé par cluster, puis par application. Les charts Helm sont publiés dans un registre OCI et référencés par version figée : une application ne suit jamais une branche mobile.
La séparation entre charts d’infrastructure et charts applicatifs est stricte. Un composant partagé par plusieurs services vit dans le premier lot, jamais dupliqué dans le second.
Implémentation
La chaîne d’intégration valide, empaquette et publie les charts. Elle ne touche jamais aux clusters : elle se contente de mettre à jour une référence de version, qu’Argo CD applique ensuite.
Les secrets sont injectés depuis un gestionnaire externe et synchronisés dans les espaces de noms consommateurs, ce qui laisse Git entièrement public à l’échelle de l’équipe.
Difficultés rencontrées
Argo CD signalait des dérives permanentes sur certaines ressources dont le contrôleur applicatif modifie lui-même des champs après création. La synchronisation semblait échouer alors que l’état réel était correct.
Solutions
Ces champs sont explicitement exclus de la comparaison. Le cas particulier d’un objet dont l’annotation de dernière configuration appliquée était corrompue a été traité en basculant sur une application côté serveur.
Résultats
- Ajout d’un cluster réduit à une entrée déclarative.
- Retour arrière d’une version applicative en une révocation de commit.
- Historique complet de qui a changé quoi, sans audit séparé.
Améliorations possibles
- Environnements de prévisualisation automatiques par demande de fusion.
- Politiques d’admission pour refuser les manifestes non conformes à l’entrée.