Multi-Cluster und Multi-Region Architektur

Lernziele

Nach dieser Lektion kannst du begründen, wann eine Plattform mehrere Kubernetes-Cluster braucht und nach welchen Achsen man eine Cluster-Flotte schneidet. Du kennst das Fleet-Management-Muster mit GitOps (ArgoCD ApplicationSets), kannst Active-Passive und Active-Active über Regionen abgrenzen und weißt, warum die Daten — nicht die Cluster — das eigentlich schwere Problem von Multi-Region sind.

Das Problem: der eine große Cluster

Ein einziger Cluster für alles ist verlockend einfach — bis er es nicht mehr ist. Vier Gründe zwingen wachsende Plattformen zum Split:

Blast Radius. Ein fehlgeschlagenes Cluster-Upgrade, eine kaputte CNI-Konfiguration oder ein Ausfall der Control Plane trifft jedes Team gleichzeitig. Der teuerste Satz im Incident-Review lautet: „Es waren alle betroffen.”

Skalierungsgrenzen. Kubernetes skaliert weit, aber nicht unbegrenzt: Die offiziell getesteten Grenzen liegen bei 5 000 Nodes und 150 000 Pods pro Cluster — in der Praxis werden API-Server und etcd oft deutlich früher zäh, vor allem bei vielen Controllern und CRDs.

Heterogene Anforderungen. PCI-Workloads neben Experimenten, GPU-Knoten neben Web-Services, ein Team braucht ein Alpha-Feature, das andere maximale Stabilität — in einem Cluster bedeutet jeder Kompromiss, dass alle ihn tragen.

Upgrade-Realität. Kubernetes erzwingt mehrere Upgrades pro Jahr. Mit einem Cluster ist jedes Upgrade ein Alles-oder-nichts-Ereignis; mit einer Flotte upgradest du erst einen Canary-Cluster, dann den Rest in Wellen.

Die Gegenrechnung gehört zur ehrlichen Antwort dazu: Jeder zusätzliche Cluster kostet Geld (Control Plane, Grundlast an System-Komponenten, schlechtere Auslastung durch Fragmentierung) und vervielfacht Betriebsarbeit. Multi-Cluster ist kein Reifegrad-Abzeichen, sondern eine Abwägung.

Die Flotte schneiden: Achsen und das Management-Cluster

Wenn geteilt wird, dann entlang bewusst gewählter Achsen — typisch sind drei: Umgebung (Prod getrennt von Non-Prod ist die erste und unstrittigste Trennung), Compliance-Zone (regulierte Workloads in eigene Cluster, damit der Audit-Scope klein bleibt) und Region/Geografie (Latenz und Data Residency). Die Achse „ein Cluster pro Team” ist dagegen meist Überisolation — dafür gibt es Namespace-basierte Mandantentrennung innerhalb der Cluster.

Architektonisch entsteht das Muster aus Lektion 6 in groß: Ein Management-Cluster (Control Plane der Plattform) hält GitOps-Controller, Portal und Provisioning-Logik; die Workload-Cluster (Data Plane) führen Team-Anwendungen aus und bleiben selbst möglichst dumm — sie können jederzeit neu erzeugt werden, weil ihr gesamter Zustand deklarativ in Git liegt. Dieses „Cluster als Vieh, nicht als Haustier”-Prinzip ist die Voraussetzung für alles Weitere: Wer Cluster von Hand pflegt, kann keine Flotte betreiben.

Fleet-Management mit GitOps: einmal definieren, n-mal ausrollen

Das Standardproblem einer Flotte: Der Monitoring-Stack, die Policy-Engine, der Ingress-Controller müssen auf jeden Cluster — und zwar konsistent. Von Hand wird das bei zehn Clustern unhaltbar. Das etablierte Muster ist der Generator-Ansatz, bei ArgoCD als ApplicationSet: Eine Definition erzeugt automatisch eine Application pro Cluster, der auf ein Label-Selektor passt:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: monitoring-stack
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            env: prod
  template:
    metadata:
      name: 'monitoring-{{name}}'
    spec:
      project: platform
      source:
        repoURL: https://git.example.com/platform/addons.git
        targetRevision: main
        path: monitoring/overlays/prod
      destination:
        server: '{{server}}'
        namespace: monitoring
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

