Wie sichert man Kubernetes? Kubernetes Sicherung

Während die Annahme, dass Kubernetes früher hauptsächlich von DevOps-Teams genutzt wurde, in gewisser Weise richtig war, setzen viele Unternehmen jetzt aktiv Container in betrieblichen Umgebungen ein. Sie entscheiden sich auch zunehmend für Container-zentrierte Ansätze anstelle von traditionellen VMs. Dies ist auf die verschiedenen Vorteile in Bezug auf Flexibilität, Leistung und Kosten zurückzuführen, die Container oft bieten können. Mit dem Einzug von Containern in den operativen Bereich der IT-Umgebung wachsen jedoch auch die Bedenken hinsichtlich der Sicherheitsaspekte von Containern in geschäftskritischen Umgebungen, einschließlich ihrer persistenten Daten im Zusammenhang mit Sicherungs- und Wiederherstellungsprozessen.

Ursprünglich war die überwältigende Mehrheit der containerisierten Anwendungen zustandslos, so dass der Bereitstellungsprozess in einer öffentlichen Cloud viel einfacher war. Das änderte sich jedoch im Laufe der Zeit, und es werden nun viel mehr zustandsabhängige Anwendungen in Containern bereitgestellt als früher. Diese Veränderung ist der Grund, warum Backup und Recovery in Kubernetes jetzt ein wichtiges Thema für viele Unternehmen ist.

Wichtige Merkmale einer kompetenten Kubernetes-Backup-Lösung

Die dynamische Natur von Kubernetes-Umgebungen macht es für herkömmliche Backup-Systeme und -Techniken schwieriger, im Kontext von Kubernetes-Knoten und -Anwendungen gut zu funktionieren. Sowohl RPO als auch RTO müssen unter Umständen sehr viel strenger sein, da die Anwendungen ständig in Betrieb sein müssen oder besonders kritisch sind usw.

Daraus ergeben sich drei verschiedene Funktionen, die für jedes Unternehmen im Allgemeinen sehr empfehlenswert sind und eine klare Notwendigkeit darstellen, wenn es um Best-Practice-Kubernetes-Backups geht:

• Disaster Recovery;
• Sicherung und Wiederherstellung;
• Lokale Hochverfügbarkeit.

In einer Kubernetes-Umgebung kann sich der Kontext dieser drei Aspekte der Sicherung leicht von ihrer normalen Definition unterscheiden:

Bei der lokalen Hochverfügbarkeit geht es eher um die Vermeidung von Ausfällen bzw. den Schutz vor Ausfällen innerhalb eines bestimmten Rechenzentrums oder über Verfügbarkeitszonen hinweg (z. B. wenn es sich um die Cloud handelt). Ein „lokaler“ Ausfall ist derjenige, der in der Infrastruktur/dem Knoten/der Anwendung auftritt, die/der für die Ausführung der Anwendung verwendet wird. In einem perfekten Szenario sollte Ihre Kubernetes-Backup-Lösung in der Lage sein, auf diesen Ausfall zu reagieren, indem sie die Anwendung am Laufen hält, was im Wesentlichen keine Ausfallzeiten für den Endbenutzer bedeutet. Eines der häufigsten Beispiele für einen lokalen Ausfall ist ein festsitzendes Cloud-Volume, das nach einem Knotenausfall auftritt.

In dieser Hinsicht kann die lokale Hochverfügbarkeit als eine Funktion als Grundlage des gesamten Datensicherungssystems betrachtet werden. Um eine solche Aufgabe zu erfüllen, muss Ihre Lösung zum einen eine Art lokales Datenreplikationssystem bieten, und zum anderen muss es sich überhaupt erst im Datenpfad befinden. Es ist wichtig zu erwähnen, dass die Bereitstellung lokaler Verfügbarkeit über die Wiederherstellung von Sicherungen immer noch als Sicherung und Wiederherstellung und nicht als lokale Hochverfügbarkeit betrachtet wird, da die Wiederherstellungszeit insgesamt länger ist.

Die Sicherung und Wiederherstellung ist ein weiterer wichtiger Bestandteil eines Kubernetes-Sicherungssystems. In den meisten Anwendungsfällen wird die gesamte Anwendung außerhalb eines lokalen Kubernetes-Clusters gesichert. Der Kontext von Kubernetes bringt auch eine weitere wichtige Überlegung mit sich – ob die Backup-Software „versteht“, was in einer Kubernetes-App enthalten ist, wie z. B.:

