Grundlegendes zur Zustandsverwaltung in Kubernetes
Wenn man über Anwendungen im Allgemeinen spricht, hört man oft vom Anwendungszustand. In dieser Lerneinheit überprüfen wir die Definition des Zustands und die verschiedenen Arten von Zuständen, damit Sie Ihre Anwendung besser auf deren Handhabung vorbereiten können.
Zustand
Beim Zustand einer Anwendung handelt es sich um alle Inhalte, die zum Zeitpunkt der Anwendungsausführung im Arbeitsspeicher gespeichert sind. Der Zustand kann verschiedene Dinge umfassen, aber wir konzentrieren uns hauptsächlich auf die Benutzerdaten.
Stellen Sie sich zum Beispiel vor, dass Sie an Ihrem Computer sitzen und den Musikplayer geöffnet haben. Diese Anwendung hat einen Zustand: Sie weiß, wer Sie sind, welche Musik Sie gern hören und welche Lieder Sie auf Ihren Computer heruntergeladen haben. Alle diese Informationen sind Teil des Anwendungszustands.
Der In-Memory-Zustand besteht aus den Informationen, nach denen von der Anwendung nicht erst an anderer Stelle gesucht werden muss. Der Datenträgerzustand besteht aus den Informationen, die der Anwendung noch nicht vorliegen, die also aus einer anderen Datenquelle abgerufen werden müssen.
Arten von Zuständen
Es gibt zwei Arten von Anwendungszuständen. Die erste Art ist der flüchtige Zustand, der nicht beständig ist und verschwindet, sobald die Anwendung geschlossen wird.
Container haben einen kurzlebigen Zustand. Alle darin gespeicherten Daten gehen sofort verloren, wenn der Container gelöscht wird. Einige Anwendungen können damit gut arbeiten, da sie den Zustand aus anderen Quellen wiederherstellen können und ihn nicht lokal speichern müssen. Diese Anwendungen werden zustandslose (stateless) Anwendungen genannt.
Im Gegensatz dazu wird der gesamte Zustand, der nicht flüchtig ist, als persistenter Zustand bezeichnet. Der persistente Zustand ist nach dem Lebenszyklus eines Containers weiterhin vorhanden. Die meisten Containertechnologien, die wir verwenden, weisen das Konzept der Volumes auf, einem datenträgerinternen Speicherort, in dem der Zustand existiert. Der Zustand bleibt an einem sicheren Ort gespeichert und kann wiederverwendet werden, selbst wenn Sie den Container entfernen und wieder in Betrieb nehmen.
Anwendungen, deren Zustand extern abgerufen werden muss, heißen zustandsbehaftete (stateful) Anwendungen.
Zustände und Kubernetes
Kubernetes kann sowohl zustandslose wie auch zustandsbehaftete Anwendungen verarbeiten. Zustandslose Apps sind einfacher, da der Fokus auf der Anwendung selbst und nicht auf ihrem Zustand liegt (da dieser nicht vorhanden ist).
Bei den meisten zustandslosen Anwendungen ist eine einfache Bereitstellungsworkload mit einem Pod ausreichend, um ein vollfunktionsfähiges System zu erhalten und den Cluster optimal nutzen zu können.
Für zustandsbehaftete Anwendungen gilt das komplette Gegenteil. In diesen Fällen müssen Sie die Anwendung und ihren Zustand berücksichtigen, wo der Zustand gespeichert ist und wie er sicher und zuverlässig gespeichert werden kann.
Aus diesem Grund bietet Kubernetes auch die Konzepte PersistentVolumes (PVs) und PersistentVolumeClaims (PVCs).
Tipp
Dieses Modul behandelt Speicherkonzepte nicht weiter, sie können sich aber in der Zusammenfassung auf die Azure Kubernetes Service-Ressourcen beziehen, um mehr zu erfahren.
PersistentVolumes sind Datenträger, die in Knoten eingeteilt werden und die Zustände aus dem Container eines Pods speichern. Da Kubernetes für verteilte Apps am besten geeignet ist, befinden sich alle erstellten Volumes in einem Pool von verfügbaren Volumes. Container beanspruchen dann diesen Raum für sich selbst. Sie können PersistentVolumeClaims verwenden, um PersistentVolume an einen Pod zu binden und den dazugehörigen Speicherplatz zum Speichern der benötigten Daten zu verwenden.
Bei allen Datenbankanbietern handelt es sich um zustandsbehaftete Anwendungen. Wenn Sie einen Datenbankanbieter in Ihrem Cluster bereitstellen, benötigen Sie ein PV und ein PVC, um die Datenbankdaten an einem sicheren Ort zu speichern und dem Anbieter das Abrufen dieser Daten zu ermöglichen, selbst wenn die dazugehörigen Container gelöscht wurden.
Best Practices für die Zustandsverarbeitung
Zustände werden in den meisten Anwendungen genutzt. Als Best Practice für die Zustandsverarbeitung gilt jedoch, Zustände nicht zu berücksichtigen.
Alle effizienten Anwendungen verfolgen das Ziel, hoch verfügbar und skalierbar zu sein. Zustände sind jedoch das genaue Gegenteil. Trotz den von Speicheranbietern angebotenen Optionen und der einfachen Bereitstellung und Verwendung lässt sich der Zustand nicht einfach skalieren. Er ist auch nicht hochverfügbar.
Hoch verfügbarer Zustand
Damit eine Anwendung hochverfügbar ist, muss sie jederzeit online sein. Dies erfolgt über Zonen-und Regionsreplikation. Bei den meisten Workloads in Kubernetes spielen Zonen eine Rolle. Dies bedeutet, dass Sie über mehrere Instanzen einer Anwendung verfügen können, die in verschiedenen Zonen bereitgestellt werden. Datenträger sind jedoch nicht kompatibel mit Zonen.
Wenn Sie ein neues PersistentVolume-Objekt in Kubernetes bereitstellen, wird es an einen Datenträger auf einem Knoten gebunden. Dieser Datenträger wird wiederum an eine bestimmte Zone in einer bestimmten Region gebunden. Die Verwendung der Zonen- oder Regionsreplikation mit PVs ist komplex und erfordert sehr viel Wartungsarbeiten, sowohl für die Replikation als auch die Synchronisierung der Daten.
Hochgradig skalierbarer Zustand
Um hoch skalierbar zu sein, sollte der Durchsatz einer Anwendung mit der Anzahl der mit ihr verbundenen Benutzer wachsen. Dies ist bei der Zustandsverwaltung kompliziert, weil jeder externe Zustand im Grunde ein Datenträger ist und jeder Datenträger eine begrenzte Ein- und Ausgaberate aufweist. Die Durchsatzverwaltung hilft bei der Lösung dieses Problems.
Datenbanklösungen kamen auf die Idee ReplicaSets, welche die gesamte Datenbank in mehrere Instanzen repliziert. Die Replikation erhöht die Anzahl der Datenträger und die E/A-Vorgänge für den Zustand.
Bei jeder Datenbankänderung muss der Zustand synchronisiert werden, damit alle Datenträger dieselben Daten enthalten. Diese Synchronisierung ist ebenfalls komplex.
Externalisieren des Zustands
Azure verfügt über Plattform-as-a-Service (PaaS)-Lösungen, z. B. Azure Cosmos DB, die hochverfügbar und skalierbar sind und die meisten Zustandsverwaltungsprobleme für Sie lösen.
Wenn Sie den Zustand extern speichern, entfällt der Wartungsbedarf auf Ihrer Seite. Stattdessen können Sie sich auf die Anwendung konzentrieren und den Mehraufwand für Erhaltung der Datenintegrität in Ihrer Infrastruktur verringern.