Der entscheidende Effekt: Ein neuer Cluster wird durch Registrieren und Labeln vollständig eingerichtet — alle ApplicationSets, deren Selektor passt, rollen ihre Komponenten automatisch aus. Cluster-Erstellung wird vom Projekt zum Vorgang. (Flux erreicht dasselbe mit Kustomizations pro Cluster-Verzeichnis; das Muster ist identisch: deklarative Flottendefinition statt Cluster-individueller Pflege.)

Ein Trade-off verdient Erwähnung: Zentrales Fleet-GitOps macht das Management-Cluster mächtig — es hat Schreibzugriff auf die ganze Flotte. Manche Organisationen lassen deshalb jeden Workload-Cluster seinen eigenen GitOps-Controller betreiben, der nur sein eigenes Git-Verzeichnis liest (Pull- statt Push-Topologie): weniger zentrale Angriffsfläche, dafür mehr verteilte Komponenten.

Multi-Region: das Problem sind die Daten

Mehrere Regionen löst man nicht für die Cluster — stateless Workloads in eine zweite Region zu deployen ist mit der Flotten-Mechanik von oben fast trivial. Schwer sind Traffic-Steuerung und vor allem State:

Active-Passive: Eine Region bedient den Traffic, die zweite steht bereit — von „Backups vorhanden, Aufbau im Notfall” (Stunden bis Tage Wiederanlauf) bis „komplett aufgebaut, Daten repliziert, nur Umschalten” (Minuten). Die Kenngrößen, die du im Interview nennen solltest: RTO (wie schnell ist der Dienst wieder da) und RPO (wie viele Daten dürfen maximal verloren gehen) — sie bestimmen, welche Ausbaustufe angemessen ist. Active-Passive ist konzeptionell einfach, hat aber eine bittere Wahrheit: Ein Failover, der nie geübt wird, funktioniert im Ernstfall nicht. Regelmäßige Failover-Tests sind Teil der Architektur, nicht Kür.

Active-Active: Beide Regionen bedienen Traffic (Routing über DNS- oder Anycast-basierte Verfahren, idealerweise mit Geo-Nähe). Für stateless Services gut machbar — für Daten beginnt hier die eigentliche Architekturarbeit: Synchrone Replikation über Regionen kostet Latenz bei jedem Schreibvorgang (Lichtgeschwindigkeit verhandelt nicht), asynchrone Replikation bedeutet im Failover-Fall Datenverlust im Rahmen des Replikations-Lags und bei echtem Multi-Master Konflikte, die jemand auflösen muss. Das ist der CAP-Trade-off in der Praxis: Konsistenz, Verfügbarkeit und Partitionstoleranz bekommst du nicht gleichzeitig in voller Stärke.

Die reife Antwort ist deshalb fast immer differenziert: pro Datenklasse entscheiden. Sessions und Caches dürfen verloren gehen (kein Replikationsproblem), Produktkatalog verträgt asynchrone Replikation mit Sekunden Lag, Zahlungsdaten brauchen starke Konsistenz — und vielleicht ist genau dieser eine Service der Grund, eine Region als primär zu definieren, während der Rest aktiv-aktiv läuft.

Praxis: ein Flotten-Design entwerfen

Szenario: SaaS-Anbieter, 60 Teams, Kunden in EU und USA, eine PCI-relevante Zahlungskomponente, Vorgabe: regionaler Ausfall darf maximal 30 Minuten Nichtverfügbarkeit kosten (RTO 30 min, RPO 5 min).