• App-Konfiguration;
• Kubernetes-Ressourcen;
• Daten

Ein korrektes Kubernetes-Backup muss alle oben genannten Teile als eine Einheit speichern, damit es nach der Wiederherstellung im Kubernetes-System nützlich ist. Die Ausrichtung auf bestimmte VMs, Server oder Festplatten bedeutet nicht, dass eine Software Kubernetes-Anwendungen „versteht“. Idealerweise sollte eine Kubernetes-Software in der Lage sein, bestimmte Anwendungen, bestimmte Gruppen von Anwendungen sowie den gesamten Kubernetes-Namensraum zu sichern. Das soll nicht heißen, dass sich die Kubernetes-Sicherung völlig von einem normalen Backup-Prozess unterscheidet – Kubernetes-Backups können auch stark von einigen der regulären Funktionen eines üblichen Backups profitieren, einschließlich Aufbewahrung, Planung, Verschlüsselung, Tiering usw.

Eine Disaster Recovery (DR)-Fähigkeit ist wahrscheinlich für jedes Unternehmen, das Kubernetes in einer unternehmenskritischen Situation einsetzt, genauso wichtig wie bei jeder anderen Technologie. Zunächst einmal muss DR den Kontext von Kubernetes-Backups „verstehen“, genau wie Backup und Restore. Es kann auch verschiedene RTO- und RPO-Ebenen und verschiedene Schutzniveaus entsprechend dieser Ebenen geben. So könnte es beispielsweise eine strenge Null-RPO-Anforderung geben, die absolut keine Ausfallzeit bedeutet, oder eine 15-Minuten-RPO mit etwas weniger strengen Anforderungen. Es ist auch nicht ungewöhnlich, dass verschiedene Anwendungen innerhalb ein und derselben Datenbank völlig unterschiedliche RTO- und RPO-Anforderungen haben.

Ein weiteres wichtiges Unterscheidungsmerkmal eines Kubernetes-spezifischen Disaster-Recovery-Systems ist, dass es bis zu einem gewissen Grad auch mit Metadaten arbeiten können sollte (Labels, App-Replikate usw.). Wenn diese Funktion nicht zur Verfügung steht, kann dies leicht zu einer unzusammenhängenden Wiederherstellung im Allgemeinen sowie zu einem allgemeinen Datenverlust oder einer zusätzlichen Ausfallzeit führen.

Datentypen, die in Kubernetes gesichert werden müssen

Wie jedes komplexe System verfügen auch Kubernetes und Docker über eine Reihe spezifischer Datentypen, die sie benötigen, um die gesamte Datenbank im Falle einer Katastrophe ordnungsgemäß wiederherzustellen. Zur Vereinfachung können alle Daten- und Konfigurationsdateitypen in zwei verschiedene Kategorien unterteilt werden: Konfiguration und persistente Daten.

Konfiguration (und gewünschte Statusinformationen) umfassen:

• Kubernetes etcd-Datenbank
• Docker-Dateien
• Bilder von Docker-Dateien

Persistente Daten (die von Containern selbst geändert oder erstellt werden) sind:

• Datenbanken
• Persistente Datenträger

Kubernetes etcd-Datenbank

Sie ist ein integraler Bestandteil des Systems und enthält die Informationen über den Zustand des Clusters. Sie kann entweder manuell oder automatisch gesichert werden, abhängig von Ihrer Backup-Lösung. Die manuelle Methode erfolgt über den Befehl etcdctl snapshot save db, der eine einzelne Datei mit dem Namen snapshot.db erstellt.

Eine andere Methode besteht darin, denselben Befehl unmittelbar vor der Erstellung eines Backups des Verzeichnisses auszulösen, in dem sich diese Datei befinden würde. Dies ist eine der Möglichkeiten, dieses spezifische Backup in die gesamte Umgebung zu integrieren.

Docker-Dateien

Da Docker-Container selbst aus Images ausgeführt werden, müssen diese Images auf etwas basieren – und diese wiederum werden aus Docker-Dateien erstellt. Für eine korrekte Docker-Konfiguration ist es empfehlenswert, eine Art Repository als Versionskontrollsystem für die Gesamtheit der Docker-Dateien zu verwenden (z.B. GitHub). Um das Ziehen früherer Versionen zu erleichtern, sollten alle Docker-Dateien in einem bestimmten Repository gespeichert werden, das es den Benutzern ermöglicht, bei Bedarf ältere Versionen dieser Dateien zu ziehen.

