So behalten Sie einen kühlen Kopf, wenn Ihr Kubernetes-Cluster abstürzt, oder warum Sie Velero brauchen

Stellen Sie sich folgendes Szenario vor: Es ist Freitagabend, Sie planen sich zu entspannen, als plötzlich eine Slack-Benachrichtigung erscheint — einer Ihrer Produktions-Kubernetes-Cluster ist abgestürzt. Eine Fehlkonfiguration, ein Cloud-Provider-Ausfall oder einfach menschliches Versagen — die Ursache spielt keine Rolle mehr. Entscheidend ist, wie schnell Sie alles wieder zum Laufen bringen können. Wenn Sie nur YAML-Dateien in Git haben, haben Sie Schwierigkeiten, zustandsbehaftete Anwendungen und ihre Daten wiederherzustellen.

Hier kommt Velero ins Spiel. Es ist ein Projekt von VMware (ursprünglich von Heptio erstellt), das zum De-facto-Standard für Backups in der K8s-Welt geworden ist.

Was es ist und warum GitOps allein nicht ausreicht

Viele Entwickler glauben, dass Backups überflüssig sind, wenn ihre gesamte Infrastruktur als Code (IaC) definiert und über ArgoCD oder Flux bereitgestellt wird. Das ist eine gefährliche Fehlannahme. Git speichert Manifeste, weiß aber nichts über den Zustand Ihrer Persistent Volumes (PV), dynamisch ausgestellte Zertifikate oder Secrets, die nie ins Repository gelangt sind.

Velero macht zwei Dinge: Es speichert Kubernetes-API-Objekte (Deployments, ConfigMaps, Secrets) und erstellt Datenträger-Snapshots mit Daten. Es funktioniert in Public Clouds (AWS, GCP, Azure) ebenso wie in On-Premises-Rechenzentren auf Bare-Metal.

Drei Szenarien, in denen Velero rettet

Ich sehe Velero oft nicht nur für Katastrophenschutz eingesetzt. Hier sind die wichtigsten Anwendungsfälle:

1. Klassische Disaster Recovery. Das ist straightforward: Der Cluster ist tot, Sie starten einen neuen und stellen alles mit einem einzigen Befehl aus dem S3-Speicher wieder her.
2. Cross-Cloud-Migration. Der Umzug von AWS zu Google Cloud oder von einer Region in eine andere wird zur trivialen Aufgabe. Velero packt die Ressourcen und deployt sie am neuen Ort.
3. Umgebungsklonen. Sie brauchen schnell eine exakte Kopie der Produktion zum Testen? Sie erstellen ein Prod-Backup und stellen es im Namespace staging wieder her. Die Datenbankdaten sind aktuell, nicht von einem Monat alten Dump.

So funktioniert es unter der Haube

Die Projektarchitektur ist ziemlich transparent. Es gibt eine Server-Komponente, die innerhalb des Clusters als Operator läuft, und einen CLI-Client für die Verwaltung des Prozesses.

Wenn Sie ein Backup auslösen, passiert Folgendes:

1. Der Client sendet eine Anfrage an die Velero-API.
2. Der Backup-Controller findet alle Objekte, die Sie angegeben haben (Sie können nach Labels oder Namespaces filtern).
3. Velero macht Anfragen an die Kubernetes-API, um JSON-Beschreibungen der Ressourcen zu sammeln.
4. Parallel dazu werden Plugins für die Datenträgerverwaltung aufgerufen (z.B. EBS in AWS oder CSI-Treiber), um Datensnapshots zu erstellen.
5. All das wird archiviert und an den Objektspeicher (S3-kompatibel) gesendet.

Übrigens unterstützt Velero Restic und Kopia. Das bedeutet, Sie können inkrementelle Dateisystem-Backups durchführen, selbst wenn Cloud-Snapshots nicht verfügbar sind.

Praktisches Beispiel

Sagen wir, wir müssen eine gesamte Anwendung im Namespace app-production sichern. Der Terminalbefehl würde ungefähr so aussehen:

velero backup create production-backup --include-namespaces app-production

Und wenn jemand diesen Namespace eine Woche später versehentlich löscht, dauert die Wiederherstellung nur wenige Minuten:

velero restore create --from-backup production-backup

Interessanterweise kann Velero Ressourcenparameter during der Wiederherstellung im laufenden Betrieb ändern. Sie können beispielsweise die StorageClass für Datenträger ändern, wenn die alte Klasse im neuen Cluster nicht verfügbar ist.

Kompatibilitätsnuancen

Die Entwickler von Velero pflegen eine ziemlich strenge Kompatibilitätsmatrix. Derzeit wird Version 1.18 gegen die neuesten Kubernetes-Releases (bis 1.35) getestet. Das ist wichtig, weil sich die Kubernetes-API schnell ändert und ältere Tools oft nach einem Cluster-Upgrade nicht mehr funktionieren.

Das Projekt steht unter dem Dach der Cloud Native Computing Foundation (CNCF), was gewisse Garantien bietet: Es wird nicht morgen verschwinden, und seine Sicherheit wird überwacht.

Lohnt sich die Implementierung

Wenn Sie Kubernetes in der Produktion betreiben und Daten auf Datenträgern haben (Datenbanken, Queues, Config Stores), ist Velero ein Must-have.

Wer wird definitiv davon profitieren:

• SRE-Engineers, die nachts ruhig schlafen müssen.
• Teams, die häufig zwischen Clustern migrieren.
• Entwickler, die frische Produktionsdaten zum Debuggen komplexer Bugs brauchen.

Beginnen Sie mit der offiziellen Dokumentation unter velero.io. Sie ist ziemlich detailliert, kann aber manchmal überwältigend wirken. Die wichtigste Erkenntnis ist, dass ein Backup nur existiert, wenn Sie es mindestens einmal erfolgreich daraus wiederhergestellt haben. Versuchen Sie dies in einem Test-Cluster, bevor Sie dem Tool echte Daten anvertrauen.