Die CNCF veröffentlichte am 10. September 2026 Leitlinien auf Grundlage von drei reproduzierbaren Ausfallszenarien. Ziel ist es, die Notfallwiederherstellung zustandsbehafteter Kubernetes-Anwendungen zu testen, statt sich darauf zu beschränken, zu beobachten, dass ein Backup mit dem Status Completed beendet wurde. Die Experimente, die sich von einem Laptop aus aus dem Labor-Repository ausführen lassen, verwendeten eine PostgreSQL-Anwendung mit bekanntem Inhalt aus vier Zeilen. Dadurch konnte das tatsächliche Ergebnis der Wiederherstellung überprüft werden, anstatt sich auf allgemeine Statusindikatoren zu verlassen.
Das Material wurde von Saiyam Pathak und Saloni Narang erstellt, die beide CNCF-Botschafter sind. Der Anwendungsbereich beschränkt sich auf die Wiederherstellung des Anwendungszustands innerhalb von Kubernetes; Compliance-Frameworks, Produktvergleiche sowie die Wiederherstellung der zugrunde liegenden Cloud- oder Rechenzentrumsinfrastruktur werden nicht behandelt. Tools wie Velero und CSI-Snapshot-Schnittstellen dienten als Referenzimplementierungen für die Szenarien, während die Ausfallmuster auf Tools anwendbar sind, die dieselben Aufgaben erfüllen.
Ein abgeschlossenes Backup beweist keine Wiederherstellbarkeit
Im ersten Szenario wurden die Komponenten eines Kubernetes-Backups in Ressourcendefinitionen im YAML-Format und Daten aus persistenten Volumes aufgeteilt. Das Labor verwendete Velero mit einem Mechanismus zur Datenübertragung in einen S3-kompatiblen Objektspeicher außerhalb beider Cluster. Die Prüfung von DataUpload-Objekten zeigte, dass tatsächlich 47.989.888 Bytes an Volume-Daten in den externen Speicher übertragen wurden.
Nach dem Löschen des Namespace einschließlich der PVCs stellte die Wiederherstellung innerhalb von etwa zwei Minuten dieselben vier Zeilen wieder her. Die CNCF warnt jedoch davor, dass der Schutz der Volume-Daten ein anwendungskonsistentes Datenbank-Backup nicht automatisch gewährleistet; Anwendungen benötigen möglicherweise Flush- oder Quiesce-Maßnahmen. Eine Wiederherstellung auf einer anderen Infrastruktur kann außerdem eine Anpassung der StorageClass und weitere Konvertierungen erfordern, die das Team entwerfen und testen muss.
Wichtig ist zudem, dass Backup-Tools Ressourcen in einem bereits vorhandenen Cluster wiederherstellen, jedoch keine Knoten, Netzwerke, Load Balancer oder DNS-Einträge erstellen. Daher muss der Wiederherstellungsplan die Umgebung, in der das Backup aufgenommen wird, eindeutig festlegen. Die Wiederherstellung von Kubernetes sollte bei Bedarf Infrastructure as Code oder der Cluster API zugeordnet werden.
Git stellt die Absicht wieder her, nicht den gespeicherten Zustand
Im zweiten Szenario wurde der Produktionscluster abgeschaltet, während der Wiederherstellungscluster bereits vorhanden war und einen mit einem Git-Repository verbundenen GitOps-Controller sowie ein mit dem gemeinsamen Speicher verbundenes Backup-Tool enthielt. Die Anwendungssynchronisierung war erfolgreich, der StatefulSet lief, und das Dashboard zeigte einen gesunden Status. Eine Abfrage der Datenbank gab jedoch den Fehler aus: relation "attendees" does not exist.
Die Ursache war kein Fehler in Kubernetes oder GitOps. Das Repository enthielt lediglich die Definitionen, weshalb der Controller einen StatefulSet, einen Service und ein neues, leeres Storage-Volume erstellte. Praktisch speichert Git den deklarierten Zustand beziehungsweise die Absicht des Teams, während Backups die tatsächlichen Daten speichern. Keines von beiden kann die Anwendung allein vollständig wiederherstellen.
Die Wiederherstellungsmethode im Labor bestand darin, die von der Synchronisierung erstellte leere Anwendung zu entfernen, anschließend die Anwendung zusammen mit ihren Volumes aus dem Backup-Speicher wiederherzustellen und schließlich die Daten mit dem erwarteten Inhalt zu vergleichen. Der Zeitraum von der Abschaltung der Produktion bis zum Auftauchen überprüfter Daten betrug im Live-Experiment vier Minuten und beim erneuten Test knapp unter zwei Minuten. Die CNCF weist darauf hin, dass diese Werte nur den automatisierten Teil abdecken und die Erkennung des Vorfalls, die Entscheidungsfindung, die Umleitung des Datenverkehrs sowie die Rückkehr zur ursprünglichen Umgebung nicht einschließen.
Einzelne Snapshots können einen Wiederherstellungspunkt erzeugen, den es nie gab
Im dritten Szenario wurde eine Anwendung getestet, die zwei voneinander abhängige Storage-Volumes verwendet: eines für Bestellungen und eines für Zahlungen. Das Labor schrieb fünfmal pro Sekunde übereinstimmende Paare, wobei jede Zahlung einer Bestellung entsprechen musste. Bei der Erstellung zweier getrennter Snapshots im Abstand von fünf Sekunden wirkte jeder Snapshot für sich bereit und intakt. Die Wiederherstellung zeigte jedoch, dass die letzte erfasste Bestellung die Nummer 108352 hatte, während die letzte Zahlung die Nummer 108377 trug; damit gab es 25 Zahlungen ohne passende Bestellungen.
Das Ergebnis zeigt, dass der Erfolg jedes einzelnen Speichervorgangs keine Anwendungskonsistenz über mehrere Volumes hinweg garantiert. Die beiden Snapshots können zusammen einen Zeitpunkt beschreiben, der tatsächlich nie existiert hat. Laut dem Material kann sich die Abweichung in der Produktion vergrößern, wenn das Backup-Tool eine große Zahl von PVCs nacheinander verarbeitet.
VolumeGroupSnapshot, das in Kubernetes 1.36 den GA-Status erreicht hat, bietet einen Mechanismus, um Volumes mit einem einzigen Label auszuwählen und über CSI einen konsistenten Wiederherstellungspunkt anzufordern. Im koordinierten Experiment stimmte die letzte Nummer für Bestellungen und Zahlungen bei 109169 überein, und die Überprüfung ihrer Beziehung war erfolgreich. Die Unterstützung hängt jedoch vom Treiber ab. Die Unterstützung regulärer VolumeSnapshots belegt nicht die Unterstützung von Gruppen-Snapshots. Außerdem implementierten die meisten großen Cloud-Treiber, die für das Labor untersucht wurden, diese Funktion bis Mitte 2026 noch nicht. CRDs, die Snapshot-Funktion und die relevanten Erweiterungen müssen ebenfalls ausdrücklich aktiviert werden.
Was sollte ein Wiederherstellungstest messen?
- Die vollständige Wiederherstellung einer Anwendung auf ein sauberes Ziel, auf dem sie zuvor noch nicht ausgeführt wurde, statt lediglich einen Pod zu löschen und seine Neuerstellung zu beobachten.
- Die Überprüfung der Daten und des Benutzerzugriffspfads anhand erwarteter Inhalte, statt sich ausschließlich auf den Ressourcenstatus oder die Farben in Dashboards zu verlassen.
- Die Messung des gesamten Vorgangs mit einer Uhr, wobei berücksichtigt wird, dass die tatsächliche Wiederherstellungszeit die Erkennung, die Entscheidung, die Umleitung des Datenverkehrs und möglicherweise die Rückkehr zur ursprünglichen Umgebung umfasst.
- Die Verwendung zweier unabhängiger Ausfallbereiche, etwa eines Produktions- und eines Wiederherstellungsclusters, wobei der Backup-Speicher außerhalb beider Cluster liegt.
Redaktionelle Einordnung: Eine Lücke zwischen Tools und der Abfolge der Wiederherstellung
Die praktische Veränderung, die diese Experimente hervorheben, besteht darin, das Erfolgskriterium von „Das Backup wurde abgeschlossen“ zu „Die richtigen Daten sind wiederhergestellt und zugänglich“ zu verlagern. Die umfassendere Einschränkung besteht darin, dass Kubernetes selbst keinen gemeinsamen Vertrag für die Koordination von Daten, Anwendung, Cluster, Datenverkehr und Identität definiert und keine standardisierte, dauerhafte Ressource bereitstellt, die die vollständige Wiederherstellungseinheit einer Anwendung samt ihren externen Abhängigkeiten beschreibt. Daher bleiben die Grenzen zwischen GitOps, Backup, Infrastruktur und Benutzerpfad auch bei ausgereiften Tools für jede einzelne Schicht in der Verantwortung des Teams. Die CNCF weist darauf hin, dass die Initiative Cloud Native Business Continuity der CNCF TAG Operational Resilience Beiträge zur Analyse von Lücken im Ökosystem, zu Wiederherstellungsleitlinien und zu Referenzarchitekturen sammeln soll.