L'un des aspects les plus intéressants de la solution entreprise Anthos de Google, à mon sens, est Anthos Config Management (ACM). Vous configurez un dépôt Git, vous y connectez vos différents clusters, et ces derniers standardisent leurs configurations tout en empêchant toute dérive selon une logique GitOps. C'est particulièrement précieux pour les grandes entreprises qui gèrent des centaines, voire des milliers de clusters répartis sur différents sites d'hébergement.
Automatiser la configuration multi-cluster Kubernetes avec Argo CD
Inspiré par ACM, je me suis demandé s'il était possible de recréer ce type de fonctionnalité avec une autre solution GitOps : Argo CD. Bonne nouvelle : cela a fonctionné comme prévu, et lorsque j'ai modifié les fichiers de configuration dans le dépôt Git, ils se sont appliqués aux deux clusters sans accroc.
Vue d'ensemble de l'architecture
La mise en place
Pour simplifier, j'ai créé deux clusters sur le service Kubernetes managé de Google Cloud, GKE, dans deux régions distinctes afin de simuler des scénarios Est et Ouest. Vous pouvez bien sûr installer Argo CD sur des clusters n'importe où, dès lors qu'ils peuvent accéder à votre dépôt Git.
J'ai créé le script shell suivant pour tout amorcer ; cela dit, en production, je recommanderais plutôt de gérer l'infrastructure avec Terraform si possible.
Clusters initialisés
En 8 à 10 minutes, les deux clusters étaient actifs et les workloads Argo CD déployés.
Clusters Kubernetes des régions Est et Ouest
Argo CD déployé sur chaque cluster
App of Apps
La particularité de cette mise en place, c'est que j'ai aussi installé Argo CD sur chaque cluster avec une Application initiale qui s'appuie sur le pattern App of Apps pointant vers mon dépôt GitHub. Cela laisse toute latitude pour ajouter ultérieurement autant de configurations que nécessaire à un dépôt et personnaliser les clusters ou les applications que l'on y déploie.
À noter que la synchronisation automatique reste totalement optionnelle. Avec un parc de clusters massif, je la recommanderais pour que les clusters s'auto-réparent et gèrent eux-mêmes la dérive. L'un des inconvénients de l'auto-sync, en revanche, est que le rollback ne fonctionne plus.
Le dossier (chemin) applications/ contient une application (pour l'instant) appelée k8s-config.yaml, qui est elle-même une application Argo pointant vers un autre dossier contenant nos configurations Kubernetes.
Le dossier (chemin) k8s-config/ regroupe tous les fichiers YAML que nous souhaitons appliquer à mes clusters Kubernetes. Vous pouvez aussi, en option, déclarer une application qui applique les configurations de manière récursive si vous avez beaucoup de fichiers à organiser.
Dépôt de code source
Pour cette expérimentation, j'ai publié un dépôt de code source sur GitHub à l'adresse mikesparr/multi-cluster-argo-demo, avec la structure de répertoires suivante.
Structure du dépôt de code source
Tout l'exemple tient dans un seul dépôt, mais vous pourriez très bien séparer les responsabilités en utilisant plusieurs dépôts et en accordant à chaque équipe les droits de modification appropriés.
Interface Argo
En ligne de commande, vous pouvez faire un port-forward vers le service argo-server
kubectl -n argocd port-forward svc/argo-server 8080:443
Dans votre navigateur, rendez-vous sur http://localhost:8080 et acceptez l'exception de sécurité lorsque vous y êtes invité (pas de https). ASTUCE : par défaut, la connexion s'effectue avec admin et le nom complet du pod argocd-server :
Copiez argocd-server-XXXXXXX comme mot de passe par défaut
Au début, les applications (app of apps) apparaissent jusqu'à la synchronisation
Une fois votre App of Apps (applications) synchronisée, elle reconnaîtra votre première application k8s-config.
Une fois les deux applications synchronisées
En cliquant sur le panneau de l'application k8s-config, vous accédez à une vue détaillée de tout ce qu'elle a installé sur le serveur.
Tous les fichiers YAML du répertoire /k8s-config du dépôt sont appliqués au serveur
Vérifier les configurations des clusters
Basculez votre contexte kubectl sur chaque cluster et vérifiez vos namespaces, serviceaccounts, roles et rolebindings pour le test-namespace. Vous les retrouvez tous installés sur les deux clusters. Bravo !
Le cluster a installé automatiquement les workloads depuis le dépôt Git
Démo vidéo
Démo en direct : ajout d'un pod Nginx et déploiement automatique sur plusieurs clusters depuis un dépôt GitHub
Un potentiel infini
Imaginez que vous souhaitiez ajouter une API Gateway à votre stack et opter pour Ambassador ou Kong, tous deux configurés avec des CRD et du YAML. Il suffirait d'ajouter un autre dossier ou dépôt, puis un nouveau fichier YAML d'application dans le dossier applications/, et ArgoCD se chargerait automatiquement de l'installation et de la configuration.
Pour chaque application publiée par l'équipe d'engineering, il suffirait de modifier la version de l'image Docker dans un manifeste de Deployment, puis d'ouvrir une pull request : vous bénéficiez ainsi d'une validation manuelle et d'une séparation des responsabilités intégrées. Une fois la PR fusionnée, Argo CD la déploiera sur le cluster et l'environnement correspondants.
Autre cas d'usage : la prise en charge de déploiements multi-cloud avec un équilibrage du trafic via le DNS, pour une véritable configuration active-active. On peut aussi envisager la migration d'un cloud vers un autre.
J'ai hâte d'explorer d'autres possibilités et j'espère que cette approche pour garder vos clusters synchronisés sur différents environnements vous aura plu.
Nettoyage
Si vous avez utilisé le script et/ou le dépôt, n'oubliez pas de faire le ménage et de supprimer vos ressources pour éviter une facturation inutile. Le plus simple est de supprimer vos clusters avec la commande ci-dessous (ou votre projet).
gcloud container clusters delete west --zone us-west2-b
gcloud container clusters delete east --zone us-east1-c