Kubernetes-Backup: Sicherung von Cloud-nativen Workloads

Als Kubernetes-Backup bezeichnet man die Erfassung und Wiederherstellung von containerisierten Anwendungen, ihres persistenten Zustands sowie der Kubernetes-Konfiguration, die deren Ausführung definiert. Dies erfolgt so, dass sich die gesamte Workload im selben Cluster, in einem anderen Cluster oder in einer anderen Cloud wiederherstellen lässt.

Viele als „Kubernetes-Backup“ vermarktete Backup-Tools umfassen nur einen Teil der Workloads. Doch eine umfassende Kubernetes-Datensicherung muss mehr leisten, wenn Produktionsbereitstellungen sich über Cluster und Clouds erstrecken. Denn dabei gilt es, einige Besonderheiten zu beachten.

Die Unterscheidung zwischen Clustern und Cloud ist wichtig, da die Workload in Kubernetes nicht nur aus den laufenden Containern besteht. Sie umfasst mehrere Komponenten:

• die persistenten Volumes (PVs), in denen zustandsbehaftete Anwendungen Daten speichern,
• den Namespace, in dem sich die Workload befindet,
• die YAML-Manifeste, die Deployments und StatefulSets definieren,
• die ConfigMaps und Secrets, die umgebungsspezifische Konfigurationen enthalten,
• die Custom Resource Definitions (CRDs), die die API erweitern sowie
• den etcd-Zustand, der festhält, was nach Ansicht des Clusters vorhanden sein sollte.

Ein Backup, das nur die persistenten Volumes erfasst, kann zwar die Daten wiederherstellen, nicht jedoch die laufende Anwendung. Ein Backup, das nur die YAML-Manifeste erfasst, kann zwar die Struktur, nicht aber den Zustand wiederherstellen. Beides ist gängige Praxis, und beides ist unzureichend.

Der Einsatz containerisierter Produktions-Workloads ist längst keine Hypothese mehr. Google startet wöchentlich Milliarden von Containern in seiner eigenen Infrastruktur. Für die meisten Plattformteams in Unternehmen stellt sich nicht mehr die Frage, ob Kubernetes-Workloads ein Backup benötigen, sondern wie sie dies richtig gestalten.

Warum Container eine andere Sicherung benötigen als VMs

VMs und Container haben genügend Gemeinsamkeiten, sodass sich einige Sicherungsprinzipien übertragen lassen. Beide sind virtualisierte Abstraktionen. Beide stellen APIs für Snapshot-Operationen bereit. Sicherungsdaten sind unabhängig von ihrer Quelle immer noch Sicherungsdaten. Eine Sicherungsplattform kann Backups für beide sinnvollerweise im selben Speicher aufbewahren.

Das Betriebsmodell unterscheidet sich in drei Punkten, die für die Gestaltung der Datensicherung von Bedeutung sind:

• Der Speicher einer VM bleibt auch nach dem Herunterfahren erhalten. Bei Containerspeicher ist dies oft nicht der Fall. Wenn eine VM heruntergefahren wird, bleibt ihr zugewiesener Speicher erhalten. Wenn ein Kubernetes-Pod heruntergefahren wird, kann das Kubelet seine „emptyDir“-Volumes und jeglichen nicht persistenten Speicher zurückgewinnen.
• VMs sind relativ stabil. Pods sind von ihrer Konzeption her vergänglich. Kubernetes ist darauf ausgelegt, Pods als normales Betriebsmuster zu starten, zu stoppen und neu zu planen. Eine Sicherung, die von langlebigen Workloads mit vorhersehbaren Zeitplänen ausgeht, passt hier nicht.
• VMs führen eine Anwendung aus. Pods führen Teile von Anwendungen aus. Eine sinnvolle Anwendungsgrenze in Kubernetes ist der Namespace oder das Helm-Release, nicht der einzelne Pod. Eine Sicherung auf Pod-Ebene fragmentiert die Anwendung.

Fünf Herausforderungen, die das Kubernetes-Backup architektonisch anders machen

