Einer der aus meiner Sicht spannendsten Bausteine von Googles Enterprise-Lösung Anthos ist Anthos Config Management (ACM). Sie richten ein Git-Repo ein, verbinden Ihre Cluster damit, und diese vereinheitlichen ihre Konfigurationen und verhindern Drift nach GitOps-Manier. Gerade für große Unternehmen, die Hunderte bis Tausende Cluster an verschiedenen Hosting-Standorten betreiben, ist das ein entscheidender Vorteil.
Kubernetes Multi-Cluster-Config mit Argo CD automatisieren
Inspiriert von ACM habe ich mich gefragt, ob sich diese Funktionalität mit einer anderen GitOps-Lösung nachbauen lässt: Argo CD. Mit Freude kann ich berichten: Es hat genauso funktioniert wie erhofft – Änderungen an Konfigurationsdateien im Git-Repo wurden nahtlos auf beide Cluster übertragen.
Architekturübersicht
Das Setup
Der Einfachheit halber habe ich zwei Cluster auf Google Clouds Managed-Kubernetes-Service GKE in zwei unterschiedlichen Regionen aufgesetzt, um East- und West-Szenarien zu simulieren. Argo CD lässt sich natürlich auf Clustern an beliebigen Standorten installieren – Hauptsache, sie haben Zugriff auf Ihr Git-Repo.
Zum Bootstrappen habe ich das folgende Shell-Skript geschrieben. Für den Produktivbetrieb empfehle ich allerdings, die Infrastruktur möglichst über Terraform zu verwalten.
Gebootstrappte Cluster
Innerhalb von 8–10 Minuten waren beide Cluster aktiv und die Argo-CD-workloads ausgerollt.
Kubernetes-Cluster in den Regionen East und West
Argo CD auf jedem Cluster ausgerollt
App of Apps
Das Besondere an diesem Setup: Auf jedem Cluster habe ich Argo CD zusätzlich mit einer initialen Application installiert, die nach dem App-of-Apps-Pattern auf mein GitHub-Repository verweist. So können Sie später beliebig viele Konfigurationen ins Repo aufnehmen und die Cluster bzw. die darauf laufenden Apps individuell anpassen.
Beachten Sie: Die automatische Synchronisierung ist rein optional. Bei sehr vielen Clustern würde ich sie empfehlen, damit sich die Cluster selbst heilen und Drift im Griff behalten. Ein Nachteil von Auto-Sync ist allerdings, dass die Rollback-Funktion nicht mehr greift.
Der Ordner applications/ (Pfad) enthält (vorerst) eine App namens k8s-config.yaml – wiederum eine Argo-App, die auf einen weiteren Ordner mit unseren Kubernetes-Konfigurationen zeigt.
Der Ordner k8s-config/ (Pfad) enthält alle YAML-Dateien, die auf meine Kubernetes-Cluster angewendet werden sollen. Optional können Sie auch eine App definieren, die Konfigurationen rekursiv anwendet, falls Sie viele Dateien zu strukturieren haben.
Source-Code-Repository
Für mein Experiment habe ich ein Source-Code-Repository auf GitHub unter mikesparr/multi-cluster-argo-demo mit folgender Verzeichnisstruktur veröffentlicht.
Struktur des Source-Code-Repositorys
In diesem Beispiel liegt alles in einem einzigen Repository, Sie könnten die Bereiche aber genauso gut auf separate Repositories aufteilen und verschiedenen Teams jeweils eigene Bearbeitungsrechte erteilen.
Argo UI
Über die Kommandozeile richten Sie ein Port-Forwarding auf den Service argo-server ein:
kubectl -n argocd port-forward svc/argo-server 8080:443
Rufen Sie im Browser http://localhost:8080 auf und bestätigen Sie bei Bedarf die Sicherheitsausnahme (kein HTTPS). TIPP: Standardmäßig melden Sie sich mit admin und dem vollständigen Namen des argocd-Server-Pods an:
Kopieren Sie argocd-server-XXXXXXX als Standardpasswort
Zunächst erscheint nur die Applications-App (App of Apps), bis sie synchronisiert ist
Sobald Ihre App of Apps (applications) synchronisiert ist, erkennt sie Ihre erste App k8s-config.
Nachdem beide Applications synchronisiert sind
Wenn Sie auf das App-Panel k8s-config klicken, sehen Sie eine detaillierte Übersicht über alles, was auf dem Server installiert wurde.
Sämtliche YAML-Dateien aus dem Verzeichnis /k8s-config im Repo werden auf den Server angewendet
Cluster-Konfigurationen prüfen
Wechseln Sie den kubectl-Kontext jeweils auf einen Cluster und prüfen Sie die namespaces, serviceaccounts, roles und rolebindings für den test-namespace. Sie werden sehen: Alles ist auf beiden Clustern installiert. Glückwunsch!
Cluster hat workloads automatisch aus dem Git-Repo installiert
Video-Demo
Live-Demo: Nginx-Pod hinzufügen und automatisch aus dem GitHub-Repo auf mehrere Cluster ausrollen
Grenzenloses Potenzial
Angenommen, Sie möchten Ihrem Stack ein API Gateway hinzufügen und entscheiden sich für Ambassador oder Kong – beide werden über CRDs und YAML konfiguriert. Sie legen einfach einen weiteren Ordner oder ein weiteres Repo an, fügen im Ordner applications/ eine zusätzliche App-YAML hinzu, und Argo CD installiert und konfiguriert alles automatisch für Sie.
Für jede Anwendung, die das Engineering-Team veröffentlicht, lässt sich die Docker-Image-Version in einem Deployment-Manifest anpassen und ein Pull Request für die Änderung erstellen – damit haben Sie manuelle Freigaben und eine saubere Funktionstrennung von Haus aus eingebaut. Sobald der PR gemerged ist, rollt Argo CD die Änderung auf den jeweiligen Cluster und die jeweilige Umgebung aus.
Ein weiterer Anwendungsfall wäre die Unterstützung von Multi-Cloud-Deployments mit DNS-basiertem Traffic-Balancing für eine echte Active-Active-Konfiguration. Auch eine Migration von einer Cloud zur anderen ist denkbar.
Ich freue mich darauf, weitere Möglichkeiten auszuprobieren, und hoffe, Ihnen hat dieser weitere Ansatz gefallen, Cluster über verschiedene Umgebungen hinweg synchron zu halten.
Aufräumen
Falls Sie das Skript und/oder das Repository genutzt haben, denken Sie bitte daran, Ihre Ressourcen wieder aufzuräumen, um unnötige Kosten zu vermeiden. Am einfachsten löschen Sie Ihre Cluster (oder gleich Ihr Projekt) mit folgendem Befehl:
gcloud container clusters delete west --zone us-west2-b
gcloud container clusters delete east --zone us-east1-c