Ein zusätzliches Repository wird auch für die YAML-Dateien empfohlen, die mit allen Kubernetes-Bereitstellungen verbunden sind und in Form von Textdateien vorliegen. Die Sicherung dieser Repositories ist ebenfalls ein Muss, entweder mit den Tools von Drittanbietern oder mit den integrierten Funktionen von GitHub.

Es ist wichtig zu erwähnen, dass Sie die zu sichernden Docker-Dateien auch dann noch spawnen können, wenn Sie Container aus Images ohne ihre Docker-Dateien ausführen. Es gibt einen speziellen Befehl, den Docker Image History, mit dem Sie eine Docker-Datei aus Ihrem aktuellen Image erstellen können. Es gibt auch einige Tools von Drittanbietern, die das Gleiche können.

Images aus Docker-Dateien

Auch die Docker-Images selbst sollten in einem Repository gesichert werden. Sowohl das private als auch das öffentliche Repository können für diesen Zweck verwendet werden. Verschiedene Cloud-Anbieter stellen ihren Kunden in der Regel auch private Repositories zur Verfügung. Wenn Ihnen das Image fehlt, auf dem Ihr Container läuft, sollte ein bestimmter Befehl, nämlich docker commit, in der Lage sein, dieses Image zu erstellen.

Datenbanken

Integrität ist auch bei Datenbanken wichtig, die Container zur Speicherung ihrer Daten verwenden. In einigen Fällen ist es möglich, den betreffenden Container vor der Erstellung eines Backups der Daten herunterzufahren, aber die dafür erforderliche Ausfallzeit dürfte für das betreffende Unternehmen eine Menge Probleme mit sich bringen.

Eine andere Methode zur Erstellung von Datenbanksicherungen innerhalb von Containern ist die Verbindung mit der Datenbank-Engine selbst. Zuvor sollte ein Bind-Mount verwendet werden, um ein Volume anzuhängen, das überhaupt gesichert werden kann, und dann können Sie den Befehl mysqldump (oder einen ähnlichen Befehl) verwenden, um eine Sicherung zu erstellen. Die betreffende Backup-Datei sollte anschließend ebenfalls mit Ihrem Backup-System gesichert werden.

Dauerhafte Datenträger

Man kann mit Fug und Recht behaupten, dass es für Container mehrere verschiedene Methoden gibt, um Zugriff auf eine Art persistenten Speicher zu erhalten. Wenn es sich um traditionelle Docker-Volumes handelt – diese befinden sich in einem Verzeichnis, das unterhalb der Docker-Konfiguration liegt. Bind-Mounts hingegen können jedes Verzeichnis sein, das innerhalb eines Containers gemountet wird. Trotz der Tatsache, dass traditionelle Volumes in der Docker-Community bevorzugt werden, sind beide relativ gleich, wenn es um die Sicherung von Daten geht. Eine dritte Möglichkeit, den gleichen Vorgang auszuführen, besteht darin, ein NFS-Verzeichnis oder ein einzelnes Objekt als Volume innerhalb eines Containers zu mounten.

Alle drei Methoden haben das gleiche Problem, wenn es um die Sicherung von Daten geht – die Konsistenz eines Backups ist nicht vollständig, wenn sich die Daten innerhalb eines Containers während des Backups ändern. Natürlich ist es immer möglich, die Konsistenz durch Abschalten des Datenträgers vor der Sicherung zu erhalten, aber in den meisten Fällen ist eine Ausfallzeit für solche Systeme im Interesse der Geschäftskontinuität nicht zu verantworten.

Es gibt einige Möglichkeiten, Daten innerhalb von Containern zu sichern, die methodenspezifisch sind. Traditionelle Docker-Volumes könnten beispielsweise in einen anderen Container gemountet werden, der bis zum Abschluss des Backup-Prozesses keine Daten verändert. Oder wenn Sie ein gebundenes Volume verwenden, ist es möglich, ein tar-Image des gesamten Volumes zu erstellen und dann das Image zu sichern.

Leider sind alle diese Optionen bei Kubernetes nur schwer umsetzbar. Genau aus diesem Grund wird immer empfohlen, zustandsbezogene Informationen in der Datenbank und außerhalb des Container-Dateisystems zu speichern.

