Speicher

Auf dieser Seite werden die Konzepte von Google Distributed Cloud Storage erläutert.

Zusammenfassung

Google Distributed Cloud lässt sich auf folgende Weise in externe Block- oder Dateispeichersysteme einbinden:

  • Der CSI-Treiber (vSphere Container Storage Interface)
  • CSI-Treiber von Drittanbietern
  • Integrierte Kubernetes-Volume-Plug-ins

vSphere-Datenspeicher

Beim Erstellen eines Administratorclusters geben Sie einen vorhandenen vSphere-datastore für die etcd-Daten des Clusters an.

Wenn Sie einen Nutzercluster erstellen, können Sie denselben Datenspeicher wie den Administratorcluster verwenden oder einen anderen Datenspeicher angeben. Sie können auch Datenspeicher für einzelne Knotenpools angeben.

Die von den Administrator- und Nutzerclustern verwendeten vSphere-Datenspeicher können durch NFS, vSAN oder VMFS auf einem Blockgerät wie einem externen Speicherarray gesichert werden. In einer Umgebung mit mehreren Hosts muss jedes Blockgerät an alle Hosts in der Umgebung angehängt sein und der Datenspeicher muss auf jedem Host über die Option Datenspeicher auf zusätzlichen Hosts bereitstellen konfiguriert werden.

StorageClasses

Beim Erstellen eines PersistentVolumeClaim können Sie eine Speicherklasse angeben, die Informationen zur Bereitstellung des Speichers enthält. Wenn Sie keine Speicherklasse angeben, wird die Standard-Speicherklasse verwendet.

Speicherklasse des Administratorclusters

In Administratorclustern gibt es eine Speicherklasse mit dem Namen standard, die als Standard-Speicherklasse festgelegt ist. Die Speicherklasse standard listet das integrierte vSphere-Volume-Plug-in als Bereitsteller auf.

So rufen Sie die Speicherklasse standard auf:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get storageclass \
    standard --output yaml

In der Ausgabe sehen Sie, dass standard die Standard-Speicherklasse und der Bereitsteller das integrierte vSphere-Volume-Plug-in kubernetes.io/vsphere-volume ist. Sie können auch den Namen eines vSphere-Datenspeichers sehen.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
  ...
  labels:
    bundle.gke.io/component-name: admin-storage-class
  name: standard
...
parameters:
  datastore: vsanDatastore
provisioner: kubernetes.io/vsphere-volume
...

Speicherklassen von Nutzerclustern

In Nutzerclustern gibt es eine Speicherklasse mit dem Namen standard und eine weitere Speicherklasse mit dem Namen standard-rwo.

Die Speicherklasse standard-rwo wird als Standard-Speicherklasse festgelegt und der vSphere-CSI-Treiber als Bereitsteller aufgeführt.

So rufen Sie die Speicherklasse standard-rwo auf:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get storageclass \
    standard-rwo --output yaml

In der Ausgabe sehen Sie, dass standard-rwo die Standard-Speicherklasse und der Bereitsteller der vSphere-CSI-Treiber csi.vsphere.vmware.com ist. Sie können auch die URL eines vSphere-Datenspeichers sehen:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
    ...
  labels:
    bundle.gke.io/component-name: user-vsphere-csi-driver-addon
    ...
  name: standard-rwo
...
parameters:
  datastoreURL: ds:///vmfs/volumes/vsan:52fb6ca22be2454e-e67f620175964a9f/
provisioner: csi.vsphere.vmware.com
...

Integrierte Kubernetes-Volume-Plug-ins

Kubernetes wird mit einer Reihe von integrierten Volume-Plug-ins ausgeliefert. Die meisten dieser integrierten Volume-Plug-ins (einschließlich des integrierten vSphere-Volume-Plug-ins) wurden jedoch verworfen. Weitere Informationen finden Sie im Projekt zur CSI-Migration.

CSI-Migration für den vSphere-Speichertreiber

In der Vergangenheit war das integrierte vSphere-Volume-Plug-in der Bereitsteller für die Standard-Speicherklasse in Nutzerclustern. Jetzt wurde jedoch das integrierte vSphere-Volume-Plug-in verworfen und der vSphere-CSI-Treiber ist der Bereitsteller für die Standard-Speicherklasse in Nutzerclustern. Wir empfehlen, den vSphere CSI-Treiber anstelle des integrierten Volume-Plug-ins zu verwenden.

Ab Version 1.15 von Google Distributed Cloud ist die CSI-Migrationsfunktion von Kubernetes standardmäßig für das integrierte vSphere-Volume-Plug-in aktiviert. Wenn also eine Arbeitslast ein integriertes vSphere-Volume verwendet, werden alle internen Speichervorgangsaufrufe automatisch an den vSphere-CSI-Treiber weitergeleitet.

Angenommen, ein PersistentVolumeClaim gibt die Speicherklasse standard an, die das integrierte vSphere-Volume-Plug-in kubernetes.io/vsphere-volume als Bereitsteller auflistet. Dann werden die Speichervorgangsaufrufe jeder Arbeitslast, die diesen PersistentVolumeClaim verwendet, an den vSphere-CSI-Treiber csi.vsphere.vmware.com weitergeleitet.

Preflight-Prüfungen

