Disaster Recovery für Kubernetes-Cluster planen

TL;DR

Eine Kubernetes-DR-Strategie umfasst drei Ebenen: etcd-Snapshots für den Cluster-State, Persistent-Volume-Backups für Anwendungsdaten und GitOps/Helm-Charts für die Anwendungskonfiguration. Definieren Sie RPO und RTO pro Workload, klassifizieren Sie in Bronze/Silver/Gold-Tiers und testen Sie den DR-Fall regelmäßig mit automatisierten CronJobs.

RPO und RTO definieren

Bevor Sie Backup-Tools installieren, brauchen Sie zwei Kennzahlen:

# DR-Anforderungen pro Anwendung definieren
apiVersion: v1
kind: ConfigMap
metadata:
  name: dr-requirements
  namespace: platform
data:
  shop-api: |
    rpo: 5m      # Max. 5 Minuten Datenverlust
    rto: 15m     # Max. 15 Minuten Ausfallzeit
    tier: gold
  internal-wiki: |
    rpo: 24h     # Tägliches Backup reicht
    rto: 4h      # 4 Stunden Wiederherstellung ok
    tier: bronze

RPO (Recovery Point Objective): Wie viel Datenverlust ist akzeptabel? Ein RPO von 5 Minuten bedeutet: Backups alle 5 Minuten.

RTO (Recovery Time Objective): Wie schnell muss der Dienst wieder laufen? Ein RTO von 15 Minuten erfordert automatisiertes Failover.

Die drei Backup-Ebenen

Kubernetes-Disaster-Recovery ist kein einzelnes Backup. Sie brauchen drei Ebenen:

Ebene 1: etcd (Cluster-State). Alle Kubernetes-Objekte leben in etcd. Ohne etcd-Backup verlieren Sie Deployments, Services, ConfigMaps - alles.

Ebene 2: Persistent Volumes. Datenbanken, Uploads, Caches. Diese Daten existieren nur auf den Storage-Backends, nicht in etcd.

Ebene 3: Anwendungskonfiguration. Helm Charts, Kustomize-Overlays, GitOps-Repos. Im Idealfall können Sie den gesamten Cluster aus Git neu aufbauen.

etcd-Snapshot erstellen und wiederherstellen

# etcd-Snapshot erstellen
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-$(date +%Y%m%d-%H%M).db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# Snapshot verifizieren
ETCDCTL_API=3 etcdctl snapshot status /backup/etcd-20260310-1400.db \
  --write-out=table

# Im Notfall: Snapshot wiederherstellen
ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-20260310-1400.db \
  --data-dir=/var/lib/etcd-restored \
  --initial-cluster="master1=https://10.0.1.10:2380" \
  --initial-advertise-peer-urls="https://10.0.1.10:2380" \
  --name=master1

Bei Managed Kubernetes (EKS, AKS, GKE) übernimmt der Anbieter etcd-Backups. Verlassen Sie sich aber nicht blind darauf - nutzen Sie zusätzlich Velero für Namespace-Level-Backups.

DR-Tier-Klassifizierung

Nicht jede Anwendung braucht Gold-Level-DR. Klassifizieren Sie Ihre Workloads:

Bronze genügt für interne Tools und Entwicklungsumgebungen. Silver passt für die meisten Produktions-Workloads. Gold ist für geschäftskritische Systeme mit SLA-Anforderungen reserviert.

Multi-Cluster-Failover

Für Silver- und Gold-Tier brauchen Sie einen zweiten Cluster. Zwei Strategien:

Active-Passive: Ein primärer Cluster verarbeitet Traffic. Der sekundäre Cluster steht bereit und synchronisiert Daten. Bei Ausfall wird DNS umgeschwenkt.

Active-Active: Beide Cluster verarbeiten Traffic gleichzeitig. Ein Global Load Balancer verteilt Anfragen. Komplexer, aber kein Failover-Delay.

Für Active-Passive reicht Velero mit regelmäßigen Restores in den Standby-Cluster. Für Active-Active brauchen Sie Datenbank-Replikation (z.B. CockroachDB, Vitess) und Service-Mesh-Federation.

DR-Tests automatisieren

