Multi-Cloud Kubernetes: Strategie und praktische Umsetzung

TL;DR

Multi-Cloud Kubernetes verteilt Workloads über mehrere Cloud-Provider und reduziert Abhängigkeiten. Die gängigen Use Cases sind Vendor Lock-in Vermeidung, regulatorische Compliance und Disaster Recovery. Tools wie KubeFed und Liqo vereinfachen die Orchestrierung. Der Einstieg gelingt am besten mit einem Multi-Cluster-Kubeconfig und schrittweiser Workload-Verteilung.

Wann Multi-Cloud Kubernetes sinnvoll ist

Nicht jedes Unternehmen braucht Multi-Cloud. Bevor Sie in die Umsetzung einsteigen, sollten Sie prüfen, ob Ihr Szenario tatsächlich davon profitiert.

Multi-Cloud Use Cases (nach Priorität):

1. Compliance & Datenresidenz
   → Bestimmte Daten müssen in bestimmten Regionen bleiben
   → Beispiel: DSGVO verlangt EU-Hosting, Kunde fordert AWS

2. Disaster Recovery
   → Ausfall eines kompletten Providers abfangen
   → RTO < 30 Minuten über Provider-Grenzen hinweg

3. Vendor Lock-in Vermeidung
   → Verhandlungsposition stärken
   → Exit-Option ohne Projekt-Charakter

4. Best-of-Breed Services
   → GPU-Workloads auf GKE, Standard auf Hetzner
   → Spezial-Hardware nur bei einem Provider verfügbar

5. Kostenoptimierung
   → Spot-Instanzen über Provider hinweg nutzen
   → Preisunterschiede je Region ausnutzen

Die meisten deutschen Mittelständler landen bei Punkt 1 oder 3. Aktives Multi-Cloud mit gleichzeitigem Betrieb auf drei Providern ist die Ausnahme -- die Exit-Option ist die Regel.

Multi-Cluster Kubeconfig einrichten

Der erste Schritt ist ein zentrales Kubeconfig, das alle Cluster zusammenführt. Damit können Sie mit einem einzigen kubectl-Befehl zwischen Providern wechseln.

# ~/.kube/config -- Multi-Cloud Kubeconfig
apiVersion: v1
kind: Config
clusters:
  - name: eks-production
    cluster:
      server: https://ABCDEF1234.gr7.eu-central-1.eks.amazonaws.com
      certificate-authority-data: LS0tLS1CRUdJTi...
  - name: aks-staging
    cluster:
      server: https://aks-staging-dns-abc123.hcp.westeurope.azmk8s.io:443
      certificate-authority-data: LS0tLS1CRUdJTi...
  - name: hetzner-dr
    cluster:
      server: https://k8s.hetzner.company.de:6443
      certificate-authority-data: LS0tLS1CRUdJTi...
contexts:
  - name: production
    context:
      cluster: eks-production
      user: eks-admin
      namespace: default
  - name: staging
    context:
      cluster: aks-staging
      user: aks-admin
      namespace: default
  - name: disaster-recovery
    context:
      cluster: hetzner-dr
      user: hetzner-admin
      namespace: default
current-context: production
users:
  - name: eks-admin
    user:
      exec:
        apiVersion: client.authentication.k8s.io/v1beta1
        command: aws
        args: ["eks", "get-token", "--cluster-name", "production"]
  - name: aks-admin
    user:
      exec:
        apiVersion: client.authentication.k8s.io/v1beta1
        command: kubelogin
        args: ["get-token", "--server-id", "6dae42f8-..."]
  - name: hetzner-admin
    user:
      token: "eyJhbGciOiJSUzI1NiIs..."

Cluster wechseln: kubectl config use-context disaster-recovery. Status aller Cluster prüfen:

# Alle Cluster-Kontexte und deren Status abfragen
for ctx in $(kubectl config get-contexts -o name); do
  echo "=== $ctx ==="
  kubectl --context="$ctx" get nodes --no-headers 2>/dev/null | wc -l
  echo "Nodes aktiv"
done

Federation mit KubeFed

KubeFed (Kubernetes Federation v2) verteilt Ressourcen automatisch über mehrere Cluster. Sie definieren eine Ressource einmal, KubeFed sorgt dafür, dass sie in den gewünschten Clustern landet.

# KubeFed: Federated Deployment über 3 Cluster
apiVersion: types.kubefed.io/v1beta1
kind: FederatedDeployment
metadata:
  name: api-service
  namespace: production
spec:
  template:
    metadata:
      labels:
        app: api-service
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: api-service
      template:
        metadata:
          labels:
            app: api-service
        spec:
          containers:
            - name: api
              image: registry.company.de/api:v3.1.0
              ports:
                - containerPort: 8080
              resources:
                requests:
                  cpu: "250m"
                  memory: "512Mi"
  placement:
    clusters:
      - name: eks-production
      - name: aks-staging
      - name: hetzner-dr
  overrides:
    - clusterName: hetzner-dr
      clusterOverrides:
        - path: "/spec/replicas"
          value: 1

KubeFed ist stabil, hat aber Einschränkungen: Es verwaltet nur die Verteilung, nicht das Netzwerk zwischen Clustern. Für Service-Discovery über Cluster-Grenzen brauchen Sie zusätzliche Tools.

Alternative: Liqo für transparentes Multi-Cloud

Liqo geht einen anderen Weg als KubeFed. Statt Ressourcen explizit zu verteilen, erweitert Liqo einen Cluster virtuell um die Kapazität anderer Cluster. Der Scheduler sieht alle Nodes -- auch die entfernten -- und platziert Pods entsprechend.

