nespix - stock.adobe.com
Einer Schätzung von Gartner zufolge werden bis zum Jahr 2027 rund 50 Prozent der geschäftskritischen Anwendungen...
außerhalb zentralisierter Public Cloud Locations laufen. Der Markt für CIPS (Cloud Infrastructure and Platform Services) wird sich demnach merklich verändern. Zu den Trends, die künftig die Unternehmens-IT maßgeblich verändern werden, gehört unter anderem das Container-Management einschließlich des Backups.
Container in der Cloud unterliegen nicht immer demselben Backup-Regime wie sie für Volumes, Folder und Files gelten. Das liegt vor allem daran, dass die containerisierten Daten „transparent“ in den Container-Strukturen liegen. Dort stellt unter anderem der „invisible persistent storage“ (Persistent Volumes, unsichtbarer dauerhafter Speicher) ein Risiko dar.
Diese Strukturen innerhalb der Container werden von gängigen Tools zur Hochverfügbarkeit üblicherweise nicht behandelt. Dabei gelten für Container die gleichen Anforderungen an RTO und RPO (und auch an das RCO, die Recovery Consistency Objective).
IT-Risiken gelten auch für Kubernetes
Die Ursachen der Störungen verschwinden nicht durch die Verlagerung der Daten in die Cloud. Die Risiken für containerisierte IT-Anwendungen sind die gleichen wie für jede IT-Infrastruktur: Unglücke, Hardwarestörungen, menschliche Fehler (darunter irrtümliches Löschen von einzelnen Spalten oder Tabellen in Datenbanken oder gar kompletter Tabellen) bis hin zu Störungen auf dem Übertragungsweg. Es gibt viele Wege, auf denen die containerisierten Daten beschädigt werden können. Zudem gibt es noch die Störungen von außen, darunter vor allem Cyberattacken.
On-premises können Störungen auftreten, die mit einem Backup wiederhergestellt werden können. Doch wie sieht dies bei Kubernetes aus, wo komplette Datensammlungen in Containern in die Cloud verlagert worden sind. Ein herkömmliches Backup scheitert bei Kubernetes, weil die Datenstrukturen „transparent“ in der Cloud abgelegt sind.
Manche Admins behelfen sich mit dem, was die Kommandozeile hergibt. Das ist naturgemäß wirksam, doch nur wenig flexibel. Kubernetes verfügt über Befehle wie „kubectl get all --all-namespaces“ (zeigt eine Liste aller Ressourcen an). Das wäre ein Anfang. Die ectl-Befehle lassen sich weiter parametrisieren, um dann zum Beispiel die PV- und PVC-Objekte zu finden.
Allerdings gibt es einige Daten und Ressourcen, die mit den ectl-Befehlen möglicherweise nicht vollständig gesichert werden. Das sind zum Beispiel Anwendungsdaten innerhalb von Pods. Die ectl-Befehle listen zwar die Pods, sichern jedoch nicht die tatsächlichen Daten und Dateien, die von Anwendungen innerhalb dieser Pods erstellt oder verwendet werden. Ähnlich sieht es bei dynamisch erzeugten Ressourcen aus. Werden Ressourcen während des Betriebs angelegt, werden diese möglicherweise nicht erfasst, wenn Sie nur statische Listen von vorhandenen Ressourcen abrufen.
Während die Befehle ConfigMaps und Secrets anzeigen, zeigen sie unter Umständen nicht alle Konfiguration und Einstellungen. Applikationsspezifische Konfigurationseinstellungen vorhanden sein, die von den etcl-Befehlen nicht zwingend erfasst werden.
Jede Veränderung bedarf erneuter Eingriffe. Das gilt dann auch für die Batch-Dateien, die für einzelne Routine-Aufgaben gebastelt worden sind.
Um eine umfassende Sicherung von Kubernetes durchzuführen, ist es wichtig, eine ganzheitliche Sicherungsstrategie zu entwickeln, die alle relevanten Daten und Ressourcen berücksichtigt.
Tools zur ganzheitlichen Erfassung der Container
In den letzten Jahren haben die Hersteller die Situation erkannt und mit entsprechenden Tools reagiert. Dazu gehört unter anderem Kasten by Veeam, das frühere Kasten 10 von Kasten. Kasten wurde 2020 von Veeam übernommen und in die eigenen Container-Management-Angebote integriert.
Lösungen wie die von Veeam betrachten die Container nicht ganzheitlich, sondern sehen die einzelnen Kubernetes-Einheiten wie die etcd-Datenbank, Persistent Volumes, anwendungsspezifische Konfigurationsdateien und darunterliegenden Strukturen, die erforderlich sind, wenn nicht nur die Daten, sondern lauffähige Applikationen wiederhergestellt werden sollen.
Damit betrachten sie auch das Wiederherstellungsziel „RCO“, zusätzlich zu RTO und RPO. Kasten bietet spezialisierte Datensicherungslösungen für Kubernetes-Containerumgebungen.
Kasten berücksichtigt die Besonderheiten von Kubernetes-Containern und wurde spezifisch für Kubernetes-Backups entwickelt. Containern, Pods, Anwendungen und persistenter Speicher innerhalb einer Kubernetes-Infrastruktur werden granular gesichert und wiederhergestellt. Insbesondere die Sicherung von Persistent Volumes ist hier wichtig, weil dabei auch Daten, außerhalb der Container gespeichert sind, jedoch zu einer Applikation gehören, gesichert werden.
Ein Kubernetes-Backup sichert Applikationen also konsistent, unabhängig davon, ob diese auf einem oder auf mehreren Containern laufen. Datenbanken und Anwendungen lassen sich dadurch in einem weitgehend laufähigen Zustand wiederherstellen.
Wie bei Backup-Lösungen für On-premises-Infrastrukturen sollten Container-Backups Automatisierungsfunktionen und Orchestrierungs-Tools enthalten, um den Sicherungsprozess in Kubernetes-Clustern zu vereinfachen. Kasten by Veeam hat hier Funktionen im Leistungsumfang, mit denen sich Policies festlegen lassen. Über diese Policies können Administratoren Sicherungsrichtlinien festlegen, Zeitpläne erstellen und die Sicherung und Wiederherstellung von Containern automatisieren.
Während sich manuelle Backup-Regimes bei containerisierten Umgebungen nur schwer auf weitere Umgebungen übertragen lassen, kann Veeam durchaus flexibel auf weitere Kubernetes-Cluster übertragen. Da Kasten by Veeam in die Veeam-Lösungen integriert ist, besteht hier auch die Verbindung zu anderen Containermanagement-Tools.
Fazit: Lieber nicht manuell sichern
Die Datensicherung von Kubernetes ist also nicht weniger wichtig als die Sicherung von Volumes oder Dateien. Auch für Kubernetes gilt es, neben die Applikationen und ihre Daten nicht nur mit einem strengen Backup-Regime, sondern auch durch geeignete Verschlüsselungsverfahren zu schützen.
Auch die Backup-Strategie für die Container muss regelmäßig mit Ernstfallszenarien getestet werden. Das geht allerdings nur in enger Zusammenarbeit mit dem Cloud Service Provider, der hier den Ausfall der Cloud und auch den Verlust einzelner Daten zumindest simulieren muss.