Multi-Cluster Kubernetes mit Karmada: Architektur-Guide

TL;DR

• Multi-Cluster wird ab 3+ Clustern fast unvermeidlich -- sei es fuer Ausfallsicherheit, Compliance oder Team-Isolation.
• Karmada ist das derzeit ausgereifteste Open-Source-Tool fuer Kubernetes Federation. Es verteilt Workloads per PropagationPolicy auf Member-Cluster.
• Vermeidet den Fehler, jeden Cluster einzeln zu managen. Zentrales GitOps plus Federation spart langfristig erheblich Aufwand.
• Monitoring und Backup muessen Cluster-uebergreifend gedacht werden. Ein ServiceMonitor pro Cluster reicht nicht.
• Startet mit einem Proof of Concept auf 2-3 Clustern, bevor ihr die gesamte Infrastruktur migriert.

Warum Multi-Cluster?

Die Frage ist nicht ob, sondern wann ihr mehrere Cluster braucht. Typische Treiber:

Ausfallsicherheit. Ein einzelner Cluster ist ein Single Point of Failure. Selbst mit hochverfuegbarem Control Plane koennt ihr einen ganzen Availability-Zone-Ausfall nicht abfangen.

Compliance und Datenlokalitaet. Regulierte Workloads muessen in bestimmten Regionen oder Rechenzentren laufen. DSGVO-relevante Daten duerfen den EU-Raum nicht verlassen.

Team-Isolation. Grosse Organisationen trennen Cluster nach Teams oder Produkten, um Blast Radius zu begrenzen und Upgrade-Zyklen zu entkoppeln.

Hybrid/Multi-Cloud. Ihr wollt Workloads auf AWS, Azure und On-Premise verteilen, ohne an einen Provider gebunden zu sein.

Karmada: Architektur im Ueberblick

Karmada (Kubernetes Armada) ist ein CNCF-Incubating-Projekt fuer Multi-Cluster-Management. Es fuehrt ein eigenes Control Plane ein, das als "Host Cluster" fungiert. Member-Cluster registrieren sich dort und empfangen Workloads ueber PropagationPolicies.

Die Kernkomponenten:

• karmada-apiserver: Nimmt Standard-Kubernetes-Manifeste entgegen
• karmada-controller-manager: Verarbeitet PropagationPolicies und verteilt Workloads
• karmada-scheduler: Entscheidet, auf welchen Clustern Workloads landen
• karmada-agent: Laeuft auf jedem Member-Cluster und synchronisiert Ressourcen

Installation

# Karmada CLI installieren
curl -sL https://raw.githubusercontent.com/karmada-io/karmada/master/hack/install-cli.sh | bash

# Control Plane auf dem Host-Cluster initialisieren
karmadactl init \
  --kubeconfig ~/.kube/config \
  --karmada-apiserver-advertise-address=10.0.1.10 \
  --etcd-storage-mode=PVC \
  --etcd-pvc-size=10Gi

# Member-Cluster registrieren
karmadactl join cluster-fra \
  --cluster-kubeconfig=/path/to/fra-kubeconfig \
  --cluster-context=fra-context

karmadactl join cluster-ber \
  --cluster-kubeconfig=/path/to/ber-kubeconfig \
  --cluster-context=ber-context

# Status pruefen
karmadactl get clusters

Workloads ueber Cluster verteilen

Das Kernkonzept von Karmada sind PropagationPolicies. Ihr deployt ganz normal ein Kubernetes-Manifest gegen den Karmada API-Server, und die PropagationPolicy bestimmt, wohin es geht.

# deployment.yaml - ganz normales Kubernetes-Manifest
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  namespace: production
spec:
  replicas: 6
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
        - name: api
          image: registry.example.com/api:v2.4.1
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 15
---
# propagation-policy.yaml - Karmada-spezifisch
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: api-server-spread
  namespace: production
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: api-server
  placement:
    clusterAffinity:
      clusterNames:
        - cluster-fra
        - cluster-ber
    replicaScheduling:
      replicaDivisionPreference: Weighted
      replicaSchedulingType: Divided
      weightPreference:
        staticWeightList:
          - targetCluster:
              clusterNames:
                - cluster-fra
            weight: 4
          - targetCluster:
              clusterNames:
                - cluster-ber
            weight: 2

In diesem Beispiel bekommt cluster-fra 4 von 6 Replicas und cluster-ber die restlichen 2. Das ist nuetzlich, wenn ein Standort naeher an euren Nutzern liegt oder mehr Kapazitaet hat.

RBAC fuer Multi-Cluster

Ein haeufiger Stolperstein: RBAC muss auf jedem Member-Cluster konsistent sein. Karmada kann ClusterRoles und ClusterRoleBindings propagieren, aber ihr muesst explizit dafuer sorgen.

