Case: GitOps Fleet (20 Cluster)

Lernziele

Nach dieser Lektion kannst du den Fleet-Case durchspielen: GitOps für 20 Kubernetes-Cluster über drei Regionen, mit Platform-Addons auf allen Clustern und Team-Anwendungen auf Teilmengen davon. Du kennst die zwei Grundtopologien (zentraler Management-Cluster vs. dezentrale Agents), kannst eine Repo-Struktur begründen, die Plattform- und Team-Verantwortung trennt, und hast Antworten auf die Standardfragen zu Single Point of Failure, Addon-Rollouts und Cluster-Bootstrap.

Das Szenario

„Ihr betreibt 20 Kubernetes-Cluster in EU, US und APAC — 6 Produktion, 6 Staging, 8 Dev. Auf allen laufen dieselben Platform-Addons wie CNI, Policy-Engine und Monitoring-Agent; Anwendungen werden je nach Team nur auf bestimmte Cluster deployed. Designe das GitOps-Setup.” Dieser Case prüft, ob du Deployment als Fleet-Problem denkst — eine Änderung an einem Addon betrifft 20 Cluster, und ein naives „überall gleichzeitig” macht aus einem Tippfehler einen globalen Incident.

Anforderungen klären: Fleet ist nicht 20 × Single Cluster

Vier Fragen, die das Design bestimmen:

• „Wie homogen sind die Cluster?” — Angenommen: gleiche Kubernetes-Distribution, aber unterschiedliche Größen und regionsspezifische Konfiguration (Endpoints, Zertifikate, Compliance-Labels). Konsequenz: Du brauchst Templating über Cluster hinweg, nicht 20 kopierte Verzeichnisse.
• „Wer deployed was — und wer darf was kaputt machen?” — Angenommen: Das Plattform-Team verantwortet die Addons auf allen Clustern, ~15 Produktteams deployen ihre Apps selbst auf zugewiesene Cluster. Konsequenz: zwei getrennte Verantwortungsbereiche, die sich in Repos und RBAC widerspiegeln müssen.
• „Gibt es Anforderungen an regionale Unabhängigkeit?” — Wenn EU-Deployments auch bei US-Ausfall laufen müssen, scheidet ein einzelner globaler Management-Cluster aus. Angenommen: wünschenswert, aber keine harte Vorgabe.
• „Wie entstehen neue Cluster?” — Angenommen: Terraform provisioniert, danach soll der Cluster ohne Handarbeit seinen Soll-Zustand erreichen. Das ist die Bootstrap-Frage, die viele Kandidaten vergessen.

Eine Abschätzung lohnt sich: 20 Cluster × ~25 Platform-Addons plus ~150 App-Deployments auf Teilmengen ergibt grob 600–800 Argo-CD-Applications. Das ist für eine Argo-CD-Instanz machbar, aber nur mit Generatoren statt Handarbeit — 800 von Hand gepflegte Application-Manifeste sind der sichere Weg ins Chaos.

Architektur: Hub-and-Spoke, ApplicationSets und die Repo-Frage

Die erste Grundsatzentscheidung ist die Topologie. Variante A: ein zentraler Management-Cluster mit Argo CD, der alle 20 Cluster über deren API-Server bedient (Hub-and-Spoke) — eine zentrale Sicht auf die Flotte, ein RBAC-Modell, ein Ort für Drift-Erkennung. Variante B: jeder Cluster zieht selbst aus Git, etwa mit Flux — kein zentraler Ausfallpunkt, keine Credentials aller Cluster an einer Stelle, dafür 20 Installationen ohne eingebaute Fleet-Übersicht, die selbst aktuell gehalten werden wollen.

Vertretbare Empfehlung: Hub-and-Spoke mit Argo CD, aber pro Region eine Instanz (EU, US, APAC) statt einer globalen. Das begrenzt den Blast Radius, hält Sync-Traffic regional und bleibt mit drei Instanzen betreibbar. Sage dazu den entlastenden Satz laut: „Wenn der Management-Cluster ausfällt, laufen alle Workloads weiter — es pausieren nur Deployments und Drift-Korrektur. Das macht den SPOF erträglich, aber nicht egal.”