Wenn Sie jedoch ein mit Bind gemountetes Verzeichnis oder ein mit NFS gemountetes Dateisystem als persistenten Speicher verwenden, ist es auch möglich, diese Daten mit den üblichen Methoden wie einem Snapshot zu sichern. Damit sollten Sie viel mehr Konsistenz erreichen als mit der traditionellen Sicherung desselben Volumes auf Dateiebene.

Markt für Kubernetes-Backup-Lösungen

Im Zusammenhang mit diesen drei wichtigen Faktoren/Merkmalen wollen wir uns ein paar weitere Beispiele für eine Kubernetes-Backup- und Recovery-Lösung ansehen. Die Beispiele, die wir hier verwenden, sind Kasten, Portworx, Cohesity, OpenEBS und Rancher Longhorn.

Kasten K10

Kasten K10 (kürzlich von Veeam übernommen) ist eine Sicherungs- und Wiederherstellungslösung, die auch auf ihre Mobilitäts- und Disaster-Recovery-Systeme stolz ist. Der Backup-Prozess mit Kasten wird dank seiner Fähigkeit, Anwendungen automatisch zu erkennen, sowie vieler anderer Funktionen wie Datenverschlüsselung, rollenbasierter Zugriffskontrolle und einer benutzerfreundlichen Schnittstelle vereinfacht. Gleichzeitig kann es mit vielen verschiedenen Datendiensten wie MySQL, PostgreSQL, MongoDB, Cassandra, AWS und so weiter arbeiten.

Lokale Hochverfügbarkeit ist damit nicht möglich, da Kasten die Replikation innerhalb eines einzelnen Clusters nicht direkt unterstützt und sich stattdessen auf die zugrunde liegenden Datenspeichersysteme verlässt. Auch die Disaster Recovery ist nur teilweise vorhanden, da Kasten aufgrund des Fehlens einer Datenpfadkomponente keine Null-RPO-Fälle erreichen kann. Ebenfalls erwähnenswert ist die Tatsache, dass Kastens Backups nur asynchron sind, was typischerweise eine zusätzliche Ausfallzeit zwischen den Operationen bedeutet.

Portworx

Portworx PX-Backup ist ein Datenmanagement-Unternehmen, das eine Cloud-basierte Speicherplattform für die Verwaltung und den Zugriff auf die Datenbank von Kubernetes-Projekten entwickelt. Es ist ein weiteres Beispiel für eine Datenverwaltungslösung und trotz seiner Einschränkungen als solche ist einer der Hauptvorteile der Verwendung von Portworx die hohe Verfügbarkeit der Daten.

Backup- und Wiederherstellungsvorgänge, das Verständnis von Kubernetes-Apps, lokale Hochverfügbarkeit, Disaster Recovery und andere Funktionen – all das macht Portworx zu einer guten Lösung für Kubernetes-Backup – wenn Sie nach einer Lösung suchen, die auf Kubernetes-bezogene Aufgaben spezialisiert ist.

Ein weiterer wichtiger Bestandteil von PX-Backup ist seine Skalierbarkeit, die On-Demand-Backups / geplante Backups von Hunderten von Anwendungen auf einmal ermöglicht. Die Lösung unterstützt auch Multi-Datenbank-Setups und kann Anwendungen direkt in Cloud-Diensten wie Amazon, Google, Microsoft usw. wiederherstellen.

Cohesity

Cohesity ist ein relativ beliebter Konkurrent im Bereich der allgemeinen Datensicherung und -wiederherstellung, aber seine Kubernetes-bezogenen Fähigkeiten haben noch etwas Raum zum Wachsen. Zunächst einmal ist Kubernetes für sie relativ neu, und sie haben das „Verständnis“ für Kubernetes-Anwendungen von Anfang an hinzugefügt, aber gleichzeitig funktioniert es nur für alle Anwendungen innerhalb desselben Namensraums, und Sie können keine spezifischen Anwendungen innerhalb dieses einen Namensraums schützen.

Auf der anderen Seite gibt es auch schnelle Wiederherstellungsfunktionen, inkrementelle Backups auf App-Tier-Basis auf der Grundlage von Richtlinien, Konsolidierung des Datenstatus und viele andere Funktionen.

OpenEBS

OpenEBS ist ein weiteres Beispiel für eine Lösung, die es geschafft hat, mit nur einer der drei Funktionen aus unserer Liste einige Ergebnisse zu erzielen, und in diesem Fall geht es um lokale Hochverfügbarkeit.

