Thought Leadership
Ein Kubernetes-Backup muss deutlich mehr leisten als die Sicherung von Daten auf persistenten Speichern.
Wer containerisierte Anwendungen zuverlässig wiederherstellen will, muss auch Konfigurationen, Abhängigkeiten und – je nach Umgebung – den Zustand der Kubernetes-Steuerungsebene berücksichtigen.
Container verändern die Anforderungen an Backups
Kubernetes-Umgebungen funktionieren nach anderen Regeln als klassische virtuelle Maschinen. Während der Speicher einer VM in der Regel auch nach dem Herunterfahren bestehen bleibt, können nicht persistente Daten eines Kubernetes-Pods beim Beenden verloren gehen. Gleichzeitig sind Pods grundsätzlich kurzlebig: Kubernetes startet, beendet und verteilt sie abhängig von den Anforderungen der Umgebung immer wieder neu.
Für die Datensicherung bedeutet das, dass traditionelle Backup-Konzepte nicht ohne Anpassungen übernommen werden können. Ein Sicherungsplan, der beispielsweise auf feste, nächtliche Backup-Zeitfenster setzt, passt schlecht zu Workloads, deren Bestand sich innerhalb kurzer Zeit verändern kann.
Hinzu kommt eine andere Betrachtungsebene. In Kubernetes bildet nicht der einzelne Pod zwangsläufig die sinnvolle Einheit einer Anwendung. Häufig sind Namespace, Helm-Release oder eine von einem Operator verwaltete Ressourcengruppe die relevanteren Grenzen.
Ein Backup muss die gesamte Workload erfassen
Eine funktionierende Wiederherstellung setzt voraus, dass mehrere Ebenen zusammenspielen. Dazu gehören zunächst die PersistentVolumes, in denen zustandsbehaftete Anwendungen ihre Daten speichern. Ebenso wichtig sind jedoch Namespace-Konfigurationen, YAML-Manifeste, ConfigMaps, Secrets und Custom Resource Definitions.
Wer beispielsweise ausschließlich die persistenten Volumes sichert, besitzt nach einem Ausfall zwar die Daten, aber nicht automatisch die Informationen, die für den Betrieb der Anwendung erforderlich sind. Umgekehrt reicht auch eine Sicherung der YAML-Dateien nicht aus, wenn die darin beschriebene Anwendung auf Daten angewiesen ist, die nicht mitgesichert wurden.
Bei verteilten Anwendungen kommt eine weitere Herausforderung hinzu: Mehrere Pods können voneinander abhängig sein oder gemeinsam auf Speicher zugreifen. Die Sicherung muss deshalb gegebenenfalls koordiniert erfolgen, damit die Daten nach der Wiederherstellung einen konsistenten Zustand aufweisen.
Fünf Faktoren erschweren die Sicherung
Nach dem im Ausgangstext beschriebenen DCIG-Framework ergeben sich für Kubernetes insbesondere fünf architektonische Herausforderungen: kurzlebiger Speicher, die dynamische Platzierung von Workloads, hohe Skalierungsanforderungen, die notwendige Abdeckung von Anwendung und Control Plane sowie die Komplexität der Wiederherstellung.
Besonders die Dynamik von Kubernetes stellt klassische Sicherungskonzepte vor Probleme. Der Scheduler entscheidet anhand von Ressourcenverfügbarkeit, Affinitätsregeln, Taints und Tolerations, auf welchem Node ein Pod ausgeführt wird. Eine Backup-Lösung muss deshalb der Workload folgen, anstatt sich auf einen dauerhaft festen Speicherort zu verlassen.
Mit steigender Zahl von Clustern und Pods wächst zudem der Verwaltungsaufwand. In großen Umgebungen können Tausende von Pods und Hunderte von Namespaces zusammenkommen. Eine manuelle Registrierung und Zuordnung einzelner Workloads wird damit schnell zum operativen Engpass.
Auch die Control Plane gehört ins Konzept
Eine weitere häufig unterschätzte Komponente ist der Zustand der Kubernetes-Control-Plane. Das System etcd enthält zentrale Informationen darüber, welche Workloads im Cluster vorhanden sind und welche Konfigurationen, Zugriffsregeln und Erweiterungen ihnen zugeordnet sind. Dazu zählen unter anderem CRDs, RBAC-Regeln, ConfigMaps und Secrets.
Nicht jede Umgebung muss diesen Zustand zwingend über ein klassisches Backup absichern. In konsequent umgesetzten GitOps-Architekturen kann die Control Plane teilweise aus der Versionsverwaltung rekonstruiert werden. Wo Konfigurationen jedoch manuell im Cluster entstanden sind oder nicht in der Quellcodeverwaltung liegen, kann der Verlust von etcd erhebliche Wiederherstellungsprobleme verursachen.
Labels können Backups automatisieren
Kubernetes stellt mit Labels und Metadaten einen Mechanismus bereit, mit dem sich Sicherungsprozesse stärker an der tatsächlichen Workload ausrichten lassen. Eine Backup-Plattform kann diese Informationen überwachen und daraus ableiten, welche Anwendungen geschützt werden sollen und welche Sicherungsrichtlinien gelten.
Das verändert auch die Rolle der Administratoren. Statt jede neue Workload einzeln für die Sicherung zu registrieren, werden die Regeln zentral definiert. Neue Anwendungen können dadurch automatisch in die entsprechenden Sicherungsprozesse aufgenommen werden, während nicht mehr benötigte Workloads keinen unnötigen Backup-Aufwand erzeugen.
Dieses deklarative Prinzip passt zum grundsätzlichen Betriebsmodell von Kubernetes: Nicht der dauerhafte Aufenthaltsort einer Anwendung steht im Mittelpunkt, sondern ihr gewünschter Zustand.
Wiederherstellung darf nicht am Cluster enden
Besonders anspruchsvoll wird die Datensicherung, wenn Anwendungen nicht im ursprünglichen Cluster wiederhergestellt werden sollen. In der Praxis können Migrationen zwischen unterschiedlichen Kubernetes-Umgebungen notwendig werden – etwa zwischen Amazon EKS, Microsoft AKS, Google GKE und On-Premises-Installationen. Auch ein Wechsel der Region oder die Bereitstellung einer separaten Testumgebung kann eine Wiederherstellung auf einem anderen Cluster erforderlich machen.
Eine belastbare Backup-Strategie muss deshalb mit unterschiedlichen Zielumgebungen umgehen können. Neben einem anderen Cluster können sich dabei auch Cloud, Region, Kubernetes-Version oder Distribution unterscheiden.
Das macht die Wiederherstellung zu mehr als einem einfachen Zurückspielen von Daten. Die Backup-Lösung muss die Unterschiede zwischen Ausgangs- und Zielumgebung berücksichtigen und die Workload entsprechend anpassen.
Drei typische Fehlansätze
Aus den beschriebenen Anforderungen lassen sich mehrere typische Schwachstellen ableiten. Ein häufiger Fehler besteht darin, nur die persistenten Speicher zu sichern. Das schützt zwar die Daten, erfasst aber nicht zwangsläufig die Konfiguration und den Kontext, die für den Betrieb der Anwendung erforderlich sind.
Problematisch kann auch sein, Kubernetes lediglich als Erweiterung einer bestehenden VM-orientierten Backup-Infrastruktur zu behandeln. Wenn Container nachträglich über Plug-ins in ein traditionelles Modell integriert werden, entstehen häufig getrennte Prozesse und zusätzliche Verwaltungsaufwände.
Der dritte Fehler ist das Ausblenden der Control Plane. Wer sich ausschließlich auf GitOps verlässt, sollte sicherstellen, dass tatsächlich sämtliche relevanten Konfigurationen und Ressourcen über diesen Weg rekonstruiert werden können. Andernfalls bleibt eine Lücke in der Wiederherstellungsstrategie.
Wiederherstellung als Praxistest
Für Unternehmen empfiehlt sich daher ein konkreter Belastungstest: Eine geschäftskritische Kubernetes-Anwendung sollte unter der Annahme ausgewählt werden, dass ihr ursprünglicher Cluster vollständig ausgefallen ist. Anschließend wird durchgespielt, wie die Anwendung in einem anderen Cluster und möglichst auch in einer anderen Region wiederhergestellt werden könnte.
Der entscheidende Prüfstein ist dabei der Grad der Automatisierung. Muss das Team während des Szenarios zahlreiche manuelle Schritte durchführen, zeigt dies, wo die bestehende Strategie Schwächen besitzt. Genau dort sollte die Vorbereitung auf einen tatsächlichen Ausfall ansetzen.
Kubernetes-Backup ist damit letztlich weniger eine Frage einzelner Snapshot-Funktionen als des gesamten Wiederherstellungsmodells. Erst wenn Daten, Konfigurationen, Abhängigkeiten und die erforderlichen Clusterinformationen gemeinsam betrachtet werden, lässt sich eine containerisierte Workload zuverlässig wieder in Betrieb nehmen.
(red/Kubermatic)