Für die meisten Mittelstands-Szenarien ist Liqo der pragmatischere Einstieg, weil es weniger Konfiguration erfordert und das Netzwerk automatisch löst.

Netzwerk-Herausforderungen lösen

Das größte Problem bei Multi-Cloud Kubernetes ist das Netzwerk. Pods in Cluster A müssen Pods in Cluster B erreichen -- über Provider-Grenzen und Firewalls hinweg.

Die drei Netzwerk-Ebenen

Service Mesh (Istio Multi-Cluster): Istio verbindet Services über Cluster-Grenzen. Die Control Plane läuft in einem Primary-Cluster, Remote-Cluster verbinden sich darüber. Vorteil: mTLS zwischen allen Services, egal wo sie laufen. Nachteil: Istio-Komplexität.

VPN-Tunnel (WireGuard): Der einfachste Ansatz. WireGuard-Tunnel zwischen den Cluster-Nodes, darüber normales Pod-Netzwerk. Latenz ist höher (10-30ms je nach Distanz), aber für viele Workloads ausreichend.

Submariner: CNCF-Projekt speziell für Multi-Cluster-Netzwerk. Erstellt verschlüsselte Tunnel zwischen Clustern und ermöglicht Cross-Cluster-Service-Discovery.

# Submariner: Cross-Cluster Service Export
apiVersion: multicluster.x-k8s.io/v1alpha1
kind: ServiceExport
metadata:
  name: api-service
  namespace: production
---
# Im anderen Cluster: Service Import
apiVersion: multicluster.x-k8s.io/v1alpha1
kind: ServiceImport
metadata:
  name: api-service
  namespace: production
spec:
  type: ClusterSetIP
  ports:
    - port: 80
      protocol: TCP

Workload Placement Strategie

Nicht jeder Workload gehört in jede Cloud. Eine sinnvolle Verteilung berücksichtigt Latenz, Kosten, Compliance und Verfügbarkeit.

Eine Faustregel: Stateless Workloads lassen sich einfach verteilen. Stateful Workloads (Datenbanken, Message Queues) sollten möglichst in einem Cluster bleiben und per Replikation synchronisiert werden.

Monitoring über Cluster-Grenzen

Ein zentrales Monitoring ist Pflicht. Ohne Überblick über alle Cluster verlieren Sie die Kontrolle.

# Thanos Sidecar für Multi-Cluster Prometheus
apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus
  namespace: monitoring
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      containers:
        - name: prometheus
          image: prom/prometheus:v2.51.0
          args:
            - "--storage.tsdb.min-block-duration=2h"
            - "--storage.tsdb.max-block-duration=2h"
          ports:
            - containerPort: 9090
        - name: thanos-sidecar
          image: thanosio/thanos:v0.34.0
          args:
            - "sidecar"
            - "--tsdb.path=/prometheus"
            - "--objstore.config-file=/etc/thanos/objstore.yml"
          ports:
            - containerPort: 10901
              name: grpc

Thanos aggregiert Prometheus-Daten aus allen Clustern in einem zentralen Object Store. Ein Thanos Query Frontend fragt alle Cluster gleichzeitig ab -- Sie sehen alle Metriken in einem Grafana Dashboard.

FAQ

Ist Multi-Cloud Kubernetes teurer als Single-Cloud?

Ja, typischerweise 20-40% höhere Betriebskosten durch doppelte Infrastruktur, Netzwerk-Traffic zwischen Providern und erhöhte Komplexität. Der Mehrwert liegt in Risikoreduktion und Verhandlungsposition.

Kann ich mit Multi-Cloud starten und später vereinfachen?

Ja. Beginnen Sie mit einem Multi-Cluster-Kubeconfig und Kustomize Overlays. Das ist keine Multi-Cloud im engeren Sinn, gibt Ihnen aber die Exit-Option ohne den vollen Betriebsaufwand.

Welche Latenz entsteht zwischen Clustern verschiedener Provider?

Zwischen AWS eu-central-1 und Azure West Europe typischerweise 5-15ms. Zwischen EU und US 80-120ms. Für synchrone API-Calls problematisch, für asynchrone Verarbeitung akzeptabel.

Brauche ich ein Service Mesh für Multi-Cloud?

Nicht zwingend. Für einfache Szenarien reichen VPN-Tunnel und DNS-basiertes Routing. Ein Service Mesh lohnt sich ab 20+ Services mit Cross-Cluster-Kommunikation.

Wie handle ich Datenbank-Replikation über Provider-Grenzen?

PostgreSQL Streaming Replication oder CockroachDB für Multi-Region. Vermeiden Sie synchrone Replikation über Provider-Grenzen -- die Latenz ist zu hoch. Asynchrone Replikation mit akzeptablem RPO ist der pragmatische Weg.

Fazit

Multi-Cloud Kubernetes ist kein Selbstzweck. Es löst konkrete Probleme: Vendor Lock-in, Compliance-Anforderungen und Disaster Recovery. Der Einstieg muss nicht komplex sein -- ein Multi-Cluster-Kubeconfig mit Kustomize Overlays reicht für die Exit-Option. Wer aktiv Multi-Cloud betreiben will, sollte Liqo oder Submariner evaluieren und das Netzwerk-Thema früh adressieren.

Die drei Grundregeln: Stateless Workloads verteilen, Stateful Workloads replizieren, Monitoring zentralisieren.