8 Min. Lesezeit

Multi-Cluster-Kubernetes ist in den meisten Plattform-Teams längst Realität, sauber organisiert ist es selten. Drei, vier, manchmal sieben Cluster verteilen sich über Cloud-Regionen, Edge-Standorte und ein dediziertes On-Prem-Stück. Was als Resilienz-Argument anfängt, endet zu oft in einem zweiten Ops-Silo: föderierte Policies hier, händische Drift-Reparatur dort. Die Frage ist nicht, ob Multi-Cluster, sondern wie viel Plattformromantik der Betrieb verträgt.

Das Wichtigste in Kürze

• Multi-Cluster ist Operating-Modell, nicht Tooling-Wahl: Wer Argo CD, Cluster API oder Karmada einführt, ohne vorher Ownership, On-Call und Policy-Quelle zu definieren, baut sich ein zweites Ops-Silo neben dem ersten. Die Reihenfolge entscheidet, nicht der Stack.
• Föderation skaliert, zentrale Control-Planes binden Personal: Karmada und vCluster lösen Drift unterschiedlich. Föderiert verteilt die Komplexität, zentral konzentriert sie. Beide Wege funktionieren, aber nur einer passt zur jeweiligen Team-Größe.
• GitOps ist die einzige skalierbare Policy-Quelle: Sobald drei Cluster überschritten werden, ist jede manuelle kubectl-Aktion ein potenzielles Audit-Finding. Argo CD oder Flux mit App-of-Apps-Pattern macht das Drift-Problem sichtbar, bevor es teuer wird.

VerwandtPlatform Engineering ehrlich  /  Multi-Cloud ohne Umwege

Warum aus einem Cluster drei werden, ohne dass jemand entscheidet

Die Geschichte ist in fast jedem Plattform-Team gleich. Es beginnt mit einem produktiven Cluster pro Umgebung, dazu ein DR-Setup in einer zweiten Region. Dann kommt ein Edge-Standort mit harten Latenz-Anforderungen, ein regulatorisch isoliertes Tenant für den Finanzbereich, ein dedizierter GPU-Pool für die KI-Workloads. Niemand hat Multi-Cluster ausgerufen. Es ist passiert.

Der Bruch entsteht meistens an zwei Stellen: Ingress-Konfiguration und RBAC. Beides ist pro Cluster definiert, beides driftet schneller als gepatcht werden kann. Plattform-Teams berichten in den letzten Quartalen konsistent dasselbe Muster – der Aufwand steigt nicht linear mit der Anzahl der Cluster, sondern eher mit Faktor 1,7 pro zusätzlichem Cluster, weil die Permutationen schneller wachsen als die Workloads.

Hybrid Cloud ist kein Architektur-Muster, sondern die Konsequenz, wenn zwei Teams nicht rechtzeitig miteinander gesprochen haben. Multi-Cluster ist die nächste Stufe davon.

Die Wegmarken: Wie ein typischer Multi-Cluster-Stack entsteht

Wer den Reifegrad der eigenen Multi-Cluster-Reise einschätzen will, kann sich an diesem Zeitstrahl orientieren. Er ist nicht vorgeschrieben, aber er beschreibt den Pfad, den die meisten Plattform-Teams in zwei bis drei Jahren durchlaufen.

Föderation, zentrale Control-Plane oder vCluster: die ehrliche Trade-off-Tabelle

Drei Architektur-Pfade konkurrieren um den Multi-Cluster-Betrieb. Sie schließen sich nicht aus, aber sie skalieren auf unterschiedlichen Dimensionen. Wer den falschen Pfad wählt, baut sich genau jenes Ops-Silo, das er eigentlich verhindern wollte.

Die Tabelle bildet die Realität ab, nicht die Marketing-Versprechen. Karmada ist solide, aber der Operator-Zoo in DACH-Unternehmen ist groß genug, dass die Föderation an einer einzigen unwilligen CRD scheitern kann. OCM und RHACM bringen Vendor-Support mit, was im Audit zählt, im Engineering-Alltag aber auch heißt: man fragt erst Red Hat, bevor man patcht. vCluster ist elegant, aber kein Ersatz für echte Cluster – wer das übersieht, lernt es spätestens beim ersten Persistent-Volume-Problem.

Die drei Zahlen, die ein Plattform-Team kennen muss

Im Multi-Cluster-Betrieb gibt es drei Metriken, ohne die jede Diskussion über Operating Model akademisch bleibt. Sie sind unbequem, weil sie auf den ersten Blick wie Kostentreiber wirken. Tatsächlich sind sie das einzige, was den Betrieb steuerbar macht.

Die Zahlen stammen aus Erfahrungswerten aus Plattform-Teams, nicht aus einer Studie. Wer sie nicht im eigenen Setup misst, hat keine Diskussionsgrundlage gegenüber dem CFO, wenn die Plattform-Investition gerechtfertigt werden muss.

Wer besitzt eigentlich die Plattform, wenn sie verteilt ist