Die Mechanik gegen 800 handgepflegte Applications sind ApplicationSets: Der Cluster-Generator erzeugt aus der Liste der registrierten Cluster automatisch eine Application pro Cluster und Addon. Cluster tragen Labels wie env=prod, region=eu, wave=2 — und genau über diese Labels steuerst du später gestaffelte Rollouts. Ein neuer Cluster, der registriert und gelabelt wird, bekommt seine komplette Addon-Ausstattung ohne eine Zeile zusätzliches YAML.

Die Repo-Struktur spiegelt die Verantwortung:

platform-gitops/          # Ownership: Plattform-Team
  addons/<addon>/base/    # gemeinsame Basis
  addons/<addon>/overlays/{dev,staging,prod}/
  clusters/<cluster>/     # clusterspezifische Werte, Labels

team-<x>-gitops/          # Ownership: Produktteam
  apps/<app>/overlays/{staging,prod}/

Wichtig: Umgebungen als Verzeichnisse, nicht als Git-Branches. Branch-per-Environment klingt naheliegend, führt aber zu Dauer-Merges zwischen Branches, die auseinanderdriften — Promotion von Staging nach Prod ist dann ein konfliktträchtiger Merge statt eines reviewbaren Diffs auf einen Overlay-Ordner.

Bootstrap schließt den Kreis: Terraform erstellt den Cluster und registriert ihn (Cluster-Secret mit Labels) bei der regionalen Argo-CD-Instanz. Ab da übernimmt ein App-of-Apps- bzw. ApplicationSet-Muster: Die Registrierung selbst ist der Trigger, der alle Addons aufspielt. Neuer Cluster bis zur Betriebsbereitschaft: eine Pipeline, kein Runbook.

Einwände des Interviewers

„Du rollst eine neue Cilium-Version aus und sie ist kaputt — was passiert?” Die wichtigste Frage des Cases. Antwort: gestaffelte Rollouts über Cluster-Labels. Die neue Version geht zuerst auf Dev-Cluster (wave=0), nach Soak-Time auf Staging, dann regionsweise auf Prod — jeweils ein eigener Commit bzw. eine eigene Overlay-Änderung, nie ein globaler Schalter. Bei einem CNI kommt dazu: Sync-Windows und manuelle Sync-Freigabe für Prod, weil ein fehlerhaftes CNI-Upgrade dir den Cluster-Netzwerkverkehr zerlegt, bevor irgendein Healthcheck greift.

„Der Management-Cluster hält Admin-Credentials für 20 Cluster — Security-Problem?” Ehrlich bejahen: Das ist die teuerste Eigenschaft von Hub-and-Spoke. Mitigation: Argo CD bekommt pro Ziel-Cluster ein dediziertes ServiceAccount mit möglichst engen Rechten statt cluster-admin, der Management-Cluster selbst ist maximal gehärtet und hat keinen Workload-Betrieb. Wer diese Restrisiken nicht tragen will, landet bei der Pull-Variante — das ist der legitime Hauptgrund, Flux zu wählen.

„Wie kommt eine App-Version von Staging nach Prod?” Promotion als Git-Operation: Ein Commit — oft automatisiert durch die CI nach erfolgreichen Staging-Checks — hebt den Image-Tag im Prod-Overlay an; Review, Merge, Sync. Der Audit-Trail ist die Git-History.

„Was, wenn jemand direkt im Cluster ändert?” Self-Heal aktiviert: Argo CD stellt den Git-Zustand wieder her und meldet den Drift. Für Break-Glass-Situationen gibt es einen definierten Pfad (Sync pausieren, ändern, nachziehen per Commit) — Ausnahmen brauchen einen Prozess, sonst werden sie zur Regel.

Praxis

Spiele den Case 40 Minuten laut mit Timer. Pflichtbestandteile:

