Multi-Cluster Kubernetes: Karmada vs. Cluster API im praktischen Vergleich

TL;DR

• Multi-Cluster ist erst ab 3+ Teams, Compliance-Anforderungen mit Datenlokalitaet oder Geo-Redundanz sinnvoll. Fuer die meisten KMUs reicht ein einzelner Cluster mit Namespaces.
• Karmada orchestriert Workloads ueber mehrere bestehende Cluster hinweg (Scheduling-Ebene). Cluster API provisioniert und verwaltet die Cluster selbst (Infrastruktur-Ebene).
• Beide Tools ergaenzen sich: Cluster API erstellt die Cluster, Karmada verteilt die Workloads.
• Der Ops-Overhead fuer Multi-Cluster ist erheblich. Rechnen Sie mit 0.5-1 FTE zusaetzlich gegenueber einem Single-Cluster-Setup.
• Starten Sie mit zwei Clustern (Prod + Staging) bevor Sie auf drei oder mehr erweitern.

Wann Multi-Cluster wirklich noetig ist

Multi-Cluster Kubernetes klingt nach Enterprise-Architektur und wird oft vorschnell eingefuehrt. Bevor Sie sich die Komplexitaet ans Bein binden, stellen Sie diese Fragen:

Brauchen Sie Geo-Redundanz? Wenn Ihre Anwendung auch bei Ausfall einer gesamten Availability Zone verfuegbar sein muss und der Cloud-Provider keine regionale Redundanz innerhalb eines Clusters bietet -- dann ja.

Haben Sie regulatorische Anforderungen an Datenlokalitaet? Wenn bestimmte Daten in bestimmten Regionen bleiben muessen (z.B. DSGVO, Branchen-Regulierung) und das nicht ueber Namespaces und Node Affinity loesbar ist -- dann ja.

Haben Sie mehrere unabhaengige Teams mit eigenen Release-Zyklen? Wenn Team A am Montag ein Cluster-Upgrade braucht und Team B das blockiert -- dann kann Multi-Cluster die Loesung sein.

Ist Blast-Radius-Isolation kritisch? Wenn ein fehlerhaftes Deployment in Namespace A die Pods in Namespace B beeintraechtigen kann (z.B. durch Node-Ressourcen-Erschoepfung) und das nicht tolerierbar ist -- dann ja.

Wenn keine dieser Fragen mit "ja" beantwortet wird, ist ein einzelner Cluster mit guter Namespace-Isolation und RBAC vermutlich die bessere Wahl. Mehr dazu unter /blog/kubernetes-namespace-management-deutschland.

Karmada vs. Cluster API: Was macht was?

Diese Tools werden oft verwechselt, loesen aber unterschiedliche Probleme.

Kurz gesagt: Cluster API baut die Cluster. Karmada verteilt die Workloads darauf. In einer Multi-Cluster-Architektur koennen Sie beide zusammen einsetzen.

Cluster API: Cluster als Code

Cluster API definiert Kubernetes-Cluster als Custom Resources. Sie beschreiben den gewuenschten Zustand eines Clusters in YAML, und ein Management-Cluster setzt das um.

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: prod-west
  namespace: clusters
spec:
  clusterNetwork:
    pods:
      cidrBlocks: ["192.168.0.0/16"]
    services:
      cidrBlocks: ["10.96.0.0/12"]
  controlPlaneRef:
    apiVersion: controlplane.cluster.x-k8s.io/v1beta1
    kind: KubeadmControlPlane
    name: prod-west-control-plane
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: AzureCluster
    name: prod-west
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AzureMachineTemplate
metadata:
  name: prod-west-worker
  namespace: clusters
spec:
  template:
    spec:
      vmSize: Standard_D4s_v3
      osDisk:
        diskSizeGB: 128
        osType: Linux

