Stretched Cluster vs. Multi-Region: Die Architektur-Wahl für maximale Resilienz

Bei der Planung einer standortübergreifenden Infrastruktur stehen Architekten oft vor einer Grundsatzentscheidung: Spannen wir einen einzelnen Kubernetes-Cluster über zwei geografische Standorte hinweg (Stretched Cluster) oder betreiben wir in jeder Region einen eigenständigen Cluster?

Die Idee eines Stretched Clusters wirkt auf den ersten Blick elegant: Man hat nur eine einzige Steuerungsebene (Control Plane), und Kubernetes verteilt die Workloads automatisch über beide Standorte. Doch was in der Theorie nach Einfachheit klingt, erweist sich in KRITIS-Umgebungen oft als riskante Komplexitätsfalle.

Das Problem: Wenn die Kopplung zum Risiko wird

Ein Stretched Cluster erfordert eine extrem verlustfreie und latenzarme Verbindung zwischen den Standorten. Erzeugt man diese harte Kopplung, entstehen neue Abhängigkeiten:

1. Latenz-Sensitivität: Die interne Kommunikation von Kubernetes (insbesondere der State-Store etcd) reagiert allergisch auf Schwankungen in der Netzwerkverbindung zwischen den Standorten. Ein kurzer Schluckauf in der Leitung kann den gesamten Cluster instabil machen.
2. Der “Split-Brain”-Effekt: Bricht die Verbindung zwischen den Standorten ab, versuchen beide Seiten oft gleichzeitig, die Führung zu übernehmen oder stoppen den Betrieb komplett, weil das Quorum fehlt.
3. Globaler Blast Radius: Ein Fehler in der zentralen Control Plane oder eine Fehlkonfiguration betrifft sofort beide Standorte. Damit verliert man den wichtigsten Vorteil der Georedundanz: die Fehlertoleranz durch Unabhängigkeit.

Die Lösung: Autarke Cluster und das “Shared-Nothing”-Prinzip

Für KRITIS-Szenarien hat sich die Multi-Region-Architektur mit entkoppelten Clustern als der robustere Weg erwiesen. Hierbei wird in jeder Region ein vollständig autonomer Kubernetes-Cluster betrieben.

1. Begrenzung des Schadensbereichs

Da jeder Cluster über eine eigene Control Plane verfügt, ist er vollkommen unabhängig. Ein technisches Problem oder ein missglücktes Update in Region A hat physikalisch keine Auswirkungen auf Region B. Dieser “Shared-Nothing”-Ansatz ist die sicherste Form der Isolation.

2. Regionale Autonomie

Fällt die Netzwerkverbindung zwischen den Standorten aus, arbeiten beide Cluster lokal ohne Einschränkungen weiter. Es gibt keinen Kampf um die Führung und keine Stillstände durch fehlende Quoren über weite Distanzen.

3. Standortübergreifende Vernetzung (Cluster Mesh)

Um die Cluster dennoch miteinander kommunizieren zu lassen (z. B. für die Replikation von Datenbanken), nutzt man moderne Netzwerk-Layer wie Cilium Cluster Mesh. Dies ermöglicht eine sichere Kommunikation auf Service-Ebene über Clustergrenzen hinweg, ohne die Schicksale der beiden Cluster untrennbar miteinander zu verknüpfen.

Fazit: Unabhängigkeit ist die wahre Hochverfügbarkeit

Während ein Stretched Cluster für lokale Campus-Netzwerke mit Glasfaser-Direktverbindung funktionieren mag, ist er für echte Georedundanz über weite Strecken oft zu fragil. Die Architektur mit autarken Clustern pro Region bietet die notwendige Stabilität und Vorhersehbarkeit, die KRITIS-Betreiber benötigen. Sie tauscht die Illusion einer “einzigen Wahrheit” gegen die Realität von zwei starken, unabhängigen Säulen.

FAQ

Ist der Verwaltungsaufwand bei zwei Clustern nicht doppelt so hoch? Technisch gesehen ja, aber dieser Aufwand wird durch Automatisierung (GitOps) neutralisiert. Werkzeuge wie ArgoCD stellen sicher, dass Konfigurationen und Applikationen in beiden Clustern identisch ausgerollt werden, ohne dass manuelle Doppelarbeit anfällt.

Wie finden Dienste im Cluster A einen Dienst im Cluster B? Hierfür wird ein globales Service-Discovery-System eingesetzt (z. B. Cilium Cluster Mesh oder externe DNS-Lösungen). Ein Dienst in Region A kann so einen Datenbank-Endpunkt in Region B über einen standardisierten Namen ansprechen, als wäre er lokal vorhanden.

Wann ist ein Stretched Cluster überhaupt sinnvoll? Ein Stretched Cluster eignet sich primär für Szenarien mit sehr geringer Distanz (z. B. zwei Gebäude auf einem Campus), bei denen eine extrem niedrige Latenz (< 1-2ms) und dedizierte Leitungen garantiert sind und die regulatorischen Anforderungen an die Standort-Isolation weniger strikt sind.

Wie wird das Quorum bei zwei autarken Clustern sichergestellt? Da jeder Cluster sein eigenes Quorum (etcd) innerhalb des Standorts verwaltet (idealerweise über drei Availability Zones innerhalb eines Standorts), entfällt die Problematik des standortübergreifenden Quorums vollständig.