Dieses Dokument wurde mithilfe automatisierter maschineller Übersetzungstechnologie übersetzt. Wir bemühen uns um korrekte Übersetzungen, übernehmen jedoch keine Gewähr für die Vollständigkeit, Richtigkeit oder Zuverlässigkeit der übersetzten Inhalte. Im Falle von Abweichungen ist die englische Originalversion maßgebend und stellt den verbindlichen Text dar.

VMware vSphere Speicher

Um zustandsbehaftete Workloads mit VMware vSphere Speicher bereitzustellen, empfehlen wir die Erstellung einer vSphereVolume StorageClass. Diese Praxis stellt vSphere Speicher dynamisch bereit, wenn Workloads Volumes über einen PersistentVolumeClaim anfordern.

Um Speicher in vSphere dynamisch bereitzustellen, muss der vSphere-Anbieter aktiviert sein. Siehe die folgenden Seiten für mehr: Out-of-tree vSphere und in-tree vSphere.

Voraussetzungen

Um vSphere Volumes in einem mit dem RKE2 erstellten Cluster bereitzustellen, muss der vSphere Cloud-Anbieter ausdrücklich in den Cluster-Optionen aktiviert werden.

Erstellen einer StorageClass

Die folgenden Schritte können auch mit dem kubectl Kommandozeilenwerkzeug durchgeführt werden. Siehe Kubernetes-Dokumentation zu persistenten Volumes für Details.

  1. Klicken Sie auf ☰ > Clusterverwaltung.

  2. Wählen Sie den Cluster aus, dem Sie vSphere-Speicher bereitstellen möchten, und klicken Sie auf Erkunden.

  3. Wählen Sie in der linken Navigationsleiste Speicher  StorageClasses aus.

  4. Klicken Sie auf Erstellen.

  5. Geben Sie einen Namen für die StorageClass ein.

  6. Unter Provisioner wählen Sie VMware vSphere Volume aus.

    vsphere storage class

  7. Optional können Sie zusätzliche Eigenschaften für diese Speicherklasse unter Parameter angeben. Bitte beachten Sie die vSphere-Speicherdokumentation für weitere Details.

  8. Klicken Sie auf Erstellen.

Erstellen eines Workloads mit einem VMware vSphere Volume

  1. Klicken Sie in der linken Navigationsleiste auf Workload.

  2. Klicken Sie auf Erstellen.

  3. Klicken Sie auf StatefulSet.

  4. Klicken Sie im Tab Volume Claim Templates auf Claim-Vorlage hinzufügen.

  5. Geben Sie einen Namen für das persistente Volume ein.

  6. Wählen Sie im Feld Speicherklasse die vSphere StorageClass aus, die Sie erstellt haben.

  7. Geben Sie die erforderliche Kapazität für das Volume ein. Klicken Sie dann auf Definieren.

  8. Weisen Sie einen Pfad im Feld Einhängepunkt zu. Dies ist der vollständige Pfad, unter dem das Volume im Container-Dateisystem gemountet wird, z.B. /persistent.

  9. Klicken Sie auf Erstellen.

Überprüfung der Persistenz des Volumes

  1. Klicken Sie in der linken Navigationsleiste auf Workload  Pods.

  2. Gehen Sie zu dem Workload, den Sie gerade erstellt haben, und klicken Sie auf ⋮ > Shell ausführen.

  3. Notieren Sie das Verzeichnis im [Root], in dem das Volume gemountet wurde (in diesem Fall /persistent).

  4. Erstellen Sie eine Datei im Volume, indem Sie den Befehl touch /<volumeMountPoint>/data.txt ausführen.

  5. Schließen Sie das Shell-Fenster.

  6. Klicken Sie auf den Namen des Workloads, um detaillierte Informationen anzuzeigen.

  7. Klicken Sie auf ⋮ > Löschen.

  8. Beobachten Sie, dass der Pod gelöscht wird. Dann wird ein neuer Pod geplant, um ihn zu ersetzen, damit der Workload seine konfigurierte Skalierung eines einzelnen zustandsbehafteten Pods beibehält.

  9. Sobald der Ersatz-Pod läuft, klicken Sie auf Shell ausführen.

  10. Untersuchen Sie den Inhalt des Verzeichnisses, in dem das Volume gemountet ist, indem Sie ls -l /<volumeMountPoint> eingeben. Beachten Sie, dass die Datei, die Sie zuvor erstellt haben, weiterhin vorhanden ist.

    workload-persistent-data

Warum StatefulSets anstelle von Deployments verwenden?

Sie sollten immer StatefulSets für Workloads verwenden, die vSphere-Speicher konsumieren, da dieser Ressourcentyp entwickelt wurde, um ein Problem mit VMDK-Blockspeicher zu adressieren.

Da vSphere-Volumes von VMDK-Blockspeicher unterstützt werden, unterstützen sie nur einen Zugriffsmodus von ReadWriteOnce. Diese Einstellung beschränkt das Volume, sodass es nur an einen einzelnen Pod gleichzeitig gemountet werden kann, es sei denn, alle Pods, die dieses Volume konsumieren, befinden sich auf demselben Knoten. Dieses Verhalten macht eine Deployment-Ressource unbrauchbar für das Skalieren über eine einzelne Replikation hinaus, wenn sie vSphere-Volumes konsumiert.

Selbst die Verwendung einer Deployment-Ressource mit nur einem Replikat kann zu einer Deadlock-Situation beim Aktualisieren des Deployments führen. Wenn der aktualisierte Pod auf einen anderen Knoten geplant wird als der, auf dem der vorhandene Pod lebt, wird er nicht starten, da die VMDK weiterhin an dem anderen Knoten angehängt ist.

Verwandte Themen