Gleichzeitig kann OpenEBS auch mit Velero integriert werden, so dass eine kombinierte Kubernetes-Lösung entsteht, die sich bei der Migration von Kubernetes-Daten auszeichnet. OpenEBS allein kann nur einzelne Anwendungen sichern (das direkte Gegenteil von dem, was Cohesity tut). Hinzu kommen Funktionen wie Multi-Cloud-Storage, der Open-Source-Charakter und eine riesige Liste unterstützter Kubernetes-Plattformen, von AWS und Digital Ocean bis hin zu Minikube, Packet, Vagrant, GCP und mehr.

Dies deckt jedoch möglicherweise nicht die Bedürfnisse der Nutzer ab, da einige Nutzer diese Namespace-Backups in bestimmten Anwendungsfällen benötigen.

Rancher Longhorn

Rancher Longhorn ist das letzte unserer Beispiele, und es ist wahrscheinlich das am wenigsten bekannte von allen. Die Community ist für eine Open-Source-Lösung relativ klein, und es ermöglicht keine vollständigen Kubernetes-Backups mit Metadaten und Ressourcen, um eine App-bewusste Wiederherstellung zu ermöglichen. Es gibt jedoch eine einzigartige Funktion, die hervorsticht, und die heißt DR Volume. DR Volume kann sowohl als Quelle als auch als Ziel eingerichtet werden, wodurch das Volume in einem neuen Cluster aktiv wird, der auf den neuesten gesicherten Daten basiert.

Ranchers Fähigkeiten, mit vielen verschiedenen Container-Plattformtypen zu arbeiten und verschiedene Backup-Methoden zuzulassen, sind das, was es von anderen unterscheidet, und es gibt bereits die Möglichkeit, Kubernetes Engine, Docker-Bereitstellungen und K3-Distributionen zu unterstützen. Docker-Container müssen zum Beispiel einen Tarball erstellen, der als Backup für Rancher dienen kann.

Rubrik

Viele andere, größere Akteure im Bereich Backup und Wiederherstellung haben damit begonnen, ihre eigenen Dienste in Bezug auf Kubernetes-Backup und -Wiederherstellung anzubieten – Rubrik ist ein gutes Beispiel: Es ermöglicht den Nutzern, das umfangreiche Management-Feature-Set von Rubrik im Bereich der Kubernetes-Deployments zu implementieren.

Es ermöglicht Flexibilität in Bezug auf das Wiederherstellungsziel, sowie den Schutz von Kubernetes-Objekten und eine einheitliche Plattform, die Einblicke und Überblick über das gesamte System bietet. Es gibt auch Funktionen wie Backup-Automatisierung, granulare Wiederherstellung, Snapshot-Replikation und mehr. Rubrik kann auch mit Persistent Volumes arbeiten und ist in der Lage, Namespaces zu replizieren – und bietet Ihnen damit die Möglichkeit, die Entwicklung und/oder das Testen vor dem Einsatz zu variieren.

Druva

Eine weitere Variante einer solchen Lösung wird von Druva präsentiert, die eine recht einfache, aber effektive Kubernetes-Backup- und Restore-Lösung bietet, mit allen erwarteten Grundfunktionen – Snapshots, Backup und Restore, Automatisierung und einigen zusätzlichen Funktionalitäten. Druva kann auch ganze Anwendungen innerhalb von Kubernetes wiederherstellen, mit viel Mobilität, wenn es um das Wiederherstellungsziel geht.

Darüber hinaus unterstützt Druva mehrere Admin-Rollen, kann Kopien von Workloads für die Fehlerbehebung erstellen und bestimmte Bereiche wie Namespaces oder Anwendungsgruppen sichern. Es gibt auch eine Vielzahl von Aufbewahrungsoptionen, umfassenden Kubernetes-Datenschutz, Unterstützung für Amazon EC2 und EKS (benutzerdefinierte Container-Workloads).

Zerto

Zerto ist ebenfalls eine gute Wahl, wenn Sie nach einer multifunktionalen Backup-Management-Plattform mit nativer Kubernetes-Unterstützung suchen. Sie bietet alles, was Sie sich von einer modernen Kubernetes-Backup- und Restore-Lösung wünschen: CDP (Continuous Data Protection), Datenreplikation über Snapshots und minimale Herstellerbindung, da Zerto alle Kubernetes-Plattformen im Enterprise-Bereich unterstützt.