Analysten der Data Center Intelligence Group (DCIG) haben fünf spezifische Herausforderungen identifiziert, die Backup-Software lösen muss, um Kubernetes-Umgebungen zu sichern. Das Framework hat sich bewährt und verdeutlicht, was Kubernetes-native Sicherung von Backup-Tools unterscheidet, die aus der VM-Ära adaptiert wurden.

• Kurzlebiger Speicher: Wenn ein Pod heruntergefahren wird, kann Kubernetes dessen Speicherplatz wieder freigeben. Die Daten gehen damit effektiv verloren. Daraus ergeben sich zwei Konsequenzen für die Datensicherung: Die Plattform muss zunächst erkennen, dass die containerisierte Anwendung überhaupt existiert (automatische Erkennung, keine manuelle Registrierung), und die Datensicherung muss während der Laufzeit der Anwendung erfolgen – was Stunden, nicht Tage dauern kann. Datensicherungspläne, die auf nächtliche Zeitfenster ausgelegt sind, eignen sich nicht für Workloads, die morgen früh möglicherweise nicht mehr existieren.
• Unvorhersehbarkeit: Der Kube-Scheduler entscheidet anhand der Ressourcen-Verfügbarkeit, Affinitätsregeln, Taints und Tolerations, wo Pods ausgeführt werden, nicht anhand von Operator-Präferenzen. Ein Pod kann jederzeit auf jedem Node in jedem Cluster ausgeführt werden. Die Backup-Plattform muss der Workload folgen, anstatt von einem festen Standort auszugehen, und sie muss Sicherungsentscheidungen für jede einzelne Workload treffen. Nicht alle Container benötigen ein Backup. Einige müssen nur bei bestimmten Lebenszyklusereignissen wie vor dem Herunterfahren geschützt werden.
• Skalierbarkeit: Ein Kubernetes-Produktions-Deployment kann Tausende von Pods über Hunderte von Namespaces hinweg ausführen. In Multi-Cluster-Umgebungen sind es sogar Millionen. Container werden viel häufiger gestartet und beendet als VMs. Eine Backup-Plattform, die linear mit dem Aufwand des Betreibers skaliert – manuelle Registrierung, manuelle Zuweisung von Richtlinien, manuelle Überprüfung –, wird zum Engpass. Kubernetes-Backups erfordern eine Cloud-native, dynamisch skalierende Backup-Infrastruktur, die mit der Workload mitwächst und schrumpft.
  Breite – Anwendungen plus Control Plane: Containerisierte Anwendungen sind wichtig, aber ohne den Status der Control Plane, die sie orchestriert, sind sie nutzlos. etcd ist die zentrale Informationsquelle des Clusters. Sie zeigt an, welche Deployments existieren, welche ConfigMaps und Secrets an welche Workloads gebunden sind, welche CRDs die API erweitern und welche RBAC-Regeln den Zugriff regeln. Ausgereifte Kubernetes-Umgebungen skripten die Control Plane über GitOps und können sie bei Bedarf neu aufbauen. Weniger ausgereifte Bereitstellungen sind darauf angewiesen, dass die Backup-Plattform beide Ebenen erfasst.
• Komplexität der Wiederherstellung: Bei der Wiederherstellung treten alle zuvor genannten Herausforderungen auf einmal zutage. Die Plattform muss ermitteln, welches Backup wiederhergestellt werden soll (Datum, Cluster, Namespace, Anwendungskontext) und die Abhängigkeiten zwischen containerisierten Anwendungen berücksichtigen, die möglicherweise gemeinsam gestartet werden müssen. Ebenso muss sie zunehmend die Wiederherstellung in einem anderen Kubernetes-Deployment als demjenigen durchführen, das gesichert wurde. Dies bedeutet, ein anderes Cluster, eine andere Cloud, eine andere K8s-Version und möglicherweise eine andere Distribution (EKS vs. AKS vs. GKE vs. On-Prem). Die Backup-Plattform muss sowohl über die Quelle als auch über das Ziel ausreichend Bescheid wissen, um zwischen beiden zu übersetzen.

Umfang eines vollständigen Kubernetes-Backups

Ein vollständiges Kubernetes-Backup deckt vier verschiedene Kategorien ab. Backup-Tools unterscheiden sich stark darin, wie viele davon sie tatsächlich abdecken.