Ein DR-Plan ohne Tests ist wertlos. Automatisieren Sie DR-Tests als CronJob:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: dr-test-etcd-backup
  namespace: platform
spec:
  schedule: "0 2 * * 0"  # Jeden Sonntag um 02:00
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: dr-tester
          containers:
          - name: dr-test
            image: bitnami/etcd:3.5
            command:
            - /bin/sh
            - -c
            - |
              echo "=== DR-Test gestartet: $(date) ==="

              # 1. Prüfe ob Backup existiert und aktuell ist
              LATEST=$(ls -t /backup/etcd-*.db | head -1)
              AGE=$(( $(date +%s) - $(stat -c %Y "$LATEST") ))
              if [ $AGE -gt 86400 ]; then
                echo "FEHLER: Letztes Backup älter als 24h"
                exit 1
              fi

              # 2. Snapshot-Integrität prüfen
              ETCDCTL_API=3 etcdctl snapshot status "$LATEST" \
                --write-out=json || exit 1

              # 3. Test-Restore in temporäres Verzeichnis
              ETCDCTL_API=3 etcdctl snapshot restore "$LATEST" \
                --data-dir=/tmp/etcd-test-restore || exit 1

              echo "=== DR-Test erfolgreich: $(date) ==="
            volumeMounts:
            - name: backup-volume
              mountPath: /backup
              readOnly: true
          volumes:
          - name: backup-volume
            persistentVolumeClaim:
              claimName: etcd-backup-pvc
          restartPolicy: OnFailure

Diesen CronJob kombinieren Sie mit einem Alert: Wenn der Job fehlschlägt, landet eine Nachricht in Slack oder PagerDuty. So wissen Sie sofort, ob Ihre Backups tatsächlich funktionieren.

Checkliste für den Ernstfall

Wenn der DR-Fall eintritt, zählt jede Minute. Halten Sie ein Runbook bereit:

1. Ausfall bewerten - Ist es ein Node-Ausfall, Zone-Ausfall oder Region-Ausfall?
2. Kommunikation starten - Incident Channel öffnen, Stakeholder informieren
3. Failover einleiten - DNS auf Standby-Cluster umschalten oder neuen Cluster provisionieren
4. Daten wiederherstellen - etcd-Restore oder Velero-Restore je nach Tier
5. Validieren - Smoke Tests ausführen, Monitoring prüfen
6. Postmortem - Was ist passiert? Wie kann man es verhindern?

Drucken Sie dieses Runbook aus. Im DR-Fall ist möglicherweise auch Ihre Wiki-Instanz betroffen.

FAQ

Wie oft sollte ich etcd-Backups erstellen?

Das hängt vom RPO ab. Für Gold-Tier alle 5 Minuten, für Silver stündlich, für Bronze täglich. Bei Managed Kubernetes (EKS, AKS, GKE) erstellt der Anbieter automatisch Backups, aber prüfen Sie die genaue Frequenz.

Reicht Velero als alleinige DR-Lösung?

Velero ist hervorragend für Namespace-Level-Backups und PV-Snapshots. Für eine vollständige DR-Strategie brauchen Sie aber zusätzlich etcd-Backups (bei Self-Managed), GitOps für die Infrastruktur und eine Multi-Cluster-Strategie.

Wie teste ich ein Failover ohne Produktionsausfall?

Nutzen Sie einen dedizierten Test-Cluster und simulieren Sie den Ausfall dort. Alternativ können Sie mit Chaos Engineering Tools wie Litmus oder Chaos Mesh gezielt Nodes oder Zonen im Staging-Cluster abschalten.

Was kostet ein Multi-Cluster-DR-Setup?

Für Active-Passive rechnen Sie mit ca. 30-50% der primären Cluster-Kosten (Standby-Nodes können kleiner sein). Active-Active verdoppelt die Kosten nahezu, bietet aber bessere Performance und kein Failover-Delay.

Wie funktioniert DR mit Managed Kubernetes?

Bei EKS, AKS und GKE managed der Anbieter die Control Plane inklusive etcd-Backups. Sie sind verantwortlich für PV-Backups (Velero, Cloud-native Snapshots), Anwendungskonfiguration (GitOps) und Multi-Region-Failover.