Kubernetes Multi-Cluster: Hybrid ohne Drift 2026

Constantin, Kubernetes-Betrieb bei Pexon Consulting | 11 Min. Lesezeit | 11.09.2026

TL;DR: Kubernetes Multi-Cluster in fünf Sätzen

Kubernetes Multi-Cluster heißt: local, Test, Staging, Produktion und ein aks-pilot sind eigene Control Planes, nicht fünf Namespaces. Pexon Consulting (80 Mitarbeitende, Deutschland, Microsoft Partner) schneidet Isolation zuerst, Tooling danach. Rancher 2.15.1 (28.08.2026) hält die Flotte. Wer alles in einen Cluster stopft, kauft sich Blast Radius, nicht Einfachheit.

Das Problem: fünf Umgebungen, fünf kubeconfigs, eine Ausrede

Ein Team hat local auf dem Laptop, Test im Keller, Staging „fast wie Prod“, Produktion mit drei Knoten und daneben einen aks-pilot, weil irgendwer Azure anfassen wollte. Jede Umgebung hat ihre eigene Wahrheit. NetworkPolicy hier, keine dort. Storage-Class mit lokalem Pfad in Test, in Prod derselbe Name und ein anderes Gerät.

Das ist kein Multi-Cluster. Das ist fünf Einzelentscheidungen, die sich zufällig Kubernetes nennen.

Wir sehen das Muster in kleinen On-Prem-Setups mit wenigen Knoten. Rancher hängt schon dran. ArgoCD deployt „irgendwie“. Cilium ist in einem Cluster gesetzt, in einem anderen noch das Default-CNI. Dann kommt die Frage: Warum verhält sich Staging anders als Prod? Die ehrliche Antwort: weil niemand die Architektur entschieden hat. Nur die Tools.

Pexon Consulting baut das nicht als Folien-Landschaft. Wir ziehen zuerst den Schnitt: welche Workloads dürfen welchen Cluster sehen, wer darf upgraden, was ist bewusst unterschiedlich. Erst danach kommt die Management-Ebene.

Warum Kubernetes Multi-Cluster kein Namespace-Trick ist

Die kurze Antwort: Namespaces teilen etcd, CNI, Storage-Treiber und das Upgrade-Fenster. Isolation auf Papier, gemeinsames Schicksal in der API.

Ein Namespace staging neben prod fühlt sich ordentlich an. Ein CRD-Upgrade trifft dann beide. Eine StorageClass füllt den Node, auf dem zufällig auch der Postgres-Pod aus Prod liegt. Tab-Complete plus kubectl delete ns macht den Rest.

Deshalb raten wir bei mehr als einer echten Umgebung von dem einen fetten Cluster ab. Nicht weil Kubernetes das nicht kann. Weil der Mittelstand den Ausfall nicht als Lernprojekt verbuchen will.

Vier Gründe, die in der Praxis tragen, und einer, der oft vorgeschoben wird:

Verfügbarkeit. Ein Control-Plane-Ausfall darf Test treffen, nicht Rechnungslauf.

Isolation. Entwickler-Rechte in local bleiben lokal. Prod bekommt ein eigenes RBAC, kein „fast dasselbe Manifest“.

Compliance. Getrennte Cluster sind erklärbar. Ein Cluster mit 40 Namespaces und einer Story ist es selten.

Hybrid. aks-pilot ist kein Label auf einem On-Prem-Node. Es ist ein anderer Betreiber, ein anderes Identitätsmodell, oft eine andere CNI-Default.

Der vorgeschobene Grund ist Skalierbarkeit. Fünf Knoten werden nicht zu fünfzig, nur weil ihr sie aufteilt. Wer wachsen will, plant Nodes. Wer überleben will, plant Blast Radius.

Mehr zur reinen Distributionsfrage steht im k3s-, k8s- und Rancher-Vergleich. Hier geht es um den Betrieb der Flotte, nicht um die Wahl der Distro.

So schneiden wir local, Test, Staging, Prod und aks-pilot

Unsere klare Empfehlung: fünf Cluster, eine Regel pro Zweck, keine Ausnahmen „nur diesmal“.

local. Laptop oder eine Mini-Instanz. Darf kaputtgehen. Keine echten Secrets, keine Kundendaten. Gleicher Manifest-Schnitt wie Prod, kleinere Replicas.

test. Geteilte Integrationsumgebung. Hier dürfen Queues und eine kleine Datenbank leben. Hier darf jemand resetten.

staging. Prod-ähnlich in CNI, Storage-Klasse-Namen und Identity-Flow. Nicht prod-ähnlich in Datenmenge. Wer Staging mit Prod-Dumps ohne Maskierung füllt, hat kein Staging. Der hat eine zweite Produktion ohne Zuschauer.

prod. Wenige Knoten, eigene etcd, eigene Backup-Annahme, eigene Zulassungsliste wer cluster-admin ist. Infra-Services (Postgres, RabbitMQ, Valkey, Elasticsearch) nur hier in der scharfen Variante, wenn ihr sie wirklich im Cluster wollt.