Wenn Sie einen neuen Cluster erstellen oder einen Cluster aktualisieren, wird durch Preflight-Prüfungen sichergestellt, dass Ihre Umgebung für die CSI-Migration geeignet ist.

Die Preflight-Prüfungen:

  • Prüfen Sie, ob Ihre vCenter- und ESXI-Versionen geeignet sind.
  • Prüfen Sie, ob der vSphere-CSI-Treiber aktiviert ist, wenn integrierte vSphere-nichtflüchtige Volumes vorhanden sind.
  • Achten Sie darauf, dass die vSphere-Speicherklassen bestimmte Parameter enthalten, die nach der CSI-Migration ignoriert werden.
  • Überprüfen Sie die Annotationen von statisch erstellten integrierten nichtflüchtigem Speicher und PersistentVolumeClaims, die für die CSI-Migration erforderlich sind.
  • Prüfen Sie, ob der Cluster eine Arbeitslast mit einem vom vSphere-CSI-Treiber bereitgestellten CSI-Volume ausführen kann.

Weitere Informationen finden Sie unter Preflight-Prüfungen ausführen.

Bekannte Probleme

Es gibt mehrere bekannte Probleme im Zusammenhang mit dem vSphere-CSI-Treiber. Informationen und Problemumgehungen finden Sie in den Versionshinweisen für VMware vSphere-CSI-Treiber 3.0 im Abschnitt „Bekannte Probleme“.

Migration zu CSI abschließen

Wenn die CSI-Migrationsfunktion von Kubernetes in Version 1.15 standardmäßig aktiviert ist, funktioniert das PersistentVolume, das vom integrierten vSphere-Volume-Plug-in unterstützt wird, weiterhin in einer reinen CSI-Umgebung. Es leitet nur Aufrufe der integrierten Plug-in-Vorgänge an das CSI-Plug-in weiter. Da die Spezifikation PersistentVolume unveränderlich ist, entspricht die Spezifikation der Spezifikation des integrierten Volume-Plug-ins.

Aus diesem Grund sind für solche Volumes nicht alle CSI-Funktionen wie Volume-Erweiterung und Volume-Snapshot verfügbar. Damit Sie diese Features nutzen können, muss die zustandsorientierte Arbeitslast vollständig zu CSI migriert werden. Dazu wird die Kubernetes-Ressourcenspezifikation mit CSI-Feldern neu erstellt. Wir haben ein automatisiertes Tool entwickelt, mit dem Sie zustandsorientierte Arbeitslasten ohne Ausfallzeiten der Anwendung zu CSI migrieren können, damit Sie alle CSI-Features nutzen können.

Treiber von Drittanbietern verwenden

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 Speicherklasse als Standard für den Cluster festlegen oder Ihre Arbeitslasten so konfigurieren, dass die Speicherklasse verwendet wird (StatefulSet-Beispiel).

Speicherpartner

Wir arbeiten mit vielen Speicheranbietern zusammen, um ihre Speichersysteme für GKE on VMware zu qualifizieren. Vollständige Liste der qualifizierten Speicherpartner.

Volume-Erweiterung

Sie können die Größe eines nichtflüchtigen Volumes nach der Bereitstellung erweitern. Bearbeiten Sie dazu die Kapazitätsanfrage im PersistentVolumeClaim-Objekt. Sie können eine Onlineerweiterung ausführen, während das Volume von einem Pod verwendet wird, oder eine Offlineerweiterung, wenn das Volume nicht verwendet wird.

Für den vSphere-CSI-Treiber ist die Offlineerweiterung in vSphere-Versionen ab 7.0 und die Onlineerweiterung in vSphere-Versionen ab 7.0 Update 2 verfügbar.

Die Speicherklasse standard-rwo legt allowVolumeExpansion für neu erstellte Cluster, die unter vSphere 7.0 ausgeführt werden, standardmäßig auf „true“ fest. Sie können sowohl die Online- als auch die Offline-Erweiterung für Volumes mit dieser Speicherklasse verwenden. Da Speicherklassen bei Clusterupgrades nicht geändert werden, bleibt die Einstellung allowVolumeExpansion in standard-rwo beim Upgrade eines Clusters von 1.7 auf 1.8 nicht festgelegt. Dadurch ist eine Volume-Erweiterung nicht zulässig.

Weitere Informationen zur Volume-Erweiterung finden Sie unter Volume-Erweiterung verwenden.

Snapshots des CSI-Volumes

Mit den Ressourcen VolumeSnapshot und VolumeSnapshotClass können Sie Snapshots des nichtflüchtigen Speichers erstellen. Zur Verwendung dieses Features auf einem CSI-Volume muss der CSI-Treiber Volume-Snapshots unterstützen und der Sidecar-Container external-snapshotter muss in der CSI-Treiberbereitstellung enthalten sein.

Weitere Informationen zu Volume-Snapshots finden Sie unter Volume-Snapshots verwenden

Die CSI-Snapshot-Controller werden automatisch bereitgestellt, wenn Sie einen Cluster erstellen.

Volume-Bereinigung

Wenn Sie einen Nutzercluster löschen, werden die vom vSphere CSI-Treiber bereitgestellten Volumes nicht gelöscht. Sie sollten alle Volumes, PersistentVolumeClaims und StatefulSets löschen, bevor Sie den Cluster löschen.

Fehlerbehebung

Siehe Fehlerbehebung für Speicher.

Weitere Informationen