Der Management-Cluster ueberwacht diese Definitionen und provisioniert die Worker Nodes automatisch. Aenderungen an der YAML-Datei (z.B. vmSize erhoehen) fuehren zu einem Rolling Update der Nodes.

Der Vorteil: Cluster-Erstellung wird reproduzierbar und versionierbar. Statt ClickOps im Cloud-Portal liegt alles in Git. Das passt perfekt in einen GitOps-Workflow -- mehr dazu unter /blog/gitops-evolution-deutschland.

Karmada: Workloads ueber Cluster verteilen

Karmada sitzt ueber den einzelnen Clustern und verteilt Kubernetes-Ressourcen anhand von Policies. Sie deployen Ihre Anwendung einmal in Karmada, und Karmada sorgt dafuer, dass sie in den richtigen Clustern laeuft.

Die zentrale Abstraktion sind PropagationPolicies:

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: api-service-spread
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: api-service
  placement:
    clusterAffinity:
      clusterNames:
        - prod-west
        - prod-east
    replicaScheduling:
      replicaDivisionPreference: Weighted
      replicaSchedulingType: Divided
      weightPreference:
        staticWeightList:
          - targetCluster:
              clusterNames:
                - prod-west
            weight: 2
          - targetCluster:
              clusterNames:
                - prod-east
            weight: 1

Diese Policy verteilt das Deployment api-service auf zwei Cluster mit einem Verhaeltnis von 2:1. Prod-West bekommt doppelt so viele Replicas wie Prod-East. Bei Ausfall eines Clusters verschiebt Karmada die Replicas automatisch.

Architektur-Patterns fuer Multi-Cluster

Pattern 1: Active-Active mit Geo-Verteilung

Zwei oder mehr Cluster in verschiedenen Regionen bedienen Traffic aktiv. Ein Global Load Balancer (z.B. Cloudflare, AWS Global Accelerator) verteilt Anfragen basierend auf Latenz oder Region.

Vorteile: Niedrige Latenz fuer Endnutzer, volle Redundanz. Nachteile: Daten-Synchronisation zwischen Clustern ist komplex. Stateful Workloads brauchen eine Strategie (z.B. CockroachDB fuer Multi-Region).

Pattern 2: Active-Passive mit Failover

Ein primaerer Cluster bedient allen Traffic. Ein zweiter Cluster steht bereit und uebernimmt bei Ausfall. Karmada erkennt den Ausfall und verschiebt Workloads.

Vorteile: Einfacher als Active-Active. Keine Daten-Synchronisation noetig, wenn der passive Cluster nur Stateless-Workloads uebernimmt. Nachteile: Ressourcen im passiven Cluster sind unterbeschaeftigt. Failover dauert Minuten, nicht Sekunden.

Pattern 3: Umgebungstrennung (Dev/Staging/Prod)

Jede Umgebung laeuft auf einem eigenen Cluster. Das ist das haeufigste Multi-Cluster-Pattern und oft der Einstieg.

Vorteile: Klare Isolation. Ein fehlerhaftes Deployment in Dev kann Prod nicht beeinflussen. Unterschiedliche Cluster-Versionen fuer Upgrade-Tests. Nachteile: Hoeherer Infrastruktur- und Ops-Aufwand als Namespace-basierte Trennung.

Networking zwischen Clustern

Die groesste technische Herausforderung bei Multi-Cluster ist das Networking. Pods in Cluster A muessen Pods in Cluster B erreichen koennen (oder bewusst nicht).

Optionen:

Fuer den Einstieg empfehle ich den API-Gateway-Ansatz: Jeder Cluster exponiert seine Services ueber einen Ingress, und die Services kommunizieren ueber HTTPS. Das ist weniger elegant als Cluster Mesh, aber deutlich einfacher zu debuggen.

Monitoring ueber mehrere Cluster

Ein zentrales Monitoring ist bei Multi-Cluster Pflicht. Ohne eine uebergreifende Sicht verlieren Sie den Ueberblick.