aks-pilot. Ein Azure-Cluster mit eigenem Zweck. Proof, dass Workloads den Schnitt überstehen. Kein stilles Production-Overflow, sobald On-Prem eng wird. Wer den Pilot als Overflow benutzt, hat den Hybrid verloren und eine Rechnung gewonnen.

# Orientierung, keine Copy-Paste-Religion. Labels steuern Zielcluster, nicht Hoffnungen.
apiVersion: management.cattle.io/v3
kind: Cluster
metadata:
  name: staging
  labels:
    env: staging
    region: on-prem
    purpose: preprod
# aks-pilot bekommt env=pilot, region=azure. Derselbe Git-Stand, andere values.

Rancher importiert bestehende Cluster oder provisioniert neue. Für fünf Umgebungen reicht Import plus klare Labels. Wer jeden Cluster von Rancher neu bauen lässt, obwohl drei schon Jahre laufen, verschiebt das Risiko in ein Wochenend-Projekt.

GitOps bleibt die Soll-Quelle für Apps. Das haben wir für Azure schon als ArgoCD auf AKS beschrieben. Hier nicht noch einmal „was ist ArgoCD“. Hier zählt: ein Repo, overlays pro env, kein Copy-Paste der Prod-values nach Staging um 17:40.

Rancher als Ebene, nicht als zweite Religion

Rancher 2.15.1 ist am 28.08.2026 erschienen. Das Repo rancher/rancher stand am 11.09.2026 bei 25.810 GitHub-Stars. Stars kaufen keinen Betrieb. Das Patch behebt unter anderem CVE-2026-75034 (SAML-Replay über Replicas) und CVE-2026-75033 (Project-Secrets über Clustergrenzen). Wer Multi-Cluster mit einer zentralen Anmeldung fährt und auf 2.14 stehen bleibt, diskutiert Architektur, während die Auth-Ebene das eigentlich relevante Loch ist.

RKE1 ist seit 31.07.2025 tot. Rancher 2.12 und neuer provisionieren es nicht mehr. Wenn in eurer Flotte noch ein RKE1-Downstream hängt, ist das kein Nostalgie-Cluster. Das ist eine Upgrade-Sperre.

Was Rancher gut kann, in einem Satz: eine Fläche für Zugang, Katalog und Cluster-Lebenszyklus über On-Prem und AKS.

Was Rancher nicht ersetzt: euer Schnitt. Ein schlecht geschnittener aks-pilot wird durch eine hübsche UI nicht besser. Fleet hilft, wenn ihr Dutzende Cluster gleich behandeln wollt. Bei fünf Umgebungen mit Absicht unterschiedlichen Regeln ist Fleet oft zu grob. Dann bleiben Labels, Rancher-Projekte und ein Git-Overlay.

Wir raten aktuell davon ab, Rancher auf denselben drei Prod-Knoten zu installieren, die auch die Fachservices tragen. Die Management-Ebene muss überleben, wenn Prod hustet. Ein eigenes kleines Management-Cluster, notfalls zwei Nodes plus etcd-Backup, ist langweilig und richtig.

Ownership ist der Teil, den Tools nicht lösen. Wer zahlt aks-pilot, wenn der Proof drei Monate alt ist? Wer darf Nodes in Prod erweitern, ohne Test mitzunehmen? In unseren Projekten schreiben wir das auf eine halbe Seite, nicht in ein Confluence-Roman. Name, Vertretung, Zeitfenster. Fehlt der Name, fehlt der Betrieb. Dann bleibt Rancher eine hübsche Fläche über einer Flotte, die nach Feierabend niemandem gehört.

Monitoring über die Flotte, nicht fünf Grafana-Inseln

Fünf Cluster ohne gemeinsame Sicht sind fünf On-Calls ohne gemeinsame Sprache. Prometheus bleibt pro Cluster. Die Frage ist, wohin die Daten und die Alerts laufen.

Wir sehen drei ehrliche Stufen, nicht fünf Tools:

1. Jeder Cluster hat kube-prometheus-stack. Alerts gehen in dieselbe Senke (Mail, Ticket, On-Call).
2. Ein zentrales Grafana liest die Prometheus-Instanzen oder ein Thanos/Mimir davor.
3. Rancher Monitoring zusätzlich, wenn die Fläche schon da ist. Nicht statt 1.

Stufe 3 ohne Stufe 1 ist Theater. Die UI zeigt grün, der Alertmanager im Cluster schweigt, weil niemand den Receiver gesetzt hat.

Den Werkzeugstreit Grafana gegen Prometheus haben wir schon entschieden: beide, nicht versus. Hier zählt nur die Flottenregel. Ein Dashboard namens prod und eines namens staging, gleiche Panels, gleiche Schwellwerte. Sonst vergleicht ihr Äpfel mit dem Laptop vom Praktikanten.