Zerto bietet auch Datenschutz als eine der Kernstrategien vom ersten Tag an und bietet Anwendungen die Möglichkeit, von Anfang an mit Schutz zu generieren. Zerto verfügt außerdem über viele Automatisierungsfunktionen, kann umfangreiche Einblicke liefern und mit verschiedenen Cloud-Speichern gleichzeitig arbeiten.

Wie in diesem Blog deutlich wird, ist das Thema Kubernetes noch relativ neu und der Markt versucht immer noch, die vollständige Liste der Funktionen aufzuholen, die jedes Kubernetes-basierte System von Anfang an erfordert. Die gesamte Natur von Kubernetes macht Anwendungen zu einem ganz anderen Tier als zuvor, und das bringt uns zu der aktuellen Liste von Lösungen, die in einer Sache überragend sind und in der anderen aufholen müssen.

Es ist klar, dass Kubernetes ein schnell wachsender Technologiebereich ist, daher ist es sicher, dass es bald mehr Lösungen geben wird, wobei die aktuellen wahrscheinlich noch besser werden, als sie es jetzt schon sind. Ein Beispiel für eine neue, leistungsstarke Kubernetes-Lösung findet sich in Bacula Enterprise.

Die Kubernetes-Backup-Lösung von Bacula Enterprise

Die Natur von Kubernetes-Umgebungen macht sie gleichzeitig sehr dynamisch und potenziell komplex. Das Sichern eines Kubernetes-Clusters sollte die Komplexität nicht unnötig erhöhen. Und natürlich ist es für Systemadministratoren und anderes IT-Personal in der Regel wichtig – wenn nicht sogar entscheidend -, die zentrale Kontrolle über das gesamte Backup- und Recovery-System der gesamten Organisation zu haben, einschließlich aller Kubernetes-Umgebungen. Auf diese Weise werden Faktoren wie Compliance, Verwaltbarkeit, Geschwindigkeit, Effizienz und Geschäftskontinuität viel realistischer. Gleichzeitig soll der agile Ansatz von Entwicklungsteams dadurch in keiner Weise beeinträchtigt werden.

Bacula Enterprise ist in diesem Bereich einzigartig, weil es eine umfassende Unternehmenslösung für komplette IT-Umgebungen (nicht nur Kubernetes) ist, die auch nativ integriertes Kubernetes-Backup und -Wiederherstellung bietet, einschließlich mehrerer Cluster, unabhängig davon, ob sich die Anwendungen oder Daten außerhalb oder innerhalb eines bestimmten Clusters befinden. Jede Betriebsabteilung eines Unternehmens kennt die Notwendigkeit einer angemessenen Wiederherstellungsstrategie, wenn es um die Wiederherstellung von Clustern, Upgrades und andere Situationen geht. Ein Cluster, der sich in einem nicht wiederherstellbaren Zustand befindet, kann mit Bacula wieder in den stabilen Zustand zurückversetzt werden, wenn sowohl die Konfigurationsdateien als auch die persistenten Volumes des Clusters zuvor korrekt gesichert wurden.

Eine weitere Möglichkeit, die Arbeitsweise von Bacula zu veranschaulichen, ist das folgende Bild:

Einer der wichtigsten Vorteile des Kubernetes-Moduls von Bacula ist die Möglichkeit, verschiedene Kubernetes-Ressourcen zu sichern, darunter:

• Pods;
• Dienste;
• Deployments;
• Persistente Volumes.

Eigenschaften des Kubernetes-Moduls von Bacula Enterprise

Die Funktionsweise dieses Moduls besteht darin, dass die Lösung selbst nicht Teil der Kubernetes-Umgebung ist, sondern auf die relevanten Daten innerhalb des Clusters über Bacula-Pods zugreift, die an einzelne Kubernetes-Knoten in einem Cluster angeschlossen sind. Das Deployment dieser Pods erfolgt automatisch und funktioniert nach Bedarf.

Einige weitere Funktionen, die das Kubernetes-Backup-Modul bietet, sind:

• Kubernetes-Backup und -Wiederherstellung für persistente Volumes;
• Wiederherstellung einer einzelnen Kubernetes-Konfigurationsressource;
• Die Fähigkeit, Konfigurationsdateien und/oder Daten von persistenten Volumes in das lokale Verzeichnis wiederherzustellen;
• Die Möglichkeit, die Ressourcenkonfiguration von Kubernetes-Clustern zu sichern.

