Ich kann es nicht glauben, wenn ich im Jahr 2024 höre, wie Plattformbetreiber oft davon reden, dass Kubernetes nur für temporäre Workloads geeignet sei – oder dass keine Datensicherung erforderlich sei, da „alle unsere Apps temporär sind“. In diesem Artikel erläutere ich Hintergrundinformationen dazu, wo sich Zustände in unseren Anwendungen befinden, was der Mythos „Kubernetes = temporär“ eigentlich ist und wie wichtig eine Datensicherung in allen Kubernetes-Umgebungen ist.
Dauerhaft oder temporär – die Grundlagen
„Temporär“ bezieht sich auf einen Workload, für den keine dauerhafte Persistenz erforderlich ist, sodass bei einem Neustart oder einer erneuten Bereitstellung des Workloads alle erfassten Daten oder geänderten Einstellungen verloren gehen. Verglichen mit ihren Vorgängern mit dauerhaften virtuellen Maschinen (VMs) sind Container von Natur aus temporär. Bei einem Neustart eines Containers weiß ein Benutzer, dass der Workload denselben beabsichtigten Workload wie bei der ursprünglichen Erstellung des Container-Images ausführt.
Der Logik folgend werden bei einem dauerhaften Workload Daten so beibehalten, dass bei einem Neustart darauf zugegriffen werden kann. Zu den häufigen dauerhaften Workloads gehören Datenbanken wie PostgreSQL, MySQL oder MongoDB.
Was ist also eine temporäre Anwendung?
Anwendungen bestehen in der Regel aus mehreren Workloads. Selbst monolithische, VM-basierte Anwendungen bestehen in der Regel aus separaten Frontend-, Geschäftslogik- und Datenbank-Workloads. Cloudbasierte, auf Microservices basierende Anwendungen bestehen in der Regel aus viel mehr separaten Workloads mit jeweils eigenen Funktionen – damit Unternehmen neue Features und Services schneller als je zuvor bereitstellen können.
Das bedeutet, dass die meisten temporären Anwendungen nicht vorhanden sind.
Ihre Lieblings-App für Essensbestellungen, eine To-Do-App auf Ihrem Telefon, ein Formular, das Sie ausfüllen, um einen Arzttermin zu vereinbaren – all dies wäre praktisch nutzlos, wenn es nicht einige dauerhafte Workloads gäbe, die für die speichernden kritischen Daten in jedem dieser Anwendungsfälle verantwortlich sind.
Bei Kubernetes ist es wichtig zu wissen, wo sich Ihre Anwendungsdaten oder Ihr Zustand befinden – innerhalb oder außerhalb des Clusters.
Wie sind wir hierher gelangt – Kubernetes = temporär?
Als Docker Anfang bis Mitte der 2010er Jahre zu einer De-facto-Container-Plattform für das Verpacken von Software wurde, war eine Lösung zur Orchestrierung von Containergruppen in großem Maßstab entscheidend, um den vollen operativen Nutzen aus der Umstellung auf Microservices zu ziehen – und Kubernetes stellte eine Lösung bereit. Deklarative Bereitstellungen, Hochverfügbarkeit und automatisierte Skalierung waren erhebliche Vorteile für temporäre Workloads, die problemlos beendet, neu gestartet und geklont werden konnten. Diese Workloads, die häufig mehr Computing für Frontend oder Anwendungsserver bereitstellen, können mit Datenservices außerhalb des Clusters verbunden werden. Die Lösung wurde von vielen als Erfolg gefeiert. Kubernetes war eindeutig eine Lösung für temporäre Workloads, richtig?
Doch in Kubernetes Version 1.0 gibt es neben all diesen großartigen Funktionalitäten für temporäre Workloads auch persistente Volumes – einen Kubernetes-nativen Mechanismus, mit dem persistenter Speicher an ephemeral Pods angefügt werden kann. Ganz klar war die Unterstützung dauerhafter Workloads von Anfang an eine Überlegung, und im Laufe der Zeit wurden einige nennenswerte Verbesserungen vorgenommen:
- Dez 2017 (v1.9) Allgemeine Verfügbarkeit von StatefulSets – Bereitstellen der Persistenz von Pod-Identitätsmerkmalen und geordneten Vorgängen
- Dez 2018 (v1.13) Allgemeine Verfügbarkeit von Container-Storage Interface (CSI) – ein Standard, mit dem Speicherhersteller ihre eigenen Plug-ins für die Speicherung von Kubernetes-Workloads erstellen können
- Mai 2018 Einführung des Operator Framework – ein Software Development Kit (SDK) zur Vereinfachung der Bereitstellung und Verwaltung komplexer Workloads wie Datenbanken in Kubernetes
- Dezember 2020 (v1.20) Allgemeine Verfügbarkeit von Volume-Snapshots innerhalb der CSI-Spezifikation – Bereitstellung einer standardisierten Oberfläche für Storage-Snapshot-Vorgänge in Kubernetes
Diese Verbesserungen, kombiniert mit den Bemühungen vieler verschiedener Anbieter und Projektbeteiligter, haben ein umfangreiches Ökosystem geschaffen, in dem Benutzer frei entscheiden können, welche Datenservices ihren Anwendungszustand bereitstellen und wo diese Workloads ausgeführt werden.
Der Aufstieg von GitOps
In dieser Zeit kam in der Kubernetes-Community eine weitere Idee zur Verbesserung der Container-Orchestrierung auf: GitOps. Das Konzept ist einfach: Versionskontrolle als Quelle der Wahrheit verwenden und alles speichern, was für die Bereitstellung einer Anwendung erforderlich ist, einschließlich Code und Kubernetes-Ressourcen. Jedes Mal, wenn Code in das Repository zusammengeführt wird, um eine Änderung vorzunehmen, aktualisiert ein Controller die Bereitstellung, damit der beschriebene gewünschte Zustand in Git widergespiegelt wird. GitOps-Implementierungen können einen Mechanismus für die Änderungskontrolle bieten, die Möglichkeit, eine ganze Umgebung mit einem einzigen Klick neu bereitzustellen, und eine Möglichkeit, fehlerhafte Änderungen rückgängig zu machen – manchmal.
Nur weil Kubernetes dauerhafte Workloads ausführen kann, sollten Sie das also auch tun?
Bei der Erstellung einer Anwendung für einen Machbarkeitsnachweis entscheiden sich Entwickler häufig für eine in der Cloud gehostete, verwaltete Datenbank (DBaaS), um ihre persistenten Daten außerhalb des Kubernetes-Clusters zu hosten. DBaaS-Lösungen bieten entwicklerfreundliche APIs und eine schnelle Wertschöpfung für Benutzer, unabhängig von ihrer Erfahrung in der Datenbankverwaltung. Doch wie so oft: das Einfachste ist nicht immer das Beste. Betrachten wir die Gründe, die es bei der Ausführung dauerhafter Workloads innerhalb oder außerhalb des Clusters zu berücksichtigen gilt:
- Latenz – wenn Sie Datenservices zusammen mit anderen containerbasierten Workloads bereitstellen, können Sie eine Verbindung mit geringer Latenz sicherstellen mit Ihren Daten herstellen und eine konsistente Benutzererfahrung bereitstellen.
- Mobilität – Kubernetes bietet eine starke Abstraktionsebene, mit der Sie Workloads zwischen verschiedenen Clouds verschieben können. Dies ermöglicht es Unternehmen, Datenhoheit zu erfüllen oder einfach von besseren Preiskonditionen zu profitieren. Sind Ihre Datenservices jedoch an eine cloudspezifische DBaaS gebunden, wird die Migration zwischen Umgebungen deutlich komplizierter. Automatisierungen und Richtlinien, die für eine DBaaS erstellt wurden, müssen für die entsprechende verwaltete Datenbank in Ihrer Zielcloud neu erstellt werden, vorausgesetzt, sie ist vorhanden und erfüllt die Anforderungen. Für eine erneute Bereitstellung Ihrer Kubernetes-Workloads aus Ihren externen Datenservices sind separate Tools und Prozesse erforderlich.
- Verwaltung kopierter Daten – Ihre Entwickler müssen Ihre Anwendung mit aktuellen und relevanten Daten testen, was separate Prozesse zum Verwalten und Verbinden dieser Datendienste erfordert, wenn sie außerhalb des Clusters ausgeführt wird. Als Teil einer vollständig deklarativen Lösung, die sowohl temporäre als auch dauerhafte Workloads innerhalb des Clusters ausführt, könnten Benutzer vollständige Anwendungsbackups einfach als Klone mithilfe einer Kubernetes-nativen Schnittstelle wie „kubectl“ wiederherstellen.
- Polyglot Persistence – dies eine ausgefallene Art Folgendes zu sagen: „Der richtige Datendienst für den richtigen Anwendungsfall“. Da herkömmliche Anwendungen mithilfe einer Microservices-Architektur neu erstellt werden, haben Entwickler auf Kubernetes die Wahl und können den idealen Datenservice für jede Anforderung implementieren. Die Operatoren vereinfachen die Bereitstellung und das fortlaufende Verwalten. Unternehmen, die Datenservices außerhalb von Kubernetes betreiben, sind möglicherweise nicht in der Lage, die komplexen betrieblichen Anforderungen zu erfüllen, um die ideale Datendienstauswahl der Entwickler zu unterstützen.
- Kosten – mit DBaaS-Lösungen bezahlen Sie für Bequemlichkeit. Partner wie EnterpriseDB haben jedoch gezeigt, dass das Hosting eigener Datenservices auf Kubernetes zu geringeren Gesamtbetriebskosten (TCO) führt, ohne dass die Benutzerfreundlichkeit wesentlich beeinträchtigt werden muss.
Die Anpassung der Laufzeit von temporären und dauerhaften Workloads in Kubernetes kann die Flexibilität hinsichtlich der Anwendungsausführung erhöhen. Es kann auch zusätzlichen Self-Service für DevOps bieten, Kosten senken und Tools und Prozesse rationalisieren. Dadurch ist es möglich, die GitOps-Methodik auf alle Teile einer Anwendung anzuwenden. Es ist daher keine Überraschung, dass Datenbanken laut dem jüngsten Datadog-Report zur realen Container-Nutzung weiterhin die beliebteste Kategorie containerisierter Workloads sind.
So schützen Sie Ihre Kubernetes-Daten
Die dauerhafte Seite
Wenn Sie bereits davon überzeugt sind, dass dauerhafte Workloads auf Kubernetes der richtige Weg in die Zukunft sind, wissen Sie wahrscheinlich, dass für die Sicherung und Disaster Recovery dieser Anwendungen ein spezielles Tool erforderlich ist. Jede Anwendung besteht aus vielen verschiedenen Kubernetes-Ressourcen (ConfigMaps, Secrets, Deployments usw.) sowie persistenten Volume-Daten. Darüber hinaus müssen all diese Daten ordnungsgemäß erkannt, per Snapshot erstellt und an einen sicheren Ort außerhalb des Clusters exportiert werden.
Hier kommt Veeam Kasten for Kubernetes ins Spiel, eine Kubernetes-native Lösung für Datensicherung und Anwendungsmobilität. Kasten bietet Unternehmen eine benutzerfreundliche, skalierbare und sichere Möglichkeit zur Erstellung unveränderlicher Backups und zur schnellen und zuverlässigen Wiederherstellung ganzer Anwendungen.
Kasten bietet eine deklarative, Kubernetes-native API zum Definieren von Richtlinien, Ausführen von Aktionen und mehr, sodass die Datensicherung eng in jede GitOps-Implementierung integriert werden kann. Das gilt für eine Vielzahl von Anwendungsfällen, von der Bereitstellung und Konfiguration von Kasten in einem neuen Cluster bis hin zur Erweiterung von GitOps durch Automatisierung von Backups vor dem Rollout von Code-Updates. GitOps selbst bietet die Möglichkeit, Konfigurationsänderungen auf eine Kubernetes-Ressource zurückzusetzen. Sollten durch eine dieser fehlerhaften Änderungen jedoch die Daten eines persistenten Volumes beeinträchtigt werden (z. B. durch eine falsche Schemaänderung oder das Löschen einer Tabelle), benötigen Sie ein aktuelles Backup, das schnell wiederhergestellt werden kann.
Die temporäre Seite
Sie möchten Ihre bevorzugte DBaaS-Datenbank noch nicht gegen eine neue in Kubernetes gehostete und vom Betreiber verwaltete Datenbank eintauschen? Kasten hält Ihnen immer noch den Rücken frei. Betrachten wir, warum die Datensicherung auf Kubernetes nach wie vor so wichtig ist:
- Der Zustand muss irgendwo vorhanden sein – unabhängig vom Speicherort der Daten außerhalb des Clusters, ist es nach wie vor wichtig, Bereitstellungen von Anwendungen zu einem bestimmten Zeitpunkt reproduzieren zu können, in der Regel aus DR- oder Compliance-Gründen. Im Kern handelt es sich bei Kasten um eine Orchestrierungs-Engine, die speziell für die Datensicherung entwickelt wurde. Die Blueprint-Funktionalitäten von Kasten ermöglichen robuste Kontrollen zum Stilllegen von Datenservices im Cluster, aber auch zur Orchestrierung von Snapshots und Backups externer Datenservices. Dies kann die Orchestrierung logischer Dumps einer Datenbank oder die direkte Integration in DBaaS-APIs umfassen.
- GitOps ist nicht narrensicher – viele Administratoren und Techniker haben in irgendeiner Form die Erfahrung eines „Tests in der Produktionsumgebung“ gemacht. Dies bedeutet, dass Änderungen an einer Produktionsinstanz für <insert important reason here> vorgenommen wurden, die den akzeptierten Änderungsverwaltungsprozess umgangen haben. Somit ist der Cluster selbst zur Laufzeit die einzige Quelle der Wahrheit bezüglich der bereitgestellten Objekte. Durch regelmäßige Backups der Manifeste, die bei der Bereitstellung zu jeder Anwendung gehören, wird sichergestellt, dass alle diese Diskrepanzen erfasst werden, sodass die Originalumgebung originalgetreu reproduziert werden kann, um DR und/oder behördliche Vorgaben zu unterstützen.
- Schutz von Container-Images – Kasten lässt sich in viele der erweiterten Funktionalitäten von Red Hat OpenShift integrieren, einschließlich der Unterstützung für den Schutz und die Wiederherstellung von ImageStream-Container-Images. Image Streams bieten im Vergleich zu Upstream-Kubernetes eine Fülle von Funktionen zum Erstellen und Bereitstellen von Container-Images. ImageStream-Container-Images sind Quellen eines Clusterzustands, die potenziell übersehen werden. Diese Images werden standardmäßig per Push an die interne Container-Registry des Clusters übertragen. Die Neuerstellung aus der Quelle bietet keine Garantie dafür, dass die resultierenden Images identisch sind. Auch hier sind zuverlässige Backups erforderlich, um eine Umgebung vollständig reproduzieren oder nach einem Cluster-Verlust wiederherstellen zu können.
- Virtuelle Maschinen in Kubernetes : Dank des KubeVirt-Projekts und seiner Mitwirkenden ist es nun möglich, VMs parallel zu containerisierten Workloads in Kubernetes auszuführen. Dadurch können Unternehmen ihre Tools und Prozesse rund um Kubernetes optimieren und gleichzeitig einen einfachen Einstieg für Workloads bereitstellen, die bisher noch nicht vollständig in cloudbasierte Apps umgewandelt wurden oder bei denen dies nicht vorgesehen ist. Auch unter Kubernetes sind VMs dauerhaft, lassen sich aber nicht mit herkömmlichen VM-Backup-Tools sichern. Kasten V7.0 bietet erstklassige Unterstützung für die Sicherung und Wiederherstellung von VMs in Kubernetes mit OpenShift Virtualization.
Team Kubernetes-Datensicherung
Kubernetes unterstützt inzwischen alle Arten von Workloads – ungeachtet der hartnäckigen Überzeugung, Kubernetes sei nur für temporären Workloads geeignet. Da Unternehmen versuchen, den größtmöglichen Nutzen aus ihren cloudbasierten Investitionen zu ziehen, ist ein anhaltender Trend hin zur Ausführung dauerhafter Workloads unumgänglich. Höhere Leistung und Mobilität, vereinfachtes Copy-Data-Management, Polyglot Persistence und Kosteneinsparungen sind alles Vorteile, die nur darauf warten, realisiert zu werden.
Ob Sie dauerhafte oder temporäre Workloads ausführen – die Datensicherung bleibt von entscheidender Bedeutung. Veeam Kasten for Kubernetes ist eine Kubernetes-native Lösung für die Sicherung von Anwendungen und Daten, Disaster Recovery, Anwendungsmobilität und Schutz vor Ransomware. Darüber hinaus können GitOps-Methoden verbessert werden, indem die Datensicherung in die Anwendungsbereitstellung integriert wird. Schließlich kann die Einführung von dauerhaften Workloads auf Kubernetes nicht nur Umsatzchancen eröffnen, sondern Unternehmen auch mehr Flexibilität, Self-Service, Kosteneffizienz und optimierte Abläufe bringen.
Testen Sie unsere Veeam Kasten Free-Lösung oder unsere Enterprise-Testversion , um jetzt zu starten.