Stretched Cluster vs. Multi-Region: Architekturentscheidungen für maximale Resilienz

Wenn Unternehmen entscheiden, ihre Kubernetes-Plattform auf zwei Rechenzentren zu verteilen, stehen sie vor einer Richtungsentscheidung: Baut man einen einzigen, „gestreckten" Cluster (Stretched Cluster), der sich über beide Standorte spannt, oder betreibt man zwei völlig getrennte Cluster (Multi-Region)?

Was auf dem Papier elegant klingt - ein einziger logischer Cluster, in dem man Pods einfach von A nach B schieben kann - erweist sich im KRITIS-Umfeld oft als riskante Fehlentscheidung. Für unser Projekt haben wir uns bewusst für das Multi-Region-Modell entschieden. Hier ist die Begründung für diese architektonische Weichenstellung.

1. Das Problem der „Shared Control Plane"

In einem Stretched Cluster teilen sich beide Standorte eine gemeinsame Steuerungsebene (Control Plane). Die Datenbank des Clusters (etcd) muss Schreibvorgänge über die Standorte hinweg synchronisieren.

• Das Latenz-Dilemma: Jede Millisekunde Verzögerung zwischen den Rechenzentren bremst die Performance des gesamten Clusters. Steigt die Latenz durch eine Netzwerkstörung kurzzeitig an, kann der gesamte Cluster instabil werden.
• Split-Brain-Risiko: Wenn die Verbindung zwischen den Standorten abreißt, versuchen beide Seiten, die Kontrolle zu übernehmen. Ohne eine komplexe „Quorum"-Logik (meist ein dritter Standort als Zeuge) droht Datenkorruption oder ein vollständiger Stillstand.

2. Blast Radius: Wenn ein Fehler alles mitreißt

Der größte Nachteil eines Stretched Clusters ist der Blast Radius (Schadensradius). Ein Fehler in der Konfiguration, ein missglücktes Kubernetes-Upgrade oder ein Bug in einem zentralen Operator betrifft sofort die gesamte Plattform an allen Standorten.

• Multi-Region-Vorteil: Durch getrennte Cluster begrenzen wir Fehler auf eine Region. Wenn Cluster A aufgrund eines Fehlkonfiguration abstürzt, läuft Cluster B völlig unbeeindruckt weiter.
• Wartbarkeit: Wir können Cluster A patchen und upgraden, während Cluster B die volle Last trägt. Besteht ein Problem mit der neuen Version, bemerken wir es in einer Region, ohne den gesamten Betrieb zu gefährden.

3. Netzwerktrennung und Unabhängigkeit

In einer KRITIS-Umgebung ist die Entkopplung von Abhängigkeiten oberstes Gebot.

• Stretched Cluster: Benötigt extrem schnelle, Layer-2-ähnliche Netzwerkverbindungen zwischen den Standorten. Das macht die Infrastruktur teuer und anfällig für großflächige Netzwerkprobleme.
• Multi-Region: Die Cluster kommunizieren über definierte Schnittstellen (z. B. Cilium Cluster Mesh). Sie sind lose gekoppelt. Ein Problem im Netzwerk von Standort A hat keine Auswirkungen auf die interne Kommunikation von Standort B.

Fazit: Resilienz durch bewusste Trennung

Ein Stretched Cluster bietet zwar eine einfache Handhabung (“Single Pane of Glass”), erkauft diese aber mit einer gefährlichen Kopplung der Schicksale beider Standorte. Für KRITIS-Systeme, bei denen ein Ausfall unter allen Umständen vermieden werden muss, ist die Multi-Region-Architektur mit getrennten Clustern die überlegene Wahl. Sie bietet echte Georedundanz, bei der ein Standort ein echter, unabhängiger Rettungsanker für den anderen ist.

FAQ

Ist der Verwaltungsaufwand bei zwei Clustern nicht doppelt so hoch? Technisch gesehen ja, aber durch den Einsatz von GitOps (ArgoCD) automatisieren wir die Verwaltung. Wir definieren die gewünschte Konfiguration einmal im Git, und ArgoCD rollt sie identisch auf beide Cluster aus. Der manuelle Aufwand bleibt also nahezu gleich.

Wie finden Dienste in Cluster A einen Dienst in Cluster B? Hierfür nutzen wir Technologien wie Cilium Cluster Mesh. Es ermöglicht eine sichere „Service Discovery" über Clustergrenzen hinweg. Ein Pod in Frankfurt kann einen Dienst in Berlin über dessen Namen aufrufen, als wäre er lokal vorhanden.

Wann macht ein Stretched Cluster überhaupt Sinn? Stretched Cluster können in Campus-Szenarien sinnvoll sein, wo zwei Gebäude sehr nah beieinander liegen (Latenz < 1ms) und über dedizierte Glasfaser direkt verbunden sind. Für echte Georedundanz über Städte hinweg ist das Modell jedoch ungeeignet.

Was passiert mit den Daten, wenn die Cluster getrennt sind? Die Datenreplikation (z. B. für PostgreSQL) findet auf Applikationsebene statt, nicht auf Dateisystemebene des Clusters. Das ist zwar etwas komplexer einzurichten, aber wesentlich robuster gegenüber Infrastrukturstörungen.

Wie unterstützt ayedo bei der Entscheidung? Wir analysieren Ihre Latenzwerte, Ihre Applikationsarchitektur und Ihre Verfügbarkeitsziele. Wir bauen keine „One-size-fits-all"-Lösung, sondern entwerfen die Multi-Cluster-Strategie, die exakt zu Ihrem Sicherheitsbedarf passt.