‫Bisher haben wir mit Kubernetes weder über Speicher noch über
‫Volumes gesprochen.
‫Sie haben sich mit Docker und dann mit
‫Compose und Swarm befasst, und bis zu einem gewissen Grad ist
‫es bei Kubernetes dasselbe.
‫Sie haben Container, und wir gehen davon aus,
‫dass die Container zustandslos sind. Wenn Sie den
‫Container wegwerfen, geht alles darin verloren.
‫Wenn Sie einen Container durch ein Update ersetzen oder
‫etwas ändern und es mit einem kubectl apply anwenden, verlieren Sie den Container, Sie
‫verlieren alles darin.
‫Natürlich müssen Kubernetes, genau wie die anderen
‫Orchestratoren, eine Möglichkeit haben, dass persistente
‫Daten erhalten bleiben. Es ist sogar mehr als die Bände selbst.
‫Sogar die Container und Bereitstellungen können in Kubernetes mit
‫so genannten StatefulSets unterschiedlich sein.
‫Hierbei handelt es sich um Ressourcen, die
‫sich von Bereitstellungen unterscheiden.
‫Sie basieren im Wesentlichen auf Datenbanken und Dingen, die viel
‫mehr Persistenz erfordern, einschließlich des gleichen
‫Namens und des gleichen IP-Materials.
‫Wir haben das nicht unbedingt mit Swarm oder Docker
‫von der Stange bekommen.
‫Es gab für Sie keine Möglichkeit, diese
‫unterschiedlichen Attribute zwischen Containern beizubehalten.
‫StatefulSets ist eine neue Funktion in
‫Kubernetes, die hier nur wenig Zeit verloren hat.
‫Es ist das, worauf Sie achten sollten,
‫wenn Sie Datenbanken oder etwas in Betracht ziehen, das sehr empfindlich
‫auf Änderungen wie Namen, IP-Adressen, Volumes und persistente Daten
‫reagiert. Ein Wort der Vorsicht hier.
‫Der Grund, warum wir nicht auf viele
‫Details eingehen werden, ist, dass ich nicht empfehle, dass
‫Ihre erste Bereitstellung von Kubernetes
‫viele StatefulSets beinhaltet. Im Idealfall ist Ihre erste
‫Bereitstellung eines Orchestrators, eines Orchestrators, sei es Swarm
‫oder Kubernetes, nur mit Staatenlosen verbunden, und Sie wissen,
‫halten Sie es einfach. Vielleicht machen Sie einfach Ihre
‫Web-Frontends oder einige APIs oder einige Worker-Funktionen oder etwas,
‫das keine Datenbanken beinhaltet. Wenn Sie Cloud-Datenbanken verwenden können, tun
‫Sie dies in der Tat.
‫Ich empfehle immer, Ihre Datenbanken auszulagern, es sei denn,
‫Sie haben bestimmte Anforderungen, die Sie nicht vermeiden können,
‫um selbst ausgeführt zu werden. Ursprünglich war die Orchestrierung
‫wirklich darauf ausgelegt, dass Container unveränderlich, verteilt und
‫austauschbar sind.
‫Diese Idee der Beständigkeit für Staatlichkeit wird mehr Arbeit,
‫Komplexität und viel mehr Tests
‫für Sie bedeuten. Im Idealfall müssen Sie sich
‫darüber keine Sorgen machen.
‫Später, wenn Sie sich mit all den anderen Dingen rund um Kubernetes
‫viel besser auskennen, können Sie zurückkehren und sagen,
‫jetzt möchte ich meine Datenbanken betrachten.
‫Es ist nicht so, dass Sie Datenbanken nicht in Clustern ausführen sollten.
‫Es ist nur mehr Arbeit. Es ist schwerer.
‫Datenbanken und persistenter Speicher sind immer schwieriger und es ist immer schwieriger, mit
‫mehr Details zu arbeiten. Da ist mein Profi-Tipp.
‫Mit jedem Container können Sie ein Volume hinzufügen,
‫das dem in Swarm und in Docker und
‫Docker Compose sehr ähnlich ist. Sie können der Vorlage innerhalb der Spezifikation
‫einfach eine Volumenangabe hinzufügen. Wenn Sie an die YAML-Datei denken,
‫können wir dort einfach ein Volume einfügen, wie Sie es erwarten
‫würden, und das genaue Format und die Details
‫finden Sie in den Ressourcen. Anders als bei Docker
‫und Swarm, wo sich das Volumen bei einem Container befindet,
‫ist es in diesem Fall technisch beim Pod. Es stellt eine Verbindung zu jedem Container oder nur zu einem Container
‫im Pod her, wenn Sie dazu aufgefordert werden.
‫Sie steuern es also auf Containerebene, aber die Beständigkeit liegt bei
‫der Pod-Ebene. Es gibt
‫eine neuere Funktion, die dauerhafte Volumes ist.
‫Das funktioniert mit etwas anderem, das als Claim bezeichnet wird.
‫Die interessante Idee dabei ist, dass Sie
‫es außerhalb der Pods verwenden
‫oder definieren. Sie erstellen diese Ressource
‫im Grunde genommen selbst und erheben dann innerhalb
‫Ihrer Pod-Spezifikation einen Anspruch gegen diese Ressource.
‫Dies ist vor allem deshalb interessant, weil Kubernetes das Unternehmen
‫übernimmt und es häufig Leute gibt, die sich um
‫die Speicherung kümmern, häufig Speicher von Drittanbietern, die nicht dasselbe Team sind,
‫das Kubernetes ausführt.
‫Sie werden diejenigen sein, die mit der Verwaltung und Erstellung
‫dieser beständigen Volumes befasst sind.
‫Dann werden die Application Deployer sagen: Hey,
‫ich brauche
‫ein solches Volume. Also werde ich eine SSD in
‫Anspruch nehmen, oder wir brauchen RAM-Speicher, oder vielleicht brauche ich NFS, oder was
‫auch immer. Dieser Speicher
‫wird automatisch bereitgestellt, da das Speicherteam ihn
‫bereits in Kubernetes eingerichtet hat.
‫Das ist die Idee für dauerhafte Volumes.
‫Wenn Sie nur eine einfache Speicherung auf
‫einem einzelnen Server für den Pod benötigen, verwenden Sie einfach
‫das Standard-Volume-Attribut.
‫Eine letzte Sache hier
‫ist die Erstellung von CSI-Plugins. In der
‫Geschichte von Kubernetes wurde alles, was Speicher
‫von Drittanbietern war, sei es Cloud-Speicher oder Speicher
‫von Drittanbietern oder etwas Besonderes, in
‫den Baum aufgenommen.
‫Das heißt, es wurde zu den Binärdateien von Kubernetes
‫hinzugefügt und mit Kubernetes ausgeliefert.
‫Das bedeutet, dass Kubernetes mit sofort einsatzfähigem Amazon-
‫und Azure-Speicher geliefert wurde.
‫Das war ziemlich praktisch, hat aber so viele Herausforderungen
‫mit sich gebracht.
‫Die meisten davon standen im Zusammenhang mit der
‫Tatsache, dass Speicheranbieter jetzt Code zum Kern Ihres Systems beisteuerten, den
‫Sie wahrscheinlich nicht einmal benötigten, weil Sie möglicherweise nur einen Speicheranbieter verwenden.
‫Warum also alle?
‫Außerdem mussten die Speicheranbieter ihre Release-Zyklen um den Kubernetes-Release-Zyklus
‫herum steuern, und es war kein
‫sehr flexibles Modell.
‫Die Branche hat sich also zusammengeschlossen, und genau
‫wie beim Networking und mit Dockerfiles und Bildern selbst hat
‫sie einen Standard geschaffen. Dieser Standard ist der CSI.
‫Das steht für Container Storage Interface.
‫Das wird jetzt Plug-ins bereitstellen, sodass jeder Speicheranbieter ein Plug-in
‫erstellen kann, das Sie auf allen Knoten installieren
‫würden und das basierend auf dem Plug-in und
‫seinen Anweisungen unterschiedlich wäre.
‫Anschließend werden sie auf einer Standard-API ausgeführt, die vom CSI bereitgestellt
‫wird, sodass jeder Ihrer Container
‫dieses Plugin verwenden kann, um zu ihrem Speicher zu gelangen.
‫Das ist ein viel besseres und flexibleres Modell.
‫Das ist die Zukunft von Kubernetes, aber sie
‫ist noch ziemlich neu. So oft in Beispielen
‫und sogar von Ihren Speicheranbietern wird je nach
‫CSI-Reifegrad empfohlen, dass Sie ihr traditionelles Plug-in verwenden, das
‫in Kubernetes integriert und sofort einsatzbereit ist.