Grundlegendes zur Zustandsverwaltung in Kubernetes

Wenn Sie über Anwendungen im Allgemeinen sprechen, hören Sie möglicherweise häufig über den Anwendungszustand. In dieser Einheit besprechen wir die Definition von Zustand und die verschiedenen Arten von Zuständen, damit Sie Ihre Anwendung besser darauf vorbereiten können, damit umzugehen.

Staat

Der Zustand der Anwendung ist alles, was im Arbeitsspeicher gespeichert ist, bis die Anwendung ausgeführt wird. Der Zustand kann verschiedene Dinge umfassen, aber wir konzentrieren uns hauptsächlich auf die Benutzerdaten.

Um ein Beispiel für den Anwendungszustand zu geben, stellen Sie sich vor, Sie haben einen Musikplayer geöffnet. Diese Anwendung hat einen Zustand: Es weiß, wer Sie sind, was Sie hören möchten, und welche Musik Sie heruntergeladen haben. Alle diese Informationen sind Teil des Anwendungszustands.

Der In-Memory-Zustand ist die Information, nach der die Anwendung nicht an einer anderen Stelle suchen muss. Der Datenträgerstatus enthält die Informationen, die die Anwendung nicht zur Hand hat, sodass sie dies aus einer anderen Datenquelle abrufen muss.

Arten von Zuständen

Es gibt zwei Arten von Anwendungszuständen. Der erste Typ ist der kurzlebige Zustand, der nicht dauerhaft 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 allein damit arbeiten, da sie den Zustand aus anderen Quellen neu generieren können und nicht den Zustand lokal speichern müssen. Diese Anwendungen werden als Anwendungen bezeichnetstateless.

Der gesamte verbleibende Zustand, der nicht kurzlebig ist, wird als beständiger Zustand bezeichnet. Der permanente Zustand ist nach dem Lebenszyklus eines Containers weiterhin vorhanden. Die meisten containertechnologien, die wir verwenden, haben das Konzept des Volumes, einen Speicherort auf dem Datenträger, an dem der Zustand vorhanden ist. Auch wenn Sie den Container entfernen und wieder aktivieren, bleibt der Zustand an einem sicheren Ort gespeichert und kann wieder verwendet werden.

Anwendungen, die auf einem abzurufenden externen Zustand basieren, werden als Anwendungen bezeichnetstateful.

Staaten und Kubernetes

Kubernetes kann zustandslose und zustandsgebundene Anwendungen verarbeiten. Zustandslose Apps sind einfacher, da wir uns nur auf die Anwendung selbst und nicht auf ihren Zustand konzentrieren können (da sie nicht vorhanden ist).

Für die meisten zustandslosen Anwendungen reicht ein einfaches Deployment-Workload mit einem Pod aus, damit Sie ein voll funktionsfähiges System haben und um Ihren Cluster optimal zu nutzen.

Für zustandsbehaftete Anwendungen gilt das komplette Gegenteil. In diesen Fällen müssen Sie die Anwendung und den zugehörigen Zustand berücksichtigen, wo der Zustand gespeichert ist und wie Sie den Zustand sicher und zuverlässig speichern können.

Deshalb hat Kubernetes auch das Konzept von PersistentVolumes (PVs) und PersistentVolumeClaims (PVCs).

PersistentVolumes sind Datenträger, die in Knoten eingeteilt werden und die Zustände aus dem Container eines Pods speichern. Da Kubernetes am besten für verteilte Apps geeignet ist, liegen alle erstellten Volumes in einem Pool verfügbarer Volumes. Container fordern dann diesen Raum für sich selbst an. Sie können PersistentVolumeClaims verwenden, um PersistentVolume mit einem Pod zu verbinden und dessen Speicherplatz zu nutzen, um die benötigten Daten zu speichern.

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 die Möglichkeit zu geben, diese Daten abzurufen, auch wenn seine Container gelöscht wurden.

Best Practices für die Zustandsverarbeitung

Zustände werden in den meisten Anwendungen genutzt. Eine bewährte Methode für die Behandlung des Zustands besteht jedoch darin, überhaupt nicht damit umzugehen.

Sie entwerfen jede effiziente Anwendung mit dem Ziel, sie hoch verfügbar und skalierbar zu machen. Der Staat geht in die entgegengesetzte Richtung. 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.

Hochverfügbarer Status

Um hoch verfügbar zu sein, muss eine Bewerbung jederzeit online sein. Dies erfolgt über die Zonen- und Regionsreplikation. Kubernetes ist in den meisten Workloads zonenbewusst. Dies bedeutet, dass Sie mehrere Instanzen einer Anwendung haben können, die in verschiedenen Zonen bereitgestellt werden. Datenträger sind jedoch nicht zonenfähig.

Wenn Sie ein neues PersistentVolume Objekt auf Kubernetes bereitstellen, wird es an einen Datenträger auf einem Knoten gebunden. Dieser Datenträger ist auch an eine bestimmte Zone in einem bestimmten Bereich gebunden. Die Verwendung der Zonen- oder Regionsreplikation mit PVs ist komplex und erfordert eine menge Wartung, um Daten zu replizieren und zu synchronisieren.

Hochskalierbarer Zustand

Um hoch skalierbar zu sein, sollte eine Anwendung ihren Durchsatz zusammen mit der Anzahl der Benutzer erhöhen, die mit ihr verbunden sind. Dies ist in der Zustandsverwaltung kompliziert, da jeder externe Zustand im Wesentlichen ein Datenträger ist und ein Datenträger eine begrenzte Eingabe- und Ausgaberate aufweist. Die Durchsatzverwaltung hilft bei der Lösung dieses Problems.

Die Datenbanklösungen entwickelten die Idee von ReplicaSets, die 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 auch komplex.

Externalisieren des Zustands

Azure verfügt über Plattform-as-a-Service-Lösungen (PaaS), z. B. Azure Cosmos DB, die hochverwendbar und skalierbar sind und die meisten Statusverwaltungsprobleme für Sie lösen.

Das externe Speichern des Zustands und das Entfernen der Wartungsanforderung kann Ihnen helfen, sich auf die Anwendung zu konzentrieren und den Aufwand für den Umgang mit der Datenintegrität in Ihrer Infrastruktur zu verringern.