Es ist auch erwähnenswert, dass Bacula problemlos mehrere Cloud-Speicherplattformen gleichzeitig unterstützt, darunter AWS, Google, Glacier, Oracle Cloud und Azure, und zwar auf der Ebene der nativen Integration. Hybrid-Cloud-Fähigkeiten sind somit integriert, einschließlich fortschrittlichem Cloud-Management und automatisierten Cloud-Caching-Funktionen, die eine einfache Integration von öffentlichen oder privaten Cloud-Diensten zur Unterstützung verschiedener Aufgaben ermöglichen.

Die Flexibilität von Lösungen ist heutzutage besonders wichtig, da viele Firmen und Unternehmen in Bezug auf verschiedene Hypervisor-Familien und Container immer komplexer werden. Gleichzeitig steigt damit die Nachfrage nach Herstellerflexibilität für alle Datenbankanbieter erheblich. Bacula ist in dieser Hinsicht besonders leistungsfähig, da es seine breite Kompatibilitätsliste mit verschiedenen Technologien kombiniert, um besonders hohe Flexibilitätsstandards zu erreichen, ohne sich an einen Anbieter zu binden.

Die Komplexität verschiedener Aspekte der Arbeit eines Unternehmens nimmt ständig zu, und es ist oft einfacher und kosteneffizienter, eine Lösung für die gesamte IT-Umgebung zu verwenden und nicht mehrere Lösungen gleichzeitig. Bacula ist genau dafür konzipiert und bietet sowohl eine traditionelle webbasierte Schnittstelle für Ihre Konfigurationsanforderungen als auch die klassische Steuerung über die Kommandozeile. Diese beiden Schnittstellen können sogar gleichzeitig genutzt werden.

Das Kubernetes-Backup-Plugin von Bacula ermöglicht zwei Hauptzielarten für Wiederherstellungsoperationen:

• Wiederherstellung in ein lokales Verzeichnis;
• Wiederherstellung im Cluster.

Regelmäßige und/oder automatisierte Backups werden dringend empfohlen, um die bestmögliche Sicherungs- und Wiederherstellungsumgebung für Container zu gewährleisten. Auch für Ihren Systemadministrator sollte es Pflicht sein, Ihre Backups von Zeit zu Zeit zu testen. In der nächsten Abbildung sehen Sie einen Teil des Wiederherstellungsprozesses, nämlich den Teil Wiederherstellungsauswahl, in dem Sie auswählen können, welche Dateien und/oder Verzeichnisse Sie wiederherstellen möchten:

Ein weiterer Teil des Wiederherstellungsprozesses ist die Seite mit den erweiterten Wiederherstellungsoptionen, die wie folgt aussieht:

Hier können Sie mehrere verschiedene Optionen angeben, z. B. das Ausgabeformat, den Pfad der KBS-Konfigurationsdatei, den Endpunktport und vieles mehr.

Es ist auch einfach, den gesamten Wiederherstellungsprozess zu überwachen, nachdem die Anpassung abgeschlossen ist, dank der Wiederherstellungsjob-Protokollseite, die jede Aktion einzeln aufzeichnet:

Eine weitere wichtige Funktion des Kubernetes-Moduls ist das Plugin Listing, das viele nützliche Informationen über Ihre verfügbaren Kubernetes-Ressourcen, einschließlich Namespaces, persistente Volumes usw., bietet. Dazu verwendet das Modul einen speziellen .ls-Befehl mit einem spezifischen Parameter plugin=.

Das Kubernetes-Modul von Bacula bietet eine Vielzahl von Funktionen, von denen einige sind:

• Schnelles und effizientes Umverteilen von Cluster-Ressourcen;
• Sicherung des Kubernetes-Cluster-Status;
• Speichern von Konfigurationen zur Verwendung in anderen Operationen;
• Möglichst sichere Aufbewahrung geänderter Konfigurationen und Wiederherstellung des exakt gleichen Zustands wie zuvor.

Obwohl dies häufig vorkommt, wird dringend empfohlen, den Anbieter nicht nach dem Datenvolumen zu bezahlen. Es macht keinen Sinn, sich jetzt oder in Zukunft von einem Anbieter erpressen zu lassen, der bereit ist, Ihr Unternehmen auf diese Weise auszunutzen. Schauen Sie sich stattdessen die Lizenzierungsmodelle von Bacula Systems genau an, die ihre Kunden vor Gebühren für das Datenwachstum bewahren und gleichzeitig den Einkaufsabteilungen der Kunden die Vorhersage künftiger Kosten erleichtern. Dieser vernünftige Ansatz von Bacula kommt von seinen Open-Source-Wurzeln und kommt in einer DevOps-Umgebung gut an.