# rbac-propagation.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: production-deployer
rules:
  - apiGroups: ["apps"]
    resources: ["deployments", "statefulsets"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
  - apiGroups: [""]
    resources: ["services", "configmaps"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
  - apiGroups: ["networking.k8s.io"]
    resources: ["ingresses"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
---
apiVersion: policy.karmada.io/v1alpha1
kind: ClusterPropagationPolicy
metadata:
  name: rbac-propagation
spec:
  resourceSelectors:
    - apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRole
      name: production-deployer
  placement:
    clusterAffinity:
      clusterNames:
        - cluster-fra
        - cluster-ber

Monitoring: Cluster-uebergreifend

Einzelne Prometheus-Instanzen pro Cluster sind okay fuer lokale Metriken. Fuer eine Gesamtansicht braucht ihr eine Aggregation. Bewaehlte Ansaetze:

• Thanos oder Cortex: Langzeit-Storage und Cross-Cluster-Queries
• Victoria Metrics: Performante Alternative zu Thanos
• Grafana mit Multi-Datasource: Ein Dashboard, mehrere Prometheus-Endpunkte

# prometheus-rule.yaml - Alert fuer Cluster-Erreichbarkeit
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: multi-cluster-health
  namespace: monitoring
spec:
  groups:
    - name: cluster-health
      rules:
        - alert: MemberClusterUnreachable
          expr: up{job="karmada-agent"} == 0
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "Cluster {{ $labels.cluster }} ist nicht erreichbar"
            description: "Der Karmada-Agent auf {{ $labels.cluster }} meldet sich seit 5 Minuten nicht."
        - alert: ReplicaImbalance
          expr: |
            abs(
              karmada_propagation_policy_replica_actual - karmada_propagation_policy_replica_desired
            ) > 1
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "Replica-Verteilung weicht ab"
            description: "Die tatsaechliche Replica-Verteilung weicht seit 10 Minuten von der gewuenschten ab."

Backup-Strategie

Velero ist das Standard-Tool fuer Kubernetes-Backups. Bei Multi-Cluster muessen Backups pro Cluster laufen, aber zentral orchestriert werden.

# Velero auf jedem Member-Cluster installieren
for CLUSTER in cluster-fra cluster-ber; do
  kubectl config use-context $CLUSTER

  velero install \
    --provider aws \
    --plugins velero/velero-plugin-for-aws:v1.9.0 \
    --bucket k8s-backup-$CLUSTER \
    --secret-file ./credentials-velero \
    --backup-location-config region=eu-central-1 \
    --snapshot-location-config region=eu-central-1 \
    --use-node-agent

  # Taegliches Backup um 02:00 UTC
  velero schedule create daily-backup \
    --schedule="0 2 * * *" \
    --include-namespaces production,staging \
    --ttl 720h
done

Rollout-Strategie: Schrittweise migrieren

Versucht nicht, alles auf einmal umzustellen. Ein bewaehrter Ablauf:

Phase 1 (2-3 Wochen): Design. Cluster-Topologie festlegen, Netzwerk-Konnektivitaet klaeren, Compliance-Anforderungen dokumentieren.

Phase 2 (2-3 Wochen): Karmada-Setup + erster Member-Cluster. Control Plane aufsetzen, einen bestehenden Cluster als Member registrieren, erste Workloads propagieren.

Phase 3 (2-3 Wochen): Zweiter Cluster + Monitoring. Zweiten Cluster hinzufuegen, Cross-Cluster-Monitoring mit Thanos oder Victoria Metrics aufbauen, Alerting einrichten.

Phase 4 (laufend): Ausrollen und optimieren. Weitere Cluster registrieren, Failover-Tests durchfuehren, Replica-Gewichtung anpassen, Backup-Restores testen.

Typische Fehler

Kein Netzwerk zwischen Clustern geplant. Cluster muessen miteinander kommunizieren koennen -- ob per VPN, Peering oder Service Mesh. Plant das frueh ein.

Secrets nicht synchronisiert. Ein Secret im Karmada API-Server wird nicht automatisch in Member-Cluster propagiert, wenn keine PropagationPolicy existiert. Nutzt External Secrets Operator oder Vault fuer zentrale Secret-Verwaltung.

Upgrades nicht koordiniert. Wenn Cluster auf unterschiedlichen Kubernetes-Versionen laufen, koennen API-Inkompatibilitaeten auftreten. Haltet die Versionsdifferenz auf maximal eine Minor-Version.

Alternativen zu Karmada

Karmada ist nicht die einzige Option. Ein kurzer Vergleich:

Fuer viele Teams ist die Kombination aus Cluster API (Provisionierung) + ArgoCD (Deployment) + Karmada (Federation) der staerkste Stack.

Weitergehende Artikel

• Kubernetes Production Cluster Setup
• Kubernetes Backup und Disaster Recovery
• Kubernetes Monitoring und Observability
• ArgoCD GitOps Tutorial

Ihr plant eine Multi-Cluster-Architektur und braucht Unterstuetzung beim Design oder bei der Umsetzung? Wir begleiten euch vom ersten Architektur-Workshop bis zum produktiven Betrieb. Schreibt uns unter /kontakt.