Die organisatorische Frage ist die unbequemste. In einem Cluster-Setup ist der Plattform-Owner offensichtlich, im Multi-Cluster-Setup wird Ownership zur Verhandlungssache. Tenant-Teams wollen lokale Hoheit, das Plattform-Team will zentrale Policies, die Security-Abteilung will einen einzigen Auditing-Punkt. Diese drei Erwartungen sind nicht widersprüchlich, aber sie sind selten ausgesprochen.

Ein belastbares Operating Model braucht drei Festlegungen, bevor irgendein Stack ausgewählt wird. Erstens: Wer entscheidet, welcher Workload in welchen Cluster geht? Zweitens: Wer ist auf welche Cluster pageable, und wer trägt die Konsequenz eines Sev-1? Drittens: Welche Policies sind verhandelbar pro Tenant, welche sind nicht. Diese Fragen lassen sich nicht durch ein Tool beantworten, sondern nur durch eine Entscheidung.

Der Unterschied zwischen einer funktionierenden Multi-Cluster-Plattform und einem zweiten Ops-Silo ist nicht die Wahl zwischen Karmada und OCM. Es ist die Frage, ob diese drei Festlegungen schriftlich existieren und ob das Team sie ein Jahr später noch erkennt.

Was ein realistischer 90-Tage-Pfad aussieht

Plattform-Teams, die heute mit drei oder mehr Clustern leben und das Multi-Cluster-Operating Model konsolidieren wollen, finden in diesen 90 Tagen meistens eine belastbare Antwort. Es geht nicht um den fertigen Stack, sondern um die Entscheidungen, die danach kommen.

Die ersten 30 Tage gehen in eine ehrliche Inventur. Wie viele Cluster existieren wirklich, wer hat zugriffsberechtigte kubeconfigs, wie alt ist der älteste Helm-Release, der seit Monaten unverändert läuft. Diese Inventur fördert mehr zutage als jeder Architektur-Workshop. Die nächsten 30 Tage sind GitOps-Konsolidierung, idealerweise mit Argo CD App-of-Apps oder Flux Kustomization-Bäumen. Wer hier keinen Erfolg hat, sollte über Föderation noch nicht nachdenken. Die letzten 30 Tage gehen in die Operating-Model-Frage: Hub-and-Spoke oder echte Föderation, und vor allem – welches Team wird in zwei Jahren noch da sein, um den Stack zu pflegen.

Das ist kein elegantes Programm. Es ist das, was funktioniert, wenn man eine Multi-Cluster-Plattform nicht als Architekturkunst, sondern als Betriebsverpflichtung versteht.

Häufige Fragen

Ab wann lohnt sich Karmada oder OCM gegenüber einer simplen Argo-CD-Föderation?

In der Praxis ab fünf produktiven Clustern oder spätestens bei harten Multi-Tenant-Anforderungen. Argo CD allein kann Workloads in mehrere Cluster ausrollen, aber bietet keine Workload-Verteilungs-Logik. Karmada erlaubt deklarative Spreading-Policies, OCM bringt Policy-Reporting im Audit-Format mit. Unter fünf Clustern lohnt sich der Operating-Overhead beider Tools selten.

Welche Drift-Quelle ist im Multi-Cluster-Betrieb am häufigsten?

Notfall-Eingriffe per kubectl, die nicht zurückwandern ins Git-Repo. Sobald ein Sev-1 schnell gelöst werden muss, gewinnt der direkte Cluster-Zugriff. Wer diese Fälle nicht systematisch nachträgt, sammelt Drift, der erst beim nächsten Disaster sichtbar wird. Eine Hilfe sind reine Read-Only-kubeconfigs für die meisten Engineers und ein gezieltes Break-Glass-Verfahren für die Sev-1-Fälle.

Sind vCluster ein Ersatz für echte Cluster?

Nein. vCluster geben Tenant-Isolation auf API-Ebene, aber teilen sich Host-Kernel, Networking und Persistent Storage. Für Dev- und Stage-Umgebungen sind sie sehr effizient. Für regulierte Produktion oder echte Multi-Region-Resilienz sind eigene Cluster weiterhin Pflicht.

Wie passen Policy-as-Code-Tools wie OPA Gatekeeper und Kyverno in Multi-Cluster-Setups?

Beide funktionieren pro Cluster, aber das Policy-Bundle muss von einer Quelle deployt werden, sonst entsteht genau jene Inkonsistenz, die der Stack lösen soll. Idealtypisch deployt GitOps die Policy-Manifeste in jeden Cluster, und ein zentrales Reporting-Tool wie Policy-Report-API aggregiert die Verstöße. Wer Policies handgepflegt pro Cluster hält, bekommt das Audit-Problem zurück, das er vermeiden wollte.

Was ist die größte versteckte Kostenfalle bei Multi-Cluster?

Inter-Cluster-Networking und Observability-Egress. Cross-Region-Traffic eines Service-Mesh oder zentraler Loki-Backend kann die Cloud-Rechnung schneller belasten als die Cluster-Footprints selbst. Eine grobe Networking-Analyse vor der Föderationsentscheidung spart später schmerzhafte Re-Architecting-Runden.