Velero und Bacula Enterprise: Was ist der Unterschied?

Das soll nicht heißen, dass es keine anderen Lösungen auf dem Markt gibt, sowohl kostenpflichtige als auch kostenfreie. Zum Beispiel Velero.

Velero (früher Heptio Ark genannt) ist eine kostenlose Open-Source-Lösung für die Sicherung und Wiederherstellung, die sich hauptsächlich auf die Arbeit mit Kubernetes-Clustern / persistenten Volumes konzentriert. Sie kann über spezielle Plugins mit einer Reihe verschiedener Cloud-Plattformen zusammenarbeiten, und Sie können wählen, ob Sie sie vor Ort oder innerhalb der öffentlichen Cloud-Plattform Ihrer Wahl betreiben möchten.

Die drei Hauptzielbereiche von Veleros Fähigkeiten sind:

• Replikation von Produktionsclustern zu Test- oder Entwicklungszwecken;
• Allgemeine Sicherungs- und Wiederherstellungsfunktionen für Kubernetes-Cluster;
• Cluster-Migrationsfunktion.

Die Idee, wie Velero funktioniert, besteht aus zwei Hauptteilen – einem Server, der innerhalb Ihres Clusters arbeitet, und einem lokalen Client, der durch eine Kommandozeile für Ihre Betriebsanforderungen repräsentiert wird. Es ist auch ziemlich einzigartig in der Art und Weise, wie es mit Kubernetes-Clustern arbeitet, sowie.

Die Funktionsweise besteht darin, dass die Kubernetes-API verwendet wird, um den spezifischen Zustand von Clustern zu erfassen und bei Bedarf den Wiederherstellungsprozess durchzuführen. Dies unterscheidet sich von dem, was die meisten anderen Lösungen tun – sie greifen direkt auf Kubernetes etcd-Datenbanken zu und interagieren über diese mit den betreffenden Daten (Bacula Pods ist ein solches Beispiel). Die Vorteile, alles über eine API zu machen, sind folgende:

• Selbst wenn die Ressourcen, die über die API zugänglich sind, in einer separaten Datenbank gespeichert sind, können sie schnell und effizient gesichert und/oder wiederhergestellt werden;
• Backups können selektiv sein und bestimmte Teilmengen der Ressourcen eines Clusters erfassen, gefiltert nach Ressourcentyp, Namespace usw., was die Flexibilität bei der Auswahl der zu sichernden Daten deutlich erhöht;
• Es kommt nicht selten vor, dass Nutzer von verwalteten Kubernetes-Angeboten keinen Zugriff auf die zugrundeliegende etcd-Datenbank haben, was direkte Backups und Wiederherstellungen im Grunde unmöglich macht und zur Verwendung verschiedener Workarounds zwingt.

Wenn man Velero und Bacula direkt miteinander vergleicht, kann man sagen, dass jede Lösung ihre eigenen Vorteile und Nutzen hat.

Bacula ist eine viel umfassendere Lösung für die Datensicherung und -wiederherstellung in Unternehmen und bietet eine besonders breite Palette an Funktionen und Technologien, die man von einer anspruchsvollen Unternehmenslösung erwarten würde. Daher bietet Bacula eine vollständige Sicherungslösung auf einer einzigen Plattform für mittlere und große Unternehmen. Bacula verfügt auch über „BWeb“, eine umfassende Webschnittstelle für die vielen Funktionen, die es bietet. Bacula ist wahrscheinlich die Lösung, die ein IT-Direktor wählen würde, wenn er oder sie komplexe, sich verändernde IT-Umgebungen mit einer einzigen, modernen Plattform sichern muss.

Velero hingegen ist spezifisch in dem Sinne, dass es nicht versucht, alle Aspekte der Sicherung aller Anwendungen, Daten und Speichertypen abzudecken, sondern sich stattdessen nur auf die Arbeit mit Kubernetes konzentriert. Für manche Benutzer ist das vielleicht attraktiver als eine All-in-One-Lösung. Dann ist da noch der einzigartige Ansatz, den Velero für die Arbeit mit Daten und Backups verfolgt – über eine API. Und nicht zuletzt ist es kostenlos und quelloffen. Trotz all der Vorteile, die Bacula hat, ist es als High-End-Lösung für mittlere und große Unternehmen konzipiert, und das ist natürlich nicht repräsentativ für alle Nutzer von Kubernetes.