Storage

Auf dieser Seite werden die Konzepte des GKE On-Prem-Speichers erläutert.

Fazit

GKE On-Prem lässt sich in externe Block- oder Dateispeichersysteme einbinden, und zwar über VM-Speicher von Kubernetes, Kubernetes-Volume-Plug-ins ("Treiber") und Container Storage Interface-Treiber (CSI).

GKE On-Prem-Cluster verwenden eine standardmäßige Kubernetes StorageClass, um Speicher für zustandsorientierte Arbeitslasten in einem vSphere-Datenspeicher bereitzustellen. Sie können auch eine StorageClass verwenden, um verschiedene Speicher-Volumes bereitzustellen.

vSphere-Speicher

Standardmäßig verwenden GKE On-Prem-Cluster den vSphere-Speicher. Der Administratorcluster erfordert einen vorab bereitgestellten vSphere-Datenspeicher für seine etcd-Daten.

Wenn Sie einen Nutzercluster erstellen, verwendet GKE On-Prem das vSphere Kubernetes-Volume-Plug-in, um neue VM-Laufwerke (VMDKs) in einem vSphere Datenspeicher dynamisch bereitzustellen. (Beachten Sie, dass Nutzercluster vor Version 1.2 denselben Datenspeicher verwendet haben wie Verwaltungscluster.)

Die vSphere-Datenspeicher, die vom Administrator- und Nutzercluster verwendet werden, können auf einem Blockgerät wie einem externen Speicherarray mit NFS, vSAN oder VMFS gesichert werden. In einer Umgebung mit mehreren Hosts muss jedes Blockgerät mit allen Hosts in der Umgebung verbunden sein und der Datenspeicher muss auf jedem Host über die Option Stellen Sie Datastore auf zusätzlichen Hosts bereit konfiguriert werden.

Standardspeicher

GKE On-Prem-Cluster enthalten eine standardmäßige StorageClass von Kubernetes, die bestimmt, wie Kubernetes Speicher bereitstellen soll. Nachdem Kubernetes Speicher-Volumes bereitgestellt hat, werden diese durch Kubernetes-PersistentVolumes dargestellt.

Die Standard-StorageClass für einen Nutzercluster verweist auf einen vSphere-Datenspeicher, der im Feld datastore der StorageClass-Konfiguration festgelegt wird. Standardmäßig sind Kubernetes-PersistentVolumes, die für den Nutzercluster bereitgestellt werden, VMDKs, die diesen Datenspeicher enthalten. Dies ist nicht unbedingt derselbe Datenspeicher, der vom Administratorcluster verwendet wird.

In GKE On-Prem verwenden StatefulSets von Kubernetes (zustandsorientierte Arbeitslasten, die normalerweise nichtflüchtigen Speicher benötigen) PersistentVolumeClaims, die von StorageClasses unterstützt werden und standardmäßig auf vSphere Speicherung verweisen.

Containerspeicher-Nutzeroberfläche

Container Storage Interface (CSI) ist eine Standard-API, die es Kubernetes ermöglicht, beliebige Speichersysteme für containerisierte Arbeitslasten bereitzustellen. Wenn Sie einen CSI-kompatiblen Volumetreiber in einem GKE On-Prem-Cluster bereitstellen, können Arbeitslasten direkt mit einem kompatiblen Speichergerät verbunden werden, ohne den vSphere Speicher verwenden zu müssen.

GKE On-Prem unterstützt CSI v1.0. Wenn Sie CSI in Ihrem Cluster verwenden möchten, müssen Sie den CSI-Treiber Ihres Speicheranbieters bereitstellen. Anschließend können Sie Arbeitslasten für die Verwendung der StorageClass des Treibers konfigurieren oder als Standard-StorageClass festlegen.

Wir arbeiten mit vielen Speicheranbietern zusammen, um ihre Speichersysteme mit GKE On-Prem zu qualifizieren. Vollständige Liste der qualifizierten Speicherpartner

vSphere-CSI-Treiber

Standardmäßig nutzt GKE On-Prem das integrierte Volume-Plug-in vSphere Cloud Provider (VCP) von VMware, das automatisch die Unterstützung für VM-Datenspeicher einschließlich vSAN aktiviert. Der vSphere-CSI-Treiber wird automatisch in GKE On-Prem-Clustern bereitgestellt und ist als Vorschaufeature ab GKE On-Prem Version 1.5 verfügbar.

Volume-Bereinigung

Wenn Sie einen Nutzercluster löschen, werden Volumes, die vom integrierten Volume-Plug-in von VMware bereitgestellt werden, möglicherweise nicht gelöscht. Beim Löschen eines Nutzerclusters werden die vom vSphere-CSI-Treiber bereitgestellten Volumes jedoch nicht gelöscht. Prüfen Sie, ob alle Volumes, PVCs und StatefulSets gelöscht werden, bevor Sie den Cluster löschen.

Integrierte Kubernetes-Volume-Plug-ins

Kubernetes wird mit einer Anzahl von integrierten Volume-Plug-ins ausgeliefert. Sie können eine dieser Optionen verwenden, um Block- oder Dateispeicher für Ihre zustandsorientierten Arbeitslasten bereitzustellen. Mit integrierten Plug-ins können Arbeitslasten direkt mit dem Speicher verbunden werden, ohne den vSphere-Speicher nutzen zu müssen.

Während der vSphere-Speicher automatisch die dynamische Bereitstellung von Datenträgern in einem Datenspeicher bereitstellt, der von einem beliebigen iSCSI-, FC- oder NFS-Speichergerät unterstützt wird, unterstützen viele der Plug-ins nicht die dynamische Bereitstellung. Sie erfordern, dass Sie PersistentVolumes manuell erstellen.

In der folgenden Tabelle werden mehrere integrierte Volume-Plug-ins beschrieben:

Integriertes Kubernetes-Volume-Plug-inBeschreibungUnterstützte ZugriffsmodiDynamische Bereitstellung
Fibre ChannelGenerisches Speicher-Plug-inEinzelnen Pod lesen/schreibenNo
iSCSIGenerisches Speicher-Plug-inEinzelnen Pod lesen/schreibenNo
NFSGenerisches Speicher-Plug-inMehrere Pods lesen/schreibenNo
Ceph RBDOpen-Source-Software-definierter SpeicherEinzelnen Pod lesen/schreibenJa
CephFSOpen-Source-Software-definierter SpeicherMehrere Pods lesen/schreibenNo
PortworxUrheberrechtlich geschützter SpeicherMehrere Pods lesen/schreibenJa
QuobyteUrheberrechtlich geschützter SpeicherEinzelnen Pod lesen/schreibenJa
StorageOSUrheberrechtlich geschützter SpeicherEinzelnen Pod lesen/schreibenJa

Clusterspeicher konfigurieren

Wenn Sie andere Speicher-Volumes als vSphere-Datenspeicher bereitstellen möchten, können Sie eine neue StorageClass in einem Cluster erstellen, der einen anderen Speichertreiber verwendet. Anschließend können Sie die StorageClass als Standardcluster festlegen oder Ihre Arbeitslasten mithilfe der StorageClass konfigurieren (StatefulSet-Beispiel).

Fehlerbehebung

Siehe Fehlerbehebung für Speicher.

Weitere Informationen