1. Die vier Klärungsfragen inklusive Bootstrap-Frage, mit zusammengefassten Annahmen.
2. Die Abschätzung „~600–800 Applications” und die Schlussfolgerung „Generatoren statt Handarbeit”.
3. Die Topologie-Entscheidung mit ehrlicher Nennung beider Varianten und Begründung für regionale Hubs.
4. Ein durcherzählter Addon-Rollout über Waves — von Commit bis Prod, inklusive dem Sonderfall CNI.
5. Der Bootstrap-Fluss: Terraform → Cluster-Registrierung → Addons erscheinen automatisch.

Variiere danach die Vorgabe: „200 Cluster statt 20, Edge-Standorte mit instabiler Anbindung.” Beobachte, wie die Antwort Richtung Pull-Modell kippt — instabile Verbindungen vom Hub zu den Spokes sprechen gegen zentrales Pushen.

Typische Stolperfallen

Fleet als 20 Einzelcluster behandeln. Wer pro Cluster ein kopiertes Verzeichnis pflegt, hat bei der nächsten Addon-Änderung 20 Diffs und garantierten Drift. Templating über Generatoren und Overlays ist der Kern des Cases.

Branch-per-Environment vorschlagen. Der Klassiker, der erfahrene Interviewer sofort triggert. Verzeichnisse/Overlays statt Branches — Promotion als Diff, nicht als Merge.

Den SPOF kleinreden oder verschweigen. Stark ist, wer ihn selbst anspricht: Workloads laufen weiter, Deployments pausieren, regionale Instanzen begrenzen das Risiko — und die Wiederherstellung des Management-Clusters ist selbst GitOps, sein Zustand liegt in Git.

Bootstrap und Tag-Updates vergessen. „Wie kommt der neue Cluster zu seinem Zustand?” und „Wer schreibt den neuen Image-Tag ins Repo?” sind Standardnachfragen. Ohne Antwort darauf bleibt das Design eine Schönwetter-Skizze.

Interview-Vorbereitung

Deine Kernbotschaft: Regionale Argo-CD-Hubs, ApplicationSets mit Cluster-Generator und Labels als Steuerungsebene, Repos getrennt nach Plattform- und Team-Ownership, Umgebungen als Verzeichnisse, Rollouts in Waves mit Soak-Time — und der Cluster-Bootstrap endet in der Registrierung, ab da ist alles deklarativ.

Rechne mit diesen Follow-ups:

• „Argo CD oder Flux für die Flotte?” — Kriterien statt Religion: zentrale Fleet-Sicht und UI vs. kein zentraler Ausfallpunkt und kein zentraler Credential-Speicher; beides ist vertretbar, die Topologie-Frage ist wichtiger als der Tool-Name.
• „Was passiert, wenn das Management down ist?” — Workloads unbeeinträchtigt, Deployments und Drift-Korrektur pausieren; regionale Instanzen begrenzen den Schaden.
• „Wie verhinderst du, dass ein Addon-Update alle Prod-Cluster gleichzeitig trifft?” — Waves über Cluster-Labels, getrennte Overlays, Sync-Windows; nie ein Commit, der global wirkt.
• „Wie skaliert das auf 200 Cluster?” — Mehr Hubs (Sharding der Argo-CD-Controller oder mehr Regionen/Zellen), Cluster-Registrierung selbst automatisiert; ab sehr großen, schwach angebundenen Flotten Pull-Modell erwägen.

Zusammenfassung

Der Fleet-Case dreht sich um drei Entscheidungen: Topologie (regionale Hubs als Mittelweg zwischen globalem SPOF und 20 Insellösungen), Mechanik (ApplicationSets und Labels statt handgepflegter Applications) und Prozess (Waves mit Soak-Time, Promotion als Git-Diff, Bootstrap bis zur Registrierung automatisiert). Wer zusätzlich die ehrlichen Schwächen benennt — Credential-Konzentration im Hub, pausierende Deployments bei Hub-Ausfall — wirkt wie jemand, der so eine Flotte schon betrieben hat. In der nächsten Lektion wechselt der Gegenstand: Statt Deployments verwaltest du Geheimnisse — eine zentrale Secrets-Plattform für 100 Teams, bei der nichts im Klartext in Git landen darf.