Kubernetes-Backup: Schutz cloud-nativer Workloads

Der Kunde, der jeden Knoten gesichert hatte

Als ich zum ersten Mal beobachtete, wie ein Kunde versuchte, einen Kubernetes-Cluster aus seinem VM-Backup wiederherzustellen, wusste ich, dass es in den Gesprächen des kommenden Jahres darum gehen würde, zu erklären, warum Container nicht so funktionieren wie VMs. Wir mussten Schritt für Schritt durchgehen, was das Backup tatsächlich enthielt, was fehlte und was dies für deren RTO bedeutete.

Der Kunde glaubte, abgesichert zu sein. Er verfügte über Backups aller Knoten im Cluster. Er hatte jedoch keine Möglichkeit, die Workload wiederherzustellen. Das Backup erfasste die zugrunde liegenden VMs, auf denen Kubernetes lief. Es erfasste jedoch nicht die Namespace-Konfiguration, die YAML-Manifeste, die ConfigMaps und Secrets sowie den etcd-Zustand, der festhielt, was vorhanden sein sollte. Sie verfügten über die Basis. Ihnen fehlte die Anwendung. 

Dies ist das, was ich diesem Team sagen würde, wenn ich die Zeit zurückdrehen und das Gespräch vor dem Vorfall führen könnte.

Was ein Kubernetes-Backup tatsächlich ist

Ein Kubernetes-Backup ist die Erfassung und Wiederherstellung von containerisierten Anwendungen, ihres persistenten Zustands sowie der Kubernetes-Konfiguration, die festlegt, wie diese ausgeführt werden – und zwar so, dass die gesamte Workload im selben Cluster, in einem anderen Cluster oder in einer anderen Cloud wiederhergestellt werden kann.

Diese Unterscheidung ist wichtig, da die Workload in Kubernetes nicht nur aus den laufenden Containern besteht. Sie umfasst 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, jedoch nicht die laufende Anwendung. Ein Backup, das nur die YAML-Manifeste erfasst, kann zwar die Struktur, jedoch nicht den Zustand wiederherstellen. Beides kommt häufig vor. Beide sind 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 gesichert werden müssen, sondern wie dies korrekt zu gestalten ist. 

Warum Container eine andere Sicherung benötigen als VMs

VMs und Container weisen genügend Gemeinsamkeiten auf, 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 des Datenschutzes von Bedeutung sind:

1. Der Speicher von VMs bleibt auch nach dem Herunterfahren erhalten. Der Containerspeicher bleibt hingegen oft nicht erhalten. Wenn eine VM heruntergefahren wird, bleibt ihr zugewiesener Speicher erhalten. Wenn ein Kubernetes-Pod heruntergefahren wird, kann das Kubelet dessen „emptyDir“-Volumes sowie jeglichen nicht persistenten Speicher zurückgewinnen.
2. VMs sind relativ stabil. Pods sind von ihrer Konzeption her vorübergehend. Kubernetes ist so konzipiert, dass das Starten, Beenden und Neuzuweisen von Pods zum normalen Betriebsablauf gehört. Eine Datensicherung, die von langlebigen Workloads mit vorhersehbaren Zeitplänen ausgeht, ist hierfür nicht geeignet.
3. VMs führen jeweils 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. Ein Backup auf Pod-Ebene fragmentiert die Anwendung. 

Die fünf Herausforderungen, die das Kubernetes-Backup architektonisch von anderen Lösungen unterscheiden

Analysten der Data Center Intelligence Group (DCIG) haben fünf spezifische Herausforderungen identifiziert, die Backup-Software bewältigen muss, um Kubernetes-Umgebungen zu schützen. Das Rahmenkonzept hat sich bewährt und verdeutlicht, was den Kubernetes-nativen Schutz von Backup-Tools unterscheidet, die aus der VM-Ära adaptiert wurden.

1. Kurzlebiger Speicher

Wenn ein Pod heruntergefahren wird, kann Kubernetes dessen Speicherplatz wieder freigeben. Die Daten gehen damit effektiv verloren. Dies hat zwei Auswirkungen auf 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 möglicherweise nur Stunden und nicht Tage dauert. Backup-Zeitpläne, die auf nächtlichen Zeitfenstern basieren, eignen sich nicht für Workloads, die morgen früh möglicherweise nicht mehr existieren.

