GitOps ist ein üblicher Weg, Anwendungen in Kubernetes auszurollen. Ein Praxisbericht über eine GitOps-Control-Plane mit 34 Clustern zeigt einen anderen Schwerpunkt: Git steuert dort nicht Anwendungen, sondern ganze Cluster. Der Engpass war nicht das Werkzeug, sondern die Frage, wie viele Abkürzungen man sich leisten kann. Der Autor ist Software Engineer und hat die Plattforminfrastruktur bei Lucid Motors mit aufgebaut. Er beschreibt eine Zentrale über 22 AWS-Accounts und eine Oracle-Cloud-Tenancy in fünf Regionen auf drei Kontinenten. Wer Kubernetes-Clusterverwaltung für mehr als eine Handvoll Cluster plant, findet darin keine Anleitung, sondern eine Liste der Stellen, an denen es teuer wird.
Anfang Oktober veröffentlichte Red Hat einen Durchgang, in dem Argo CD ApplicationSets gehostete Control Planes direkt aus Git ausrollen. Einen Tag später fiel GitHub für Stunden aus, mit Folgen für Actions, Git-Operationen und Pull Requests. Zusammen zeigt das zwei Dinge: Die Ebene verwaltet inzwischen Infrastruktur, nicht nur Manifeste, und sie hängt an einem Git-Layer, der nicht immer antwortet. Der Text prüft, was der Bericht zeigt, wo die Zahlen belastbar sind und was sich auf andere Umgebungen übertragen lässt.
Was die Zentrale steuert und was die Außenstellen entscheiden
Das Modell ähnelt einer Leitwarte mit Außenstellen. Die Zentrale hält die einzige Argo-CD-Instanz für Plattformkomponenten, die Cluster-Registrierungen, die Identität des Cluster-API-Controllers und drei ApplicationSets: ein Basis-Setup pro Cluster über ein App-of-Apps-Chart, gemeinsame Plattformdienste auf den Clustern, die sie beherbergen, und die Cluster-API-Definitionen der Cluster selbst. Alles Weitere läuft in den Außenstellen.
Wichtig ist, dass die Außenstellen Nein sagen können. Jeder Cluster entscheidet über seine Authentifizierungskonfiguration und ob er die Rolle der Zentrale zulässt. Jeder Cluster besitzt die Rolle, die Cluster API in seinem Inneren verwendet; seine Workloads beziehen Cloud-Rollen vom eigenen Identity Provider. In AWS lagerte die Zentrale keine langlebigen accountübergreifenden Secrets, sondern erhielt kurzlebige Credentials. Deren Vergabe wurde auf der Außenseite deklariert und in Git geprüft. Bei Oracle Cloud ließ sich das nicht herstellen; dort las die Registrierung weiterhin ein gespeichertes Credential aus einem Vault.
Der lehrreichste Satz des Berichts: Man soll aufschreiben, wo das eigene Modell bricht. Beim Autor brach es beim zweiten Provider. Das gehört zu einer ehrlichen Architekturbeschreibung. Ein Modell, das nur bei einem Anbieter hält, ist keine Regel, sondern eine Konvention. Wer Multi-Cloud-Kubernetes mit GitOps verwalten will, sollte diese Bruchstelle kennen, bevor sie in einem Audit auftaucht.
Der Vertrag ist das Produkt: jeder Cluster als kleine Konfigurationsdatei
Der Schritt, der den Rest beherrschbar machte, war unspektakulär: Jeder Cluster wurde als kleine Konfigurationsdatei mit rund zwanzig Schlüsseln behandelt. Die Schlüssel beschrieben Identität, Account-Grenze, Region und Umgebung, den Weg zur API des Clusters, delegiertes DNS und Zertifikate sowie Ausstiegsoptionen. Alles andere wurde daraus abgeleitet: welche Applications der Cluster bekam, seine IAM-Rollennamen, seine Cluster-API-Identität, seine DNS-Delegation, seine Kosten-Tags.
Nichts davon wurde nachgelagert separat gepflegt. Das klingt nach einem Detail, macht aber Änderungen am gesamten Fuhrpark billig. Ein Cluster kam über eine Label-Änderung an seiner Registrierung in einen Verbund. Eine Komponente kam über eine Zeile in einer Liste in einen Verbund. Die Verteilung übernahm ein Matrix-Generator. Auch die Oracle-Tenancy, die aus einer Expansion in den Nahen Osten stammte und vom Autor verantwortet wurde, kam über denselben Vertrag ins Bild – nicht als Sonderfall. Der Test für einen Vertrag ist, ob der ungewöhnlichste Fall durch dieselbe Tür geht wie der langweiligste.
Für eine Organisation verschiebt das die Verantwortung. Wer einen Cluster will, schreibt keine Tickets an das Plattformteam, sondern eine Werte-Datei. Das Plattformteam pflegt nicht Cluster, sondern die Ableitungsregeln. Fragen, die vorher in Meetings geklärt wurden, stehen danach als Schlüssel in einem Review.
Warum 174 Helm Charts zum Risiko werden
Bei 174 Helm Charts, die 1.214 Argo-CD-Application-Objekte rendern, ist Argo CD selbst nicht das Problem. Das Problem ist eine Werteänderung, die für einen Cluster sauber rendert und dreißig andere bricht. Diese Erfahrung macht man erst bei Größe: Nicht die Steuerungsebene wird fragil, sondern die Vielfalt der Eingaben.
Zwei Gewohnheiten hielten das im Zaum. Erstens rendert die CI bei jedem Merge Request alles: Jedes Chart musste für sich rendern, jedes App-of-Apps-Chart gegen jeden Cluster-Vertrag, jede Cluster-Definition und jedes von einer Application referenzierte Chart mit exakt den Werten, die es tatsächlich erhalten würde. Zweitens rendert die CI den Zielbranch und stellt den Manifest-Diff in den Merge Request. Prüfer sehen dann, was sich auf den Clustern tatsächlich ändert, nicht, wie ein Template editiert wurde.
Das unterscheidet eine CI-Pipeline für Helm Charts und Manifeste, die Tests sammelt, von einer, die Wirkung zeigt. Ein Template-Diff beantwortet die Frage „Was habe ich getippt?“. Ein Manifest-Diff beantwortet die Frage „Was passiert morgen um drei auf Produktion?“. Nur die zweite Frage ist im Review nützlich. Bei Argo CD ApplicationSets in großem Maßstab kommt hinzu, dass der Generator selbst zur Fehlerquelle wird – eine falsche Matrix-Kombination erzeugt keine kaputte Datei, sondern dreißig kaputte Cluster.
Drift messen, ohne sich selbst zu betrügen
Die Zahlen im Bericht werden vom Autor selbst relativiert. Konfigurationsdrift ging von 24,3 Vorfällen pro Monat vor der Umstellung auf 0,9 danach, gemessen über zwei Fenster von je 90 Tagen. Die Zahl davor stammte aus Incidents, die als Drift markiert waren – und diese Markierung war unvollständig. Die Zahl danach stammte aus Diff-Ereignissen des Controllers mit bestätigter Ursache außerhalb des Git-Wegs. Die Methoden unterscheiden sich, also ist es keine saubere Reduktion um 96 Prozent.
Die Zahlen zeigen trotzdem den Punkt: Sobald Drift instrumentiert war, war sie selten – und der Controller korrigierte jeden Fall innerhalb seines Reconciliation-Intervalls, ohne dass jemand eingriff. Das ist die belastbare Aussage, nicht der Prozentwert. Wer Konfigurationsdrift in Kubernetes reduzieren will, sollte zuerst die Messung vereinheitlichen. Zähle vorher und nachher auf dieselbe Weise, sonst misst man den Wechsel der Buchführung und nennt es Fortschritt.
Für die zweite Kennzahl gilt dasselbe. Die Onboarding-Zeit sank im Bericht von durchschnittlich 4,0 Tagen auf 1,7 Stunden – aber in der Zwischenzeit fielen manuelle Freigabeschritte weg, die Messfenster unterschieden sich, und die Stichproben umfassten acht beziehungsweise elf Cluster. Der Autor schreibt selbst, dass daraus kein direkter Vergleich werden darf. Die Richtung ist trotzdem klar.
Für den schlechten Tag entwerfen
Bei dieser Größe ist der gefährlichste Fehlerfall nicht der Ausfall, sondern der einzelne schlechte Commit. Deshalb schränkte das Team die Voreinstellungen von Argo CD an zwei Stellen ein. Jedes ApplicationSet war so konfiguriert, dass es beim Löschen bereits ausgerollte Ressourcen erhält – das Entfernen eines Eintrags konnte also keine Kaskadenlöschung auslösen. Cluster-Objekte trugen eine No-Prune-Einstellung, sodass ein Revert eines Commits keinen laufenden Cluster löschen konnte.
Dahinter steht ein Prinzip: Reconciliation sollte proportional zum Blast Radius und zur Umkehrbarkeit sein. Ein Deployment darf sich selbst heilen. Ein Cluster darf das nicht. Dasselbe Denken gilt für Ausfälle wie den von GitHub. In einem Hub-and-Spoke-Design laufen die Workloads in den Außenstellen; ist Git oder die Zentrale nicht erreichbar, laufen bestehende Workloads weiter, auch wenn Deployments und Konfigurationsänderungen stocken. Das Ziel ist nicht Hochverfügbarkeit der Steuerungsebene um jeden Preis, sondern die Trennung zweier Ausfallarten: Ein Ausfall der Control Plane darf kein Ausfall der Workloads werden.
Die unbequeme Kehrseite: Die Zentrale ist das privilegierteste System, das man betreibt. Ein Kompromittieren des Repositories oder der CI hat nach dem Merge die Reichweite der Zentrale. Wer hier spart, spart an der falschen Stelle.
Cluster 35: was ein neuer Cluster kostet
Ein neuer Cluster unter Verwaltung brauchte vier Schritte: die IAM-Rollen nach dem Namensmuster einmalig in Terraform anlegen, die Werte-Datei des Clusters schreiben, einen Merge Request öffnen, damit die CI den gesamten Graphen rendert und den Diff einstellt, und schließlich mergen und die Registrierung labeln. Ältere, von Hand gebaute Cluster wurden über einen expliziten Importpfad an Ort und Stelle übernommen, statt sie neu zu bauen.
Wichtiger als die Zeitersparnis ist die Form des Zuwachses. Ein neuer Cluster ist kein Projekt mehr, sondern ein Vorgang. Das unterscheidet Kubernetes-Clusterverwaltung als Handwerk von einer Dienstleistung: Bei GitOps für viele Kubernetes-Cluster zählt nicht, wie schnell der erste Cluster steht, sondern wie gleichförmig der fünfunddreißigste entsteht.
Keine dieser Beobachtungen ändert die GitOps-Prinzipien: Zustand deklarieren, ihn prüfen, einen Controller darauf konvergieren lassen. Was Skalierung verändert, ist der Preis jeder Abkürzung. Ein Credential, das in der Zentrale liegt, eine Werte-Datei, die niemand rendert, eine Prune-Einstellung, die auf Voreinstellung bleibt: Bei fünf Clustern sind das Gewohnheiten, bei vierunddreißig sind es Vorfälle mit einem Datum. Für den eigenen Aufbau heißt das: erst den Vertrag definieren, dann die Cluster zählen. Erst die Drift-Messung vereinheitlichen, dann über Erfolge sprechen. Erst die Löschvoreinstellungen prüfen, dann automatisieren. Und die Zentrale behandeln wie das, was sie ist – das privilegierteste System im Haus.
Quelle: cloudnativenow.com