1. Flotte schneiden: Lege Anzahl und Zweck der Cluster fest (Management, Prod/Non-Prod, EU/US, PCI). Begründe jeden Cluster mit einer der vier Split-Achsen — Cluster ohne klare Achse streichst du.
2. Label-Schema: Definiere die Cluster-Labels (z. B. env, region, compliance), mit denen deine ApplicationSets die Flotte selektieren. Schreibe für den Monitoring-Stack das passende ApplicationSet-Gerüst (wie oben, angepasst auf dein Schema).
3. Region-Strategie: Entscheide Active-Active oder Active-Passive für (a) das stateless Web-Frontend, (b) die Produktdatenbank, (c) die Zahlungskomponente — je zwei Sätze mit RTO/RPO-Bezug.
4. Failover-Probe: Skizziere in fünf Stichpunkten, wie ein geplanter Failover-Test der EU-Region abläuft — inklusive des Kriteriums, ab wann der Test als bestanden gilt.

Typische Stolperfallen

Multi-Cluster als Selbstzweck. Wer ohne Blast-Radius-, Skalierungs- oder Compliance-Argument splittet, kauft Betriebsaufwand ohne Gegenwert. Erst die Achse, dann der Cluster.

Die Flotte konsistent wähnen, ohne es zu erzwingen. Ohne durchgängiges Fleet-GitOps driften Cluster auseinander — und der zehnte Cluster verhält sich subtil anders als der ersten neun. Konsistenz ist ein Mechanismus, kein Vorsatz.

Multi-Region ohne Datenkonzept. Zwei Regionen mit Clustern und ein „die Datenbank replizieren wir dann” ist keine DR-Strategie. RPO/RTO pro Datenklasse zuerst.

Failover nur auf dem Papier. Ungeübte Failover scheitern an Details, die niemand bedacht hat: DNS-TTLs, hartkodierte Endpunkte, fehlende Secrets in der zweiten Region. Der Test ist der Beweis — alles andere ist Hoffnung.

Interview-Vorbereitung

Auf „Wann und wie würdest du auf Multi-Cluster gehen?” antwortest du am stärksten so: Treiber nennen (Blast Radius, Skalierungsgrenzen, Compliance, Upgrade-Strategie) → Kostenseite ehrlich benennen (Betrieb, Geld, Fragmentierung) → Schnitt-Achsen (Umgebung, Compliance, Region — nicht pro Team) → Mechanik (Management- vs. Workload-Cluster, Fleet-GitOps mit Generator-Pattern, Cluster als ersetzbares Vieh).

Rechne mit diesen Follow-ups:

• „Wie rollst du eine Komponente konsistent auf 20 Cluster aus?” — ApplicationSet/Kustomization mit Label-Selektoren; neue Cluster erben durch Registrierung und Labels automatisch den Soll-Zustand.
• „Active-Active oder Active-Passive?” — Gegenfrage nach RTO/RPO und Datenklassen; stateless gern aktiv-aktiv, bei strenger Konsistenz einzelner Daten eher primäre Region plus schneller Failover.
• „Was begrenzt die Größe eines einzelnen Clusters?” — Getestete Obergrenzen (5 000 Nodes / 150 000 Pods), praktisch früher: etcd- und API-Server-Last, Controller-Menge — plus das Blast-Radius-Argument unabhängig von Technik.
• „Wie hältst du Upgrades über die Flotte beherrschbar?” — Wellen-Rollout: Canary-Cluster zuerst, Soak-Zeit, dann gestaffelt; möglich nur, weil Cluster deklarativ reproduzierbar sind.

Zusammenfassung

Multi-Cluster ist die Antwort auf Blast Radius, Skalierungsgrenzen, Compliance-Trennung und Upgrade-Risiko — bezahlt mit Betriebsaufwand und Fragmentierung, also nur entlang klarer Achsen (Umgebung, Compliance, Region). Beherrschbar wird die Flotte durch das Management-/Workload-Muster und Fleet-GitOps mit Generatoren: Cluster sind ersetzbares Vieh, deren Soll-Zustand vollständig in Git liegt. Multi-Region ist für stateless Workloads Flotten-Routine — die echte Arbeit steckt in den Daten: RTO/RPO pro Datenklasse, Replikations-Trade-offs und geübte Failover.

Ob man die Bausteine dafür selbst baut, kauft oder aus dem Open-Source-Regal adoptiert, ist eine eigene Entscheidungsklasse — das Thema der nächsten Lektion.