Warum der Begriff „Selbstheilung“ in Kubernetes nicht ganz zutreffend ist
Kubernetes wird häufig dafür gelobt, eine Plattform mit Selbstheilung zu sein. Pods starten selbstständig neu, Arbeitslasten werden automatisch verlegt und der Cluster kompensiert kleinere Ausfälle ohne großes Theater. Doch in dem Moment, in dem Sie unternehmenskritische Anwendungen ausführen, die unbedingt online bleiben müssen – kundengerichtete Systeme, transaktionale Arbeitslasten, interne Dienste, die nicht ausfallen dürfen –, wird „Selbstheilung“ vom netten Extra zur absoluten Notwendigkeit. Wenn bereits wenige Minuten Ausfallzeit dramatische Folgen haben können, müssen die Teams irgendwann feststellen, dass die Hochverfügbarkeit in Kubernetes nicht so automatisch ist, wie sie angepriesen wird.
Die versteckte Lücke in der Hochverfügbarkeit: Pod-Wiederherstellung vs. Datenverfügbarkeit bei zustandsbehafteten Anwendungen
Hochverfügbarkeit läuft in Kubernetes auf zwei Ebenen: auf der Steuerungsebene und in den Anwendungen selbst. Eine resiliente Steuerungsebene gewährleistet die Funktionsfähigkeit des Clusters selbst beim Ausfall von Knoten, sodass Kubernetes Entscheidungen treffen und Arbeitslasten bei Bedarf verschieben kann. Vor allem bei zustandslosen Anwendungen gelingt es Kubernetes ausgezeichnet, mit Replikaten zu arbeiten, die es bei Ausfällen neu startet. Das ist jedoch nur die halbe Miete. Bei zustandsbehafteten Anwendungen – die auf konsistente Daten angewiesen sind – verläuft die Wiederherstellung keineswegs so reibungslos. Kubernetes ist immer in der Lage, einen Pod neu zu starten, kann jedoch nicht garantieren, dass der letzte Zustand dieses Pods nach einem Ausfall sofort wieder zur Verfügung steht.
Das ist der Punkt, an dem die meisten Teams die wahre Herausforderung in puncto Hochverfügbarkeit erleben. Wenn ein Knoten plötzlich ausfällt, bringt Kubernetes den Pod schnell auf einem anderen Knoten wieder ans Laufen. Dieser Teil funktioniert hervorragend. Das Problem dabei: Was geschieht mit den Daten, die gerade von der Anwendung genutzt wurden, als es zum Ausfall kam? Ist nicht anderswo Speicher verfügbar oder wurden die Daten noch nicht über die Knoten hinweg synchronisiert, ist die neu gestartete Anwendung nicht wirklich wiederhergestellt – sie läuft lediglich zustandslos. Diese Diskrepanz zwischen Failover der Arbeitslast und Datenbereitschaft macht vielen Clustern zu schaffen. Sie ist auch der Grund dafür, dass Unternehmen sich nach solideren Möglichkeiten zur Sicherung der Verfügbarkeit ihrer Anwendungen und Daten umsehen, für den Fall, dass Kubernetes-Knoten ausfallen.
DataCore Puls8: Hochverfügbarkeit für zustandsbehaftete Kubernetes-Arbeitslasten
Die Lücke zwischen Pod-Wiederherstellung und Datenverfügbarkeit schließen
Für den Lückenschluss zwischen Pod-Wiederherstellung und Datenverfügbarkeit bietet DataCore Puls8 einen einheitlichen Ansatz zur Sicherstellung der Hochverfügbarkeit zustandsbehafteter Anwendungen. Anstatt sich auf fragmentierte Tools zu verlassen, synchronisiert Puls8 die Anwendungsdaten knotenübergreifend in Echtzeit und gewährleistet, dass Arbeitslasten an einem beliebigen Ort im Cluster im vollständigen, konsistenten Zustand neu starten und ausgeführt werden können. Anstatt Speicher und Failover getrennt zu betrachten, pflegt Puls8 eine aktive, gespiegelte Kopie der Anwendungsdaten über alle Knoten hinweg und stellt sicher, dass ein Neustart der Arbeitslasten überall im Cluster im vollständig intakten Zustand erfolgen kann.
Synchrone Spiegelung für sofortige Verfügbarkeit des neuesten Stands
Mit Puls8 läuft jeder Schreibvorgang parallel auf mehreren Knoten, sodass die Anwendungsdaten jederzeit und überall auf dem neuesten Stand und konsistent sind. So wird der Cluster auf Störungen vorbereitet: Ist ein Knoten nicht mehr erreichbar, besteht das Risiko nicht darin, dass Kubernetes den Pod vielleicht nicht neu starten kann, sondern dass die Arbeitslast nicht in ihrem jüngsten Zustand neu startet. Dieses Risiko beseitigt Puls8 vollständig, indem es eine einsatzfertige, synchronisierte Kopie der Daten auf einem anderen Knoten verfügbar hält, bevor ein Failover ausgeführt wird.
Wie die Architektur deterministische Konsistenz gewährleistet
Aus technischer Sicht nutzt Puls8 eine Architektur auf der Grundlage gespiegelter Datenträger auf Blockebene mit einem CSI-Treiber. Replikationsbestätigungen erfolgen erst dann, wenn beide Knoten den Schreibvorgang abgeschlossen haben. So ist die deterministische Konsistenz auch bei hohen, explosionsartigen oder transaktionalen Arbeitslasten gewährleistet. Diese Vorgehensweise verhindert Datendrift, asynchrone Lücken und Wiederherstellungsverzögerungen, die bei der Verwendung herkömmlicher replizierter Speicher in Kubernetes-Umgebungen häufig auftreten.
Sofortige Volumenverfügbarkeit und automatisierte Replikatverwaltung
Geht ein Knoten offline, zieht Puls8 automatisch den gespiegelten sekundären Datenträger heran. Puls8 kann nach einem Ausfall auch automatisch die gewünschte Anzahl von Volume-Instanzen (Replikaten) wiederherstellen und veraltete Kopien entfernen, sobald sich der Cluster stabilisiert hat.
Failover für garantierte Kontinuität
Kubernetes verlegt den Pod und stellt das vollständig synchronisierte Replikat bereit. Die Anwendung kann genau an dem Punkt neu starten, an dem sie aufgehört hat, ohne Wiederaufbau, Resynchronisation, Datenverlust oder langsames Wiederanheften. Das Failover erfolgt automatisch, transparent und schnell, sodass zustandsbehaftete Dienste sich so geschmeidig wie zustandslose verhalten, mit vollständig erhaltener Datenintegrität.
Wie Puls8 in der Praxis mit einem Knotenausfall umgeht
In diesem Beispiel sehen wir eine WordPress-Anwendung, die unter normalen Betriebsbedingungen auf Knoten 1 ausgeführt wird. Der Pod ist „gesund“ und dient planmäßig als Server für den Datenverkehr.
Der Cluster besteht aus drei Knoten (Knoten 0, Knoten 1 und Knoten 2) und liefert Kubernetes und Puls8 die Umgebung, die für die zuverlässige Ausführung der zustandsbehafteten Arbeitslast erforderlich ist. Puls8 repliziert kontinuierlich die Daten der Anwendung im Hintergrund, sodass der letzte Zustand immer auf einem weiteren Knoten bereitgehalten wird.
Auf dem folgenden Bild sehen wir, dass die Replikation für alle drei Knoten konfiguriert ist.
Auf dem nächsten Bild werden alle drei Knoten in einem fehlerfreien, synchronisierten Datenzustand angezeigt.
Hier sehen wir, dass Knoten 1 unerwartet offline geht. Ab diesem Punkt ist die Arbeitslast auf dem Knoten nicht länger verfügbar und Kubernetes muss den Pod verlegen, damit die Anwendung weiterlaufen kann.
Die WordPress-Anwendung wird auf Knoten 2 verlegt. Da Puls8 die Daten zuvor laufend repliziert hat, kann der Pod die Anwendung auf dem neuen Knoten sofort im korrekten, aktuellen Zustand starten.
Die Anwendung ist intakt und läuft jetzt normal auf Knoten 2. Mit kontinuierlicher Replikation und nahtlosem Failover sorgt Puls8 dafür, dass die zustandsbehaftete Arbeitslast ohne Ausfallzeit oder Störung weiterläuft.
Fazit: Die Grundlage für Hochverfügbarkeit in Kubernetes
Hochverfügbarkeit in Kubernetes basiert ultimativ auf der Sicherheit, dass Arbeitslasten online und Daten intakt bleiben und Störungen keine Ausfallzeit nach sich ziehen. Durch die Kombination aus synchronisierter Datenreplikation und nahtlosem, automatisiertem Failover der Anwendungen bewirkt DataCore Puls8 für zustandsbehaftete Anwendungen den gleichen Grad an Resilienz und Vorhersehbarkeit, den zustandslose Anwendungen genießen. Puls8 ist die Grundlage für Systeme, in denen Kontinuität bei Störungen nicht dem Zufall überlassen werden darf, sondern unabdingbar ist.
Darum bezeichnen wir diese Funktion als „Rettungsleine“. In dem Moment, in dem ein Knoten verschwindet, sorgt die Rettungsleine dafür, dass mit der Anwendung nicht das Gleiche passiert. Sie bewahrt den Zustand, erhält die Konsistenz und lässt den Dienst ohne Verzögerung weiterlaufen: als ein Sicherheitsnetz, auf das jede unternehmenskritische Arbeitslast angewiesen ist. Wenn Sie wissen möchten, wie Puls8 Hochverfügbarkeit in Kubernetes bewirkt, fordern Sie eine Demo bei DataCore an und erleben Sie den Unterschied selbst.
KONTAKTIEREN SIE UNS FÜR EINE DEMO VON PULS8
