Was ist ein Kubernetes-Backup?
Ein Kubernetes-Backup schützt Anwendungen auf einem Kubernetes-Cluster, indem es zwei Dinge gemeinsam erfasst: die Ressourcendefinitionen, die jede Anwendung beschreiben, und die Daten in ihren Persistent Volumes. Das Ziel ist, eine Anwendung samt Daten auf demselben oder einem anderen Cluster neu erzeugen zu können.
Was enthält ein Kubernetes-Backup?
Eine Anwendung auf Kubernetes besteht aus Objekten in der API des Clusters, etwa Deployments, Services, ConfigMaps und Secrets, sowie aus den Daten in Persistent Volumes. Container-Images werden in der Regel nicht gesichert, weil sie erneut aus einer Registry geladen werden.
| Komponente | Beschreibung | Erfassung |
|---|---|---|
| Ressourcendefinitionen | Objekte, die die Anwendung beschreiben | Export aus der Kubernetes-API |
| Daten in Persistent Volumes | Datenbanken, Queues, hochgeladene Dateien | Exportierter Storage-Snapshot oder Kopie auf Dateiebene |
| Cluster-Zustand (etcd) | Konfiguration des gesamten Clusters | Separater etcd-Snapshot, für den Wiederaufbau des Clusters selbst |
| Container-Images | Anwendungscode | In einer Registry, meist nicht im Backup |
Worin unterscheidet sich das vom Backup virtueller Maschinen?
Das Backup virtueller Maschinen erfasst das Disk-Image einer langlebigen Maschine. Kubernetes-Workloads verteilen sich auf kurzlebige Container, die dort laufen, wo Kapazität frei ist. Es gibt also keine einzelne Disk, die die Anwendung abbildet. Backup-Werkzeuge arbeiten deshalb auf der Ebene der Anwendung oder des Namespace, wählen über Labels aus, was geschützt wird, und rufen Hooks in den Containern auf, um Datenbanken vor einem Snapshot in einen konsistenten Zustand zu bringen. Das ist das Kubernetes-Gegenstück zum anwendungskonsistenten Backup.
Warum landen Kubernetes-Backups auf Objektspeicher?
Nahezu alle Backup-Werkzeuge für Kubernetes schreiben auf S3-kompatiblen Objektspeicher. Er ist von jedem Cluster aus per HTTP erreichbar, skaliert ohne vorab zugewiesene Volumes und liegt außerhalb des Clusters. Das ist entscheidend, denn ein Backup auf dem Cluster, den es schützt, geht mit ihm verloren. Derselbe Speicher kann mehrere Cluster bedienen und wird damit auch zum Transportweg für Anwendungen zwischen Clustern. Unterstützt der Speicher S3 Object Lock, lassen sich die Backups unveränderlich machen.
Was beeinflusst Sizing und Wiederherstellung?
Die Kapazität hängt von den Daten der Persistent Volumes, ihrer Änderungsrate und dem Aufbewahrungsplan ab, nicht von der Zahl der Container. Backups erzeugen außerdem viele kleine Objekte. Der Objektspeicher muss also hohe Objektzahlen und häufige Listings bewältigen. Bei der Wiederherstellung zählen zwei Fragen: Wie lange dauert die Wiederherstellung der größten zustandsbehafteten Anwendung, und wurde eine vollständige Wiederherstellung auf einen neuen, leeren Cluster schon einmal getestet? Der Beitrag Aufbewahrung von Kubernetes-Backups und S3-Sizing rechnet die Zahlen durch.
Häufig gestellte Fragen
Reicht ein etcd-Backup, um Kubernetes-Anwendungen zu schützen?
Nein. Ein etcd-Snapshot stellt die Cluster-Konfiguration wieder her. Die Daten in Persistent Volumes enthält er nicht.
Lohnt sich ein Backup zustandsloser Anwendungen?
Für ihre Definitionen ja, sofern sie sich nicht vollständig aus einem Quell-Repository neu ausrollen lassen. Eigene Daten halten sie nicht.
Lässt sich ein Kubernetes-Backup auf einem anderen Cluster wiederherstellen?
Ja. Das ist ein Hauptzweck, für Migration, Upgrades und Disaster Recovery, sofern Storage-Klassen und Versionen kompatibel sind.