2. Unvorhersehbarkeit

Der Kube-Scheduler entscheidet anhand der Ressourcenverfügbarkeit, Affinitätsregeln, Taints und Toleranzen, wo Pods ausgeführt werden. Nicht auf der Grundlage von Präferenzen des Betreibers. Ein Pod kann jederzeit auf jedem Knoten in jedem Cluster ausgeführt werden. Die Backup-Plattform muss der Workload folgen, anstatt von einem festen Standort auszugehen, und sie muss Schutzentscheidungen auf Workload-Ebene treffen. Nicht alle Container benötigen ein Backup. Einige müssen nur bei bestimmten Lebenszyklusereignissen wie vor dem Herunterfahren gesichert werden.

3. Skalierbarkeit

Ein Kubernetes-Produktionsdeployment kann Tausende von Pods über Hunderte von Namespaces hinweg ausführen. In Multi-Cluster-Umgebungen steigt diese Zahl auf Millionen an. Container werden wesentlich häufiger gestartet und beendet als VMs. Eine Backup-Plattform, deren Skalierbarkeit linear vom Aufwand des Betreibers abhängt – manuelle Registrierung, manuelle Zuweisung von Richtlinien, manuelle Überprüfung –, wird zum Engpass. Kubernetes-Backups erfordern eine cloudnative, dynamisch skalierbare Backup-Infrastruktur, die mit der Arbeitslast mitwächst und schrumpft.

4. Umfang: Anwendungen plus Control Plane

Containerisierte Anwendungen sind wichtig, aber ohne den Zustand der Control Plane, die sie orchestriert, sind sie nutzlos. etcd ist die zentrale Informationsquelle des Clusters. Welche Deployments existieren, welche ConfigMaps und Secrets sind an welche Workloads gebunden, welche CRDs erweitern die API, welche RBAC-Regeln regeln den Zugriff. Ausgereifte Kubernetes-Umgebungen automatisieren die Steuerungsebene mittels GitOps und können sie bei Bedarf neu aufbauen. Weniger ausgereifte Bereitstellungen sind auf die Backup-Plattform angewiesen, um beide Ebenen zu erfassen.

5. Komplexität der Wiederherstellung

Bei der Wiederherstellung treten alle zuvor genannten Herausforderungen gleichzeitig zutage. Die Plattform muss ermitteln, welches Backup wiederhergestellt werden soll (Datum, Cluster, Namespace, Anwendungskontext), die Abhängigkeiten zwischen containerisierten Anwendungen berücksichtigen, die möglicherweise gemeinsam gestartet werden müssen, und zunehmend die Wiederherstellung in ein anderes Kubernetes-Deployment als dasjenige vornehmen, das gesichert wurde. Anderer Cluster, andere Cloud, andere K8s-Version, möglicherweise andere Distribution (EKS vs. AKS vs. GKE vs. On-Prem). Die Backup-Plattform muss sowohl über die Quelle als auch über das Ziel ausreichend informiert sein, um zwischen beiden zu übersetzen. 

Was ein vollständiges Kubernetes-Backup schützen muss

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

Die Rolle von Container-Labels und Metadaten

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

Eine gut konzipierte Backup-Plattform überwacht den Start von Containern und liest 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-Aufträge über die Integration mit dem kube-scheduler planen, sodass Kubernetes selbst entscheidet, wo die Backup-Aufgaben ausgeführt werden – genauso, wie es entscheidet, wo Pods ausgeführt werden.

Dieses Muster unterscheidet sich vom 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 geschützt. 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 nicht lange im einfachen Fall. Drei reale Szenarien, die Backup-Plattformen nun bewältigen müssen.

Migration von Workloads zwischen EKS, AKS, GKE und On-Prem-Distributionen. Entscheidungen zum Cluster-Lebenszyklus (Kostenoptimierung, Regionwechsel, 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 Wiederherstellungs-Workload in einem Cluster einer anderen Region gestartet – 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 anonymisierten Daten) in Testclustern 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. Drei Muster, auf die Sie achten sollten.

Fehler 1: Backup ausschließlich auf persistenter Speicherung

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 Daten ohne Kontext. Ein reines Speicher-Backup ist eine nützliche Grundfunktion. Es ist jedoch keine Kubernetes-Backup-Strategie.