On-Prem mit local-path-Storage macht das Monitoring ehrlicher: Disk full auf dem Node ist ein Cluster-Event, kein Volume-Event in der Cloud. Wer das nicht alarmiert, merkt den Postgres-Stopp an der Fachanwendung.

Worauf Sie bei Hybrid On-Prem plus AKS achten

Fünf Punkte, mehr nicht. Der Rest ist Geschmack.

1. Gleicher Schnitt, andere Werte. Image, Probe, Resource-Requests bleiben. StorageClass-Name darf gleich heißen, die Implementation nicht. local-path in Test, ein echter Provisioner in Prod, Azure Disk im Pilot.
2. Identität nicht mischen. On-Prem-LDAP und Entra im aks-pilot brauchen eine bewusste Brücke. Zwei Admin-Listen sind besser als eine, die niemand mehr erklärt.
3. Netzwerk nicht romantisch. Cluster Mesh und Service-Mesh über On-Prem und AKS klingen nach einer Plattform. In einem Fünf-Knoten-Keller sind sie oft die teuerste Kopplung, die ihr kaufen könnt. Wir koppeln über Git und über Ingress, nicht über eine gemeinsame Pod-CIDR, solange niemand einen harten Grund hat.
4. Upgrade-Kalender. Ein Cluster pro Fenster. Staging zuerst, Prod nach der Lüge „bei uns war nichts“. aks-pilot folgt dem AKS-Support-Fenster, nicht eurem Keller-Rhythmus. Wer alle fünf am selben Donnerstag hebt, hat einen Plan und fünf Rollbacks.
5. Daten bleiben wo sie sind. Der Pilot kopiert keine Prod-Datenbank „zum Testen in Azure“, ohne dass Datenschutz das gesehen hat. Hybrid heißt Rechenort plus Regel, nicht USB-Stick in die Cloud.

Wer On-Prem und DSGVO schon als eigene Frage hat, liegt näher an einem Souveränitäts-Text als an einer AKS-Verkaufsfolie. Die Flotte selbst bleibt Betriebsfrage, nicht Beratungs-Hub.

Ein Wort zu Komponenten, die Teams gern in jeden Cluster kopieren: Ingress, cert-manager, ein Logging-Agent, der Prometheus-Stack. Das ist die Plattform-Baseline. Sie gehört ins Git, nicht in fünf Handinstallationen. Was nicht zur Baseline gehört: der Fach-Postgres in local. Der Fach-Elasticsearch in Test „weil die Suche sonst fehlt“. Jede Extra-Stateful-Komponente in einer Umgebung, die resetbar sein soll, macht den Reset teurer als den Nutzen.

Pexon Consulting (Microsoft Partner, 30 Azure-Spezialisten, Sitz in Deutschland) sieht denselben Ablauf: erst die fünf Namen an die Wand, dann die Baseline, dann erst die Fachservices. Wer mit den Fachservices anfängt, bekommt fünf Schneebälle.

Häufig gestellte Fragen

Was kostet ein Kubernetes Multi-Cluster Setup mit fünf Umgebungen?

Die Software ist oft Open Source. Der Preis sitzt in Zeit: Schnitt, Baseline, Identity, Monitoring, das erste ehrliche Restore. Wir rechnen das nicht als Listenpreis in den Artikel. Der Einstieg ist ein Betriebsgespräch in 45 Minuten. Rancher-Subscription ist optional, kein Muss für fünf Cluster.

Kubernetes Multi-Cluster oder ein Cluster mit vielen Namespaces?

Kommt darauf an, was ausfallen darf. Namespaces reichen für Teams in derselben Vertrauenszone. Eigene Cluster, sobald Staging Prod nicht mitreißen darf oder Azure daneben steht. Unsere Empfehlung für local/test/staging/prod plus aks-pilot: fünf Cluster, keine Diskussion über „Namespace reicht schon“.

Brauchen wir Rancher, oder reicht kubectl plus Git?

kubectl plus Git reicht technisch. Es reicht menschlich selten, sobald mehr als zwei Personen die kubeconfigs teilen. Rancher lohnt als Fläche für Zugang und Lebenszyklus. Es lohnt nicht als Ersatz für den Schnitt.

Wie hängt ArgoCD in so einer Flotte?

Als Deploy-Pfad, nicht als Cluster-Manager. Ein Hub kann mehrere Ziele bedienen. Die Werte pro Umgebung liegen im Overlay. Die Einführung selbst ist der AKS-GitOps-Text, nicht dieser.

Für wen lohnt Kubernetes Multi-Cluster nicht?

Für ein einziges Dev-Cluster ohne Prod-Anspruch. Für Teams, die noch keinen Staging-Begriff haben. Für Häuser, die fünf Cluster wollen, aber niemanden für Upgrades. Dann ist ein gemanagter Betrieb ehrlicher als eine selbst gebaute Flotte, die nur am Dienstag existiert.

Nächster Schritt

Verwandte Themen