Stateful vs Stateless Applications auf Kubernetes
Beginnen wir mit einer naiven Definition von "Staatenlosigkeit" und gehen dann langsam zu einer strengeren und realen Sichtweise.
Eine staatenlose Anwendung ist eine, die von keinem anhaltenden Speicher abhängt. Das einzige, wofür Ihr Cluster verantwortlich ist, ist der Code und andere statische Inhalte, die darauf gehostet werden. Das ist es, keine sich ändernden Datenbanken, keine Schreibvorgänge und keine übrig gebliebenen Dateien, wenn der Pod gelöscht wird.
Eine staatliche Anwendung hingegen hat mehrere andere Parameter, die sie im Cluster betreuen soll. Es gibt dynamische Datenbanken, die, selbst wenn die App offline oder gelöscht ist, auf der Festplatte bestehen bleibt. Auf einem verteilten System wie Kubernetes wirft dies mehrere Probleme auf. Wir werden sie ausführlich betrachten, aber zuerst klären wir einige Missverständnisse.
Staatenlose Dienste sind eigentlich nicht „aufstandslos“
Was bedeutet es, wenn wir den Zustand eines Systems sagen?? Betrachten wir das folgende einfache Beispiel einer automatischen Tür.
Die Tür öffnet.
In der Praxis ähnelt Ihre staatenlose App diesem oben genannten Mechanismus. Es kann viel mehr Zustände haben, als nur geschlossen oder offen, und viele verschiedene Arten von Inputs sowie so komplexer, aber im Wesentlichen gleich.
Es kann komplizierte Probleme lösen, indem sie nur eine Eingabe erhalten und Aktionen ausführen, die sowohl von der Eingabe als auch von "Status" abhängen. Die Anzahl der möglichen Zustände ist vordefiniert.
Staatenlosigkeit ist also eine Fehlbezeichnung.
Staateless Anwendungen können in der Praxis auch ein wenig betrügen, indem sie Details über die Kundensitzungen auf dem Kunden selbst speichern (HTTP -Cookies sind ein gutes Beispiel) und haben immer noch eine schöne Staatenlosigkeit, die sie fehlerfrei auf dem Cluster läuft.
Beispielsweise können die Sitzungsdetails eines Kunden wie die Produkte im Warenkorb gespeichert und nicht überprüft werden.
Auf einem Kubernetes -Cluster hat eine staatenlose Anwendung keinen anhaltenden Speicher oder Volumen zugeordnet. Aus Sicht der Operationen sind dies großartige Neuigkeiten. Verschiedene Schoten im gesamten Cluster können unabhängig voneinander arbeiten, wobei mehrere Anfragen gleichzeitig zu ihnen kommen. Wenn etwas schief geht, können Sie die Anwendung einfach neu starten und es wird mit wenig Ausfallzeit in den Ausgangszustand zurückkehren.
Staatliche Dienste und der Cap -Theorem
Die staatlichen Dienstleistungen hingegen müssen sich um viele, viele Kanten- und seltsame Probleme kümmern. Eine Schote wird mit mindestens einem Volumen begleitet, und wenn die Daten in diesem Volumen beschädigt sind.
Wenn Sie beispielsweise eine Datenbank auf einem Kubernetes -Cluster ausführen, müssen alle Pods ein lokales Volumen für die Speicherung der Datenbank haben. Alle Daten müssen perfekt synchronisiert sein.
Wenn also jemand einen Eintrag in die Datenbank ändert und dies auf Pod A durchgeführt wurde und eine Leseanforderung in Pod B erhältlich ist, um diese geänderten Daten anzuzeigen. Dies ist als Konsistenz bekannt.
Konsistenz, im Kontext eines Kubernetes -Clusters bedeutet bedeutet Jede Lesung empfängt die neueste Schreib- oder Fehlermeldung.
Aber das schneidet dagegen Verfügbarkeit, Einer der wichtigsten Gründe für ein verteiltes System. Die Verfügbarkeit impliziert, dass Ihre Anwendung so nahe an der Perfektion wie möglich funktioniert, rund um die Uhr, mit einem so geringen Fehler wie möglich.
Man kann argumentieren, dass Sie all dies vermeiden können, wenn Sie nur eine zentralisierte Datenbank haben, die für den Umgang mit allen anhaltenden Speicheranforderungen verantwortlich ist. Jetzt haben wir wieder einen einzigen Fehler, was ein weiteres Problem ist, das ein Kubernetes -Cluster überhaupt lösen sollen.
Sie müssen eine dezentrale Möglichkeit haben, anhaltende Daten in einem Cluster zu speichern. Allgemein als Netzwerkpartitionierung bezeichnet. Darüber hinaus muss Ihr Cluster in der Lage sein, den Fehler von Knoten zu überleben, die die staatliche Anwendung ausführen. Dies ist bekannt als als Partitionstoleranz.
Jeder staatliche Dienst (oder die Anwendung), die auf einem Kubernetes -Cluster ausgeführt werden, muss zwischen diesen drei Parametern ausgeglichen werden. In der Branche ist es als CAP -Theorem bekannt, in dem die Kompromisse zwischen Konsistenz und Verfügbarkeit bei der Anwesenheit von Netzwerkaufteilungen berücksichtigt werden.
Weitere Referenzen
Für weitere Einblicke in das CAP -Theorem möchten Sie diese hervorragende Gespräche von Bryan Cantrill sehen, der sich viel genauer mit der Ausführung verteilter Systeme in der Produktion befasst.