Fehler 2: Nachträglich angefügte Plug-ins für ältere Backup-Produkte

Als bestehende Backup-Anbieter zwischen 2019 und 2021 „Kubernetes-Unterstützung“ hinzufügten, lieferten viele Plug-ins aus, die ihre Architektur aus der VM-Ära so anpassten, dass sie Kubernetes-APIs aufrufen konnten. Das Ergebnis besteht in der Regel darin, dass Container als separate Workloads behandelt werden, die eine eigene Infrastruktur erfordern – wodurch genau jene isolierte Datensicherung entsteht, 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 feststellte, führt die Behandlung von Kubernetes als nachträglich angehängtes Modul selten zu dem Betriebsmodell, das Plattformteams erwarten. 

Fehler 3: Die Control Plane wird außer Acht gelassen

GitOps-Umgebungen, die ihre Control Plane bei Bedarf aus der Quellcodeverwaltung neu aufbauen, können auf die 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 des Clusters darüber, was bereitgestellt wurde, verloren. Entweder ist die Sicherung der Control Plane Teil der Schutzstrategie, oder es besteht eine betriebliche Disziplin rund um GitOps. Nicht beides.

Häufige Fragen zur Kubernetes-Sicherung

Müssen zustandslose Workloads gesichert werden? 

Zustandslose Workloads verfügen zwar über keine Anwendungsdaten, die gesichert werden müssten, jedoch über Konfigurationen (Deployments, ConfigMaps, Service-Definitionen, Ingress-Regeln), deren Erfassung sinnvoll ist. Wird der Namespace zerstört, lassen sich zustandslose Workloads schnell aus Container-Images wiederherstellen – allerdings nur, wenn Sie die Konfigurationsmanifeste zur Hand haben. Die meisten Teams erkennen dies erst, wenn sie nach einem Cluster-Vorfall zum zweiten Mal einen Service aus dem Gedächtnis neu erstellen müssen.

Wie sieht es mit CSI-Snapshots aus?

CSI-Snapshots sind eine nützliche Grundfunktion, die die Backup-Plattform im Hintergrund nutzen sollte. Sie erfassen zeitpunktbezogene Kopien von persistenten Volumes auf der Speicherebene. CSI-Snapshots allein stellen jedoch keine Backup-Strategie dar. Sie sind an das Speicher-Backend gebunden, erfassen keine Namespace-Konfiguration, lassen sich ohne zusätzliche Tools nicht zwischen Clustern verschieben und teilen in der Regel das Schicksal des Clusters, in dem sie sich befinden (geht der Cluster verloren, gehen auch die Snapshots verloren). Eine Backup-Plattform, die CSI-Snapshots orchestriert und den Rest der Workload erfasst, ist das richtige Vorgehen. 

Kann ich ein Backup von einer Kubernetes-Distribution in eine andere wiederherstellen?

Das hängt von der Backup-Plattform ab. Die Distributionen unterscheiden sich hinsichtlich ihrer API-Erweiterungen, Standard-Ingress-Controller, Speicherklassen und Sicherheitsstandards. Eine Plattform, die die Workload auf der Ebene der Kubernetes-Objekte (Deployments, Services, PVCs) erfasst und zielspezifische Konfigurationen bei der Wiederherstellung anpasst, kann Workloads mit überschaubarem Aufwand zwischen EKS-, AKS-, GKE- und On-Prem-Clustern verschieben. Eine Plattform, die Speicher-Snapshots auf der Ebene des Cloud-Anbieters erfasst, ist dazu nicht in der Lage. Die Snapshots sind an den jeweiligen Anbieter gebunden.

Wo Sie beginnen sollten

Wenn Sie Kubernetes bereits schützen, führen Sie in diesem Quartal eine Tabletop-Übung durch. Nehmen Sie Ihre kritischste containerisierte Anwendung. Gehen Sie Schritt für Schritt durch, wie Sie diese in einem anderen Cluster in einer anderen Region wiederherstellen würden, wenn der ursprüngliche Cluster nicht mehr verfügbar ist. Sollte jemand im Team während der Durchsicht das Wort „manuell“ verwenden, haben Sie Ihre Schwachstelle gefunden.