Als Kubernetes erstmals die Bühne betrat, basierte es auf einer ebenso schlichten wie genialen Idee: Anwendungen sollten als zustandslos behandelt werden. Fiel ein Container aus, startete Kubernetes einfach irgendwo im Cluster einen neuen, und das Leben ging weiter. Bei Mikrodiensten, die sich von einer Anfrage zur nächsten an nichts „erinnern“ mussten, funktionierte das hervorragend.
Bis dieses schöne Gefüge von der Realität eingeholt wurde. Die Geschäftswelt basiert auf Daten: Bestellverläufe, Nutzerprofile, Finanztransaktionen, Produktbestände, Protokolle, Auswertungen … Diese Arbeitslasten sind nicht zustandslos; sie sind darauf angewiesen, dass im Laufe der Zeit immer wieder auf dieselben Daten zugegriffen werden kann. Plötzlich hatte Kubernetes es mit Anwendungen zu tun, bei denen „einfach neu starten“ den Verlust riesiger Mengen an kritischen Daten bedeuten konnte.
Hier kam persistenter Speicher ins Spiel. Ohne persistenten Speicher ist die Verarbeitung zustandsbehafteter Arbeitslasten auf Kubernetes wie das Anlegen einer Datenbank auf einer Festplatte aus Eis. Man kann darauf unzählige Schreibvorgänge ausführen, aber in dem Moment, in dem sich die Temperatur ändert, geht alles den Bach runter.
Zustandslose oder zustandsbehaftete Arbeitslasten: ein Unterschied, der alles verändert
Am einfachsten lässt sich die Notwendigkeit persistenten Speichers verstehen, wenn man sich den Unterschied zwischen zustandslosen und zustandsbehafteten Arbeitslasten in Kubernetes vor Augen führt.
Ein zustandsloser Dienst ist wie ein Mitarbeiter einer Mautstelle, der keine Aufzeichnungen führt. Die Autos passieren die Stelle, er kassiert die Gebühr, damit ist der Job erledigt. Geht der Mitarbeiter nach Hause und seine Ablösung übernimmt seinen Dienst, geht kein Verlauf verloren. In Kubernetes-Begriffen ausgedrückt wäre das beispielsweise eine HTTP API für Produktlisten, ein PDF-Renderdienst oder ein einfacher Ereignisprozessor.
Zustandsbehaftete Arbeitslasten könnte man hingegen eher mit einem Bankmitarbeiter vergleichen. Jede Transaktion muss aufgezeichnet und gespeichert werden und später noch zugänglich sein. Geht der Mitarbeiter nach Hause und nimmt die Aufzeichnungen mit, bricht der Geschäftsbetrieb der Bank zusammen. In Kubernetes wären das Ihre MySQL-Datenbank, Ihre Kafka-Broker, Ihr Elasticsearch-Cluster oder sogar Redis im Persistenzmodus.
Der Grund für den Unterschied liegt im Lebenszyklus der Kubernetes-Pods: Die Pods sind flüchtig. Sie sind nicht an eine bestimmte Hardware gebunden und können jederzeit gelöscht oder verschoben werden. Das ist ein großer Vorteil für die Skalierung und die Resilienz, aber ein eklatanter Nachteil für alles, was darauf angewiesen ist, dass lokale Daten morgen auch noch da sind.
Das Problem mit dem flüchtigen Speicher
Jeder Pod in Kubernetes hat einen integrierten Speicher, der allerdings flüchtig ist – er existiert nur so lange, wie der Pod existiert. Fällt der Pod aus, sei es, weil Sie ein Update aufspielen oder weil der Knoten, auf dem er läuft, abstürzt, wird der Speicher gelöscht.
In Kubernetes kann man Datenträger wie emptyDir als temporären Speicher nutzen. Sie sind perfekt für Caches, temporäre Dateien oder kurzfristige Rechenvorgänge. Sie sind allerdings auf den Lebenszyklus des Pods beschränkt. Das bedeutet, wenn der PostgreSQL-Pod emptyDir zur Speicherung seiner Datenbankdateien verwendet, ist das so, als würden Sie diese direkt in /tmp speichern – gibt es den Pod nicht mehr, sind Ihre Daten ebenfalls weg.
Diese flüchtige Art macht auch die Wiederherstellung schwierig. Man stelle sich einen ausgefallenen Kafka-Broker-Pod vor. Ohne persistenten Speicher beginnt Kubernetes bei jeder Erstellung eines neuen Brokers wieder bei null. Die Offsets der Nachrichten sind weg, die Partitionsreplikate sind weg und der Cluster muss den Zustand anhand anderer Replikate wieder aufbauen – sofern es diese überhaupt gibt.
Persistenter Speicher: Entkopplung der Daten von der Rechenkapazität
Die zentrale Idee hinter persistentem Speicher in Kubernetes ist die Entkopplung der Daten vom Pod. Die Rechenressourcen (die Pods) können kommen und gehen, aber die von ihnen verwendeten Daten werden unabhängig davon in einem Speichersystem gespeichert, das Kubernetes bei Bedarf wieder ankoppeln kann.
Mit diesem Modell können Sie:
- Serverausfälle ohne Datenverlust überstehen;
- rollierende Updates durchführen, ohne den Zustand der Anwendung zu löschen;
- zustandsbehaftete Arbeitslasten auf Knoten ohne manuelle Intervention skalieren;
- ein einheitliches Verhalten der Anwendung auch bei Verschiebungen sicherstellen.
Aus Implementierungssicht gibt Kubernetes uns PersistentVolumes (PVs) und PersistentVolumeClaims (PVCs).
- Ein PV ist die tatsächliche Speicherressource, z. B. ein AWS EBS-Datenträger, Azure Managed Disk, Google Persistent Disk, NFS-Speicher oder Ceph RBD-Blockspeicher.
- Ein PVC ist der „Vertrag“ zwischen Ihrer Anwendung und diesem Speicher. Anstatt die Speicherdetails in der Anwendungskonfiguration fest zu programmieren, geben Sie an: „Ich brauche 20 GiB an ReadWriteOnce Storage“. Kubernetes überlegt dann, wie die Bereitstellung erfolgen kann und der Speicher basierend auf den verfügbaren Speicherklassen angekoppelt werden soll.
StatefulSets: Mehr als Speicher
Während PersistentVolumes das Speicherproblem lösen, liefern sie nicht alles, was zustandsbehaftete Arbeitslasten benötigen. Viele zustandsbehaftete Anwendungen brauchen stabile Netzwerkidentitäten und geordnete Sequenzen zum Starten und Herunterfahren.
Stellen Sie sich einen Datenbank-Cluster mit Leader-/Follower-Knoten vor. Sie können nicht einfach alle Pods nach dem Zufallsprinzip gleichzeitig starten und hoffen, dass sich alles schon selbst regeln wird. Manche Knoten müssen vor anderen starten und denselben Namen behalten, um von anderen gefunden zu werden.
Zu diesem Zweck hat Kubernetes StatefulSets eingeführt. Im Gegensatz zu Deployments, die die Pods wie austauschbares Nutzvieh behandeln, behandeln StatefulSets die Pods mehr wie Haustiere, denen sie Namen geben. Die Pod-Namen sind fest (app-0, app-1, etc.) und die zugehörigen PVCs sind direkt mit diesen Namen verbunden.
Das heißt: Falls mysql-0 ausfällt, wird Kubernetes ihn als mysql-0 neu erstellen und derselbe PVC ist immer noch daran gekoppelt, unabhängig davon, auf welchem Knoten er landet. Die Anwendung kann den Betrieb wieder aufnehmen, ohne ihre Daten aus dem Blick zu verlieren.
Praxisbezogene Herausforderungen des persistenten Speichers in Kubernetes
Selbst mit PVs, PVCs und StatefulSets funktioniert der Speicher in Kubernetes nicht in jedem Szenario nach dem „Plug & Play“-Prinzip.
- Performance-Optimierung: Manche Workloads sind höchst empfindlich gegenüber I/O-Latenz. Mit der falschen Speicherklasse oder dem falschen Backend schaffen Sie möglicherweise einen Engpass für das gesamte System.
- Zonenübergreifende Verfügbarkeit: Viele Blockspeichersysteme sind an eine einzelne Verfügbarkeitszone gebunden, was hochverfügbare Deployments erschwert.
- Backup und Notfallwiederherstellung: Persistente Speicher sind nicht das Gleiche wie Backups. Wenn der zugrunde liegende Speicher ausfällt oder gelöscht wird, braucht man weiterhin Wiederherstellungsmechanismen wie Snapshots oder Replikation.
- Multi-Writer-Komplexität: Arbeitslasten, die ReadWriteMany-Zugriff benötigen, müssen sorgfältig koordiniert werden, um Beschädigungen zu vermeiden. Sie verwenden häufig gemeinsam genutzte Dateisysteme oder verteilte Speicher.
Und es gibt einen tieferen Grund, warum sich das alles so schwierig anfühlt: Die meisten herkömmlichen externen Speicher sind nicht Kubernetes-nativ. Da sie außerhalb der Kubernetes-Steuerungsebene mit eigenem Scheduler, eigenen Ausfalldomänen und eigenem Datendienstmodell angesiedelt sind, kann Kubernetes das An- und Abkoppeln, Failover oder Richtlinien nicht auf natürliche Weise koordinieren, sodass Umplanungen anfällig werden und sich der Betrieb wie ein Fremdkörper anfühlt.
Container-nativer Speicher: Die moderne Antwort
Persistenter Speicher in Kubernetes bedeutet nicht einfach, eine Festplatte zu haben, die einen Neustart der Pods überlebt. Es geht darum, einen Speicher zu haben, der die Sprache von Kubernetes versteht und spricht. Traditionelle Speichersysteme wurden bereits entwickelt, lange bevor Container gängige Praxis wurden. Sie behandeln Kubernetes häufig nur als einen Client von vielen und heften sich von außen an den Cluster. Theoretisch funktioniert das zwar, praktisch führt das allerdings zu Reibungen, beispielsweise durch manuelle Bereitstellung, komplexe Integration, nicht übereinstimmende Skalierungsmuster und schlechte Automatisierung.
Container-Native Storage (CNS) dreht dieses Modell um. Anstatt als externes System zu fungieren, mit dem Kubernetes kommunizieren muss, wird CNS als Mikrodienste-Satz im Innern von Kubernetes eingesetzt, genau wie die Anwendungen. Die Speicherebene wird damit zum Bewohner derselben Umgebung – und mit denselben Kubernetes Primitives organisiert, skaliert und verwaltet wie alles andere.
Das macht für persistenten Speicher einen großen Unterschied aus, denn es löst die zwei großen Herausforderungen, um die es in diesem Blog geht:
- Dass die Daten länger leben müssen als der Pod, und zwar auf eine Weise, die bei einem Failover zuverlässig und vorhersehbar ist.
- Dass der persistente Speicher so dynamisch und automatisiert wie der Rest von Kubernetes sein muss, damit man zustandsbehaftete Arbeitslasten nicht wie zarte Schneeflöckchen behandeln muss.
Mit CNS werden persistente Datenträger nicht manuell von einem Speicheradministrator im Voraus bereitgestellt; sie werden dynamisch erstellt, sobald ein PersistentVolumeClaim vorliegt. In dem Moment, in dem die Anwendung 50 GiB an ReadWriteOnce-Speicher anfordert, stellt die CNS-Ebene automatisch einen Datenträger bereit, integriert ihn in das PersistentVolume-Subsystem von Kubernetes und koppelt ihn an die betreffende Arbeitslast.
Weil der CNS im Cluster verteilt ist, gilt:
- Daten können knotenweit repliziert werden, um Hochverfügbarkeit sicherzustellen, damit der Ausfall eines Knotens nicht den Ausfall des Speichers bedeutet.
- Das Failover ist nativ. Wird ein Pod auf einen anderen Knoten verschoben, kommt der Speicher automatisch mit (oder ein identisches Replikat befindet sich bereits dort).
- Die Speicher-Performance skaliert gemeinsam mit dem Cluster. Wenn Sie Knoten hinzufügen, erhalten Sie nicht nur mehr Rechenkapazität, sondern auch mehr Speicherkapazität und mehr Durchsatz.
- Speicherdienste wie Snapshots, Thin Provisioning usw. sind in dieselbe Umgebung eingebaut und benötigen keine externen Verwaltungswerkzeuge.
Anders ausgedrückt: CNS liefert Kubernetes nicht nur persistenten Speicher, sondern dieser persistente Speicher ist sogar Kubernetes-nativ. Die persistente Speicherebene hinkt der Rechenebene in puncto Automatisierung, Resilienz und Skalierung nicht länger hinterher. So ist es endlich möglich, zustandsbehaftete Arbeitslasten mit der gleichen betrieblichen Sicherheit zu verarbeiten wie zustandslose.
So kann DataCore helfen
Bei der Wahl und dem Betrieb der passenden persistenten Speicherstrategie in Kubernetes geht es nicht nur um die Wahl einer Technologie. Es geht darum, diese Technologie an das Performance-Profil, den Verfügbarkeitsbedarf und die Wachstumspläne Ihrer Anwendung anzupassen. Hier kann DataCore den entscheidenden Unterschied bewirken.
DataCore ist Experte für softwaredefinierte, Container-native Speicherlösungen, die sich nahtlos in Kubernetes integrieren lassen. Durch die Kombination aus Speicherdiensten der Enterprise-Klasse – wie Hochverfügbarkeit, Replikation, Snapshots und Backups – mit einem Kubernetes-nativen Betriebsmodell hilft DataCore Unternehmen dabei, selbst anspruchsvollste zustandsbehaftete Arbeitslasten sicher zu verarbeiten.
Ob Sie vorhandene Anwendungen modernisieren, Cloud-native Datenbanken einsetzen oder von Grund auf neue zustandsbehaftete Dienste aufbauen: DataCore bietet Ihnen die Tools, Leitlinien für die Architektur und operativen Support, damit Ihre Speicherebene ebenso agil, resilient und automatisiert ist wie Kubernetes selbst. Das Ergebnis: eine Plattform, auf der sowohl zustandslose als auch zustandsbehaftete Arbeitslasten Seite an Seite funktionieren können, ohne dass Sie Kompromisse eingehen müssen.
Sind Sie bereit, Ihren persistenten Speicher für Kubernetes produktionsreif zu machen? Kontaktieren Sie uns, um zu besprechen, wie DataCore Ihnen bei der Verarbeitung zustandsbehafteter Arbeitslasten helfen und höchste Zuverlässigkeit und Performance sicherstellen kann.