Die gaengigste Loesung: Jeder Cluster betreibt einen lokalen Prometheus, der Metriken sammelt. Ein zentraler Thanos oder Cortex aggregiert die Metriken aller Cluster in einer einzigen Abfrage-Schicht. Grafana verbindet sich mit Thanos und zeigt Dashboards ueber alle Cluster.

Fuer Logs funktioniert dasselbe Pattern: lokaler Promtail/Fluentbit pro Cluster, zentrales Loki oder Elasticsearch fuer die Aggregation.

Wichtig: Labeln Sie Metriken und Logs mit dem Cluster-Namen. Ohne dieses Label koennen Sie bei einem Alert nicht unterscheiden, welcher Cluster betroffen ist. Mehr zum Monitoring-Setup unter /blog/opentelemetry-kubernetes-deutschland.

Kosten und Ops-Overhead

Multi-Cluster kostet mehr als ein einzelner Cluster. Das muss klar sein.

Infrastrukturkosten: Jeder zusaetzliche Cluster braucht eigene Nodes, eigenes Monitoring, eigene Ingress-Infrastruktur. Bei Managed Kubernetes kommt die Control-Plane-Gebuehr hinzu (AKS: kostenlos, EKS: 72 EUR/Monat, GKE: 72 EUR/Monat fuer Standard).

Ops-Overhead: Cluster-Upgrades muessen koordiniert werden. Jeder Cluster braucht eigene Backups. Certificates muessen verwaltet werden. Rechnen Sie mit 0.5-1 FTE zusaetzlich.

Komplexitaet: Debugging wird schwieriger. "Der Service antwortet nicht" kann jetzt bedeuten: falscher Cluster, Netzwerk-Problem zwischen Clustern, oder Karmada-Policy falsch konfiguriert.

Wer die Kosten im Griff behalten will, sollte sich die Kapazitaetsplanung genau ansehen: /blog/kubernetes-capacity-planning-deutschland.

Disaster Recovery mit Multi-Cluster

Ein haeufiger Grund fuer Multi-Cluster ist Disaster Recovery (DR). Dabei geht es nicht nur um Verfuegbarkeit, sondern auch um Recovery Time Objective (RTO) und Recovery Point Objective (RPO).

Fuer die meisten KMUs ist Active-Passive der beste Kompromiss. Velero sichert den Primaer-Cluster regelmaessig. Karmada ueberwacht die Cluster-Health und verschiebt Workloads bei Ausfall auf den Sekundaer-Cluster.

Der kritische Punkt bei DR ist das Testen. Ein DR-Plan, der nie getestet wurde, ist kein Plan. Fuehren Sie mindestens quartalsweise einen DR-Test durch: Simulieren Sie den Ausfall des Primaer-Clusters und messen Sie, wie lange das Failover tatsaechlich dauert.

Fuer Backup-Strategien und Velero-Konfiguration lohnt ein Blick auf /blog/kubernetes-cluster-setup-production.

RBAC und Policy Management ueber Cluster hinweg

Bei mehreren Clustern wird die Zugriffskontrolle schnell unuebersichtlich. Jeder Cluster hat seine eigenen RBAC-Regeln, und ohne Automatisierung divergieren sie.

Zwei Ansaetze:

Karmada OverridePolicies: Karmada kann RBAC-Ressourcen wie ClusterRoles und RoleBindings ueber alle Member-Cluster verteilen. So definieren Sie Zugriffsregeln einmal zentral.

Policy Engines (OPA/Gatekeeper, Kyverno): Erzwingen Regeln wie "Kein Pod darf als root laufen" oder "Jedes Deployment braucht Resource Limits" einheitlich auf allen Clustern. Karmada kann auch diese Policy-Ressourcen propagieren.

Schrittweise Einfuehrung

Phase 1 (Monat 1-2): Zweiten Cluster fuer Staging aufsetzen (per Cluster API oder manuell). GitOps-Workflow so anpassen, dass beide Cluster aus demselben Repository deployt werden. Monitoring zentralisieren.

Phase 2 (Monat 3-4): Karmada im Management-Cluster installieren. Erste nicht-kritische Anwendung ueber Karmada auf beide Cluster verteilen. Failover-Szenarien testen.

Phase 3 (Monat 5-6): Produktive Workloads schrittweise in die Multi-Cluster-Architektur migrieren. Cross-Cluster-Networking aufbauen (Submariner oder API-Gateway). Load-Balancing zwischen Clustern einrichten.

Phase 4 (ab Monat 7): Optimierung. Karmada-Policies feintunen. Kosten analysieren und Cluster-Auslastung optimieren. Runbooks und Troubleshooting-Dokumentation erstellen.

GitOps fuer Multi-Cluster

Die Verwaltung mehrerer Cluster schreit nach Automatisierung. Manuelle kubectl-Befehle gegen 3+ Cluster sind fehleranfaellig und nicht nachvollziehbar.

Der beste Ansatz: Ein zentrales GitOps-Repository mit Kustomize-Overlays pro Cluster. Argo CD (oder Flux) synchronisiert jedes Overlay mit dem jeweiligen Cluster. Aenderungen durchlaufen Pull-Requests mit Review, bevor sie auf irgendeinen Cluster angewendet werden.

gitops-repo/
  clusters/
    prod-west/
      kustomization.yaml   # Overlay fuer Cluster prod-west
    prod-east/
      kustomization.yaml   # Overlay fuer Cluster prod-east
    staging/
      kustomization.yaml
  base/
    namespaces.yaml
    network-policies.yaml
    monitoring/

Jeder Cluster hat eine eigene Argo CD Application, die auf das jeweilige Overlay zeigt. Cluster-spezifische Konfigurationen (z.B. Ingress-Hostnamen, Node-Labels) werden im Overlay definiert. Gemeinsame Ressourcen (NetworkPolicies, Monitoring-Stack) liegen in der Base.

Typische Stolperfallen

Multi-Cluster ohne Grund: Der haeufigste Fehler. Namespace-Isolation mit RBAC und ResourceQuotas loest 80% der Probleme, die Leute mit Multi-Cluster angehen wollen.

Stateful Workloads ueber Cluster verteilen: Datenbanken gehoeren nicht in Karmada-PropagationPolicies. Jeder Cluster sollte seine eigene Datenbank-Instanz haben, synchronisiert ueber Applikations-Logik oder Database-Replikation.

Cluster-Versionen divergieren lassen: Wenn Cluster A auf 1.29 und Cluster B auf 1.27 laeuft, funktionieren Manifeste, die neuere APIs nutzen, nicht ueberall. Halten Sie die Versionen maximal einen Minor-Release auseinander.

Kein zentrales Certificate Management: Jeder Cluster braucht TLS-Zertifikate. Ohne cert-manager mit einem zentralen Issuer wird das Zertifikats-Management zum Albtraum.

Fazit

Multi-Cluster Kubernetes ist ein maeechtiges Werkzeug -- aber eines, das seinen Preis hat. Die Infrastrukturkosten steigen, der Ops-Aufwand waechst, und das Debugging wird komplexer. Bevor Sie diesen Weg gehen, stellen Sie sicher, dass ein einzelner Cluster mit guter Isolation und Monitoring wirklich nicht ausreicht.

Wenn Multi-Cluster die richtige Entscheidung ist, starten Sie mit Cluster API fuer die Infrastruktur und Karmada fuer die Workload-Verteilung. Beide Tools sind ausgereift und ergaenzen sich gut. Beginnen Sie mit zwei Clustern und einem einfachen Pattern (z.B. Umgebungstrennung), bevor Sie Active-Active oder Geo-Verteilung angehen.

Fuer eine Architektur-Bewertung oder Hilfe beim Setup, melden Sie sich unter /kontakt.