• Persistente Volumes: Der Anwendungsstatus ist gespeichert in PersistentVolumes, die über PersistentVolumeClaims gebunden sind. Bei zustandsbehafteten Anwendungen (Datenbanken, Nachrichtenwarteschlangen, Dateispeicher) handelt es sich hierbei um die Anwendungsdaten selbst. Die meisten Backup-Tools unterstützen diese Kategorie. Die meisten hören aber hier auf.
• Namespace-Konfiguration: YAML-Manifeste, ConfigMaps, Secrets, Service-Definitionen, Ingress-Regeln, NetworkPolicies und Custom Resources für Operatoren. So wird die Workload für die Ausführung konfiguriert. Geht dies verloren, werden Anwendungsdaten ohne Kontext zu archäologischem Material und lassen sich nicht mehr wiederherstellen.
• Zustand der Steuerungsebene (etcd): Die Wahrheit auf Cluster-Ebene, also welche Workloads existieren, welche RBAC-Regeln gelten für sie, welche CRDs erweitern die API, welche Admission-Webhooks sind registriert? GitOps-Umgebungen können dies möglicherweise aus der Quellcodeverwaltung wiederherstellen. Bei weniger ausgereiften Bereitstellungen muss dies als Teil der Sicherung erfasst werden.
• Containerisierte Anwendungen mit Abhängigkeiten: Die Anwendungsgrenze in Kubernetes ist in der Regel das Helm-Release, der Namespace oder die vom Operator verwaltete Ressourcengruppe, nicht der einzelne Pod. Verteilte Anwendungen mit gemeinsam genutztem Speicher erfordern eine koordinierte Sicherung über mehrere Pods hinweg, um die Transaktionskonsistenz zu gewährleisten.

Die Rolle von Container-Labels und Metadaten

Kubernetes bietet den Schutzmechanismus, den die Plattform benötigt: Labels und Metadaten, die jedem Workload zugeordnet sind. Wenn ein Container gestartet wird, liest der Kubernetes-Node-Service dessen vorhandene Metadaten, fügt Schlüssel-Wert-Paare hinzu, die angeben, welche Ressourcen zusammengehören, und stellt diese Labels allen zur Verfügung, die die API überwachen.

Eine gut konzipierte Backup-Plattform überwacht den Start von Containern und liest die Metadaten in Echtzeit aus. Die Labels teilen der Plattform mit, was gesichert werden soll (die Workload erfüllt die Richtlinienkriterien), wann (gemäß der an diese Labels gebundenen Richtlinie) und wie (welche zugehörigen Ressourcen koordiniert erfasst werden müssen). Die Plattform kann dann Backup-Jobs über die Integration mit dem kube-scheduler planen, sodass Kubernetes selbst entscheidet, wo die Backup-Aufgaben ausgeführt werden – genauso, wie sie entscheidet, wo Pods ausgeführt werden.

Dieses Muster unterscheidet sich von dem operatorgesteuerten Modell, das bei herkömmlichen Backup-Lösungen zum Einsatz kommt. Im herkömmlichen Modell legt ein Mensch oder eine Konfigurationsdatei fest, was gesichert werden soll. Im Kubernetes-nativen Modell deklariert sich die Workload selbst über ihre Labels, und die Backup-Plattform reagiert darauf. Neue Workloads werden automatisch gesichert. Ausgemusterte Workloads verursachen keine Backup-Last mehr. Die Aufgabe des Operators besteht nun darin, Richtlinien festzulegen, nicht mehr darin, den Bestand zu verwalten.

Clusterübergreifende Wiederherstellung und Multi-Cloud-Kubernetes

Die Wiederherstellung innerhalb eines einzelnen Clusters (Wiederherstellung der Workload in demselben Cluster, aus dem sie stammt) ist der einfache Fall. Die meisten Kubernetes-Bereitstellungen in Unternehmen bleiben jedoch nicht lange bei diesem einfachen Fall.

Drei reale Szenarien, die Backup-Plattformen heute bewältigen müssen:

• Workload-Migration zwischen EKS, AKS, GKE und On-Prem-Distributionen: Entscheidungen zum Cluster-Lebenszyklus (Kostenoptimierung, Regionswechsel, Distributionspräferenzen) erfordern regelmäßig die Verlagerung von Workloads. Ein Backup, das die distributionsübergreifende Wiederherstellung unterstützt, verwandelt diese Migrationen von mehrwöchigen Projekten in Routinevorgänge.
• Notfallwiederherstellung in einer anderen Region: Wenn die primäre Region ausfällt, wird die wiederherzustellende Workload in einem Cluster einer anderen Region gestartet. Dies erfolgt im Idealfall mit denselben Backup-Daten, denselben Richtlinien und derselben Managementebene, die das Betriebsteam tagtäglich nutzt.
• Klonen von Test- und Entwicklungsumgebungen: Die Wiederherstellung von Produktions-Workloads (mit synthetischen oder bereinigten Daten) in Test-Clustern ist eine gängige Anforderung für präzise Tests vor der Produktionsfreigabe. Derselbe projekt- und regionenübergreifende Wiederherstellungsmechanismus, der die Notfallwiederherstellung unterstützt, ermöglicht auch das Klonen von Umgebungen.

Häufige Fehler bei Kubernetes-Backups

Der Markt für Kubernetes-Datensicherung ist voll von Produkten, die in einer Funktionsmatrix angemessen erscheinen, aber angesichts der Komplexität der Produktionsumgebung versagen. Es gibt drei Muster, auf die Unternehmen achten sollten:

• Backup ausschließlich für persistente Speicher: Viele „Kubernetes-Backup“-Tools erfassen PV-Snapshots und bezeichnen sich selbst als vollständig. PV-Snapshots sind notwendig, aber nicht ausreichend. Ohne Namespace-Konfiguration, YAML-Manifeste, ConfigMaps, Secrets und vom Operator definierte benutzerdefinierte Ressourcen sind die wiederhergestellten persistenten Volumes nur Daten ohne Kontext. Ein reines Speicher-Backup ist eine nützliche Grundfunktion. Es ist jedoch keine Kubernetes-Backup-Strategie.
• Nachträglich angefügte Plug-ins für veraltete Backup-Produkte: Als bestehende Backup-Anbieter zwischen 2019 und 2021 „Kubernetes-Unterstützung“ hinzufügten, lieferten viele Anbieter Plug-ins aus, die ihre Architektur aus der VM-Ära so anpassten, dass sie Kubernetes-APIs aufrufen konnten. Das Ergebnis behandelt Container in der Regel als separate Workloads, die eine eigene Infrastruktur erfordern, und schafft genau jene isolierte Datensicherung, die durch den Umstieg auf Kubernetes eigentlich beseitigt werden sollte. Wie Krista Macomber von der Evaluator Group in ihrer Einführung zu den Grundlagen der Datensicherung für Container festgestellt hat, führt die Behandlung von Kubernetes als nachträglicher Zusatz selten zu dem Betriebsmodell, das Plattformteams erwarten.
• Die Control Plane wird übersehen: GitOps-Umgebungen, die ihre Control Plane bei Bedarf aus der Quellcodeverwaltung neu aufbauen, können auf eine Sicherung der Control Plane getrost verzichten. Die meisten Kubernetes-Bereitstellungen sind nicht rein GitOps-basiert. Der Cluster enthält angesammelte, manuell angewendete Konfigurationen, über kubectl installierte Operatoren, CRDs, die nicht in der Quellcodeverwaltung erfasst sind, sowie Secrets, die (zu Recht) nie committet wurden. Geht etcd verloren, ist die Historie der im Cluster bereitgestellten Komponenten verloren. Entweder ist die Sicherung der Control Plane Teil der Strategie, oder es besteht eine operative Disziplin rund um GitOps.

Wo Unternehmen anfangen sollten

Wenn Unternehmen heute Kubernetes sichern wollen, sollten sie eine Tabletop-Übung durchführen und ihre kritischste containerisierte Anwendung heranziehen. Sie sollten durchspielen, wie sie diese in einem anderen Cluster in einer anderen Region wiederherstellen würden, wenn der ursprüngliche Cluster nicht mehr verfügbar ist. Wenn jemand im Team während des Durchspielens das Wort „manuell“ verwendet, haben sie ihre Schwachstelle gefunden.

Sebastian Scheele, Kubermatic

Kubermatic