Storage

Auf dieser Seite werden die Speicherkonzepte von Google Distributed Cloud (nur Software) für VMware erläutert.

Fazit

Google Distributed Cloud lässt sich über folgende Optionen in externe Block- oder Dateispeichersysteme integrieren:

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

vSphere-Datenspeicher

Wenn Sie einen Administratorcluster erstellen, geben Sie einen vorhandenen 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 blockorientierten Gerät, z. B. einem externen Speicherarray, gesichert werden. In einer Umgebung mit mehreren Hosts muss jedes blockorientierte Gerät mit allen Hosts in der Umgebung verbunden sein und der Datenspeicher muss auf jedem Host über die Option Datastore auf zusätzlichen Hosts bereitstellen konfiguriert werden.

StorageClasses

Wenn Sie einen PersistentVolumeClaim erstellen, können Sie eine StorageClass angeben, die Informationen zur Bereitstellung des Speichers enthält. Wenn Sie keine StorageClass angeben, wird die Standard-StorageClass verwendet.

StorageClass für Administratorcluster

In Administratorclustern gibt es eine StorageClass namens standard, die als Standard-StorageClass festgelegt ist. In der StorageClass standard wird das integrierte vSphere-Volume-Plug-in als Bereitsteller aufgeführt.

So rufen Sie die StorageClass standard auf:

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

In der Ausgabe sehen Sie, dass standard die Standard-StorageClass ist und der Bereitsteller das vSphere-In-Tree-Volume-Plug-in kubernetes.io/vsphere-volume ist. Außerdem wird der Name eines vSphere-Datenspeichers angezeigt.

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
...

StorageClasses für Nutzercluster

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

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

So rufen Sie die StorageClass standard-rwo auf:

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

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

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 zahlreichen integrierten Volume-Plug-ins ausgeliefert. Die meisten dieser In-Tree-Volume-Plug-ins werden jedoch eingestellt, einschließlich des In-Tree-Volume-Plug-ins von vSphere. Weitere Informationen finden Sie im Projekt CSI-Migration.

CSI-Migration für den vSphere-Speichertreiber

Bisher war das vSphere-Volume-Plug-in der Bereitsteller für die Standard-StorageClass in Nutzerclustern. Das integrierte vSphere-Volume-Plug-in wird jedoch eingestellt und der vSphere CSI-Treiber ist der Bereitsteller der standardmäßigen StorageClass 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 Kubernetes CSI-Migrationsfunktion standardmäßig für das In-Tree-vSphere-Volume-Plug-in aktiviert. Wenn also eine Arbeitslast ein In-Tree-vSphere-Volume verwendet, werden alle internen Aufrufe von Speichervorgängen automatisch an den vSphere CSI-Treiber weitergeleitet.

Angenommen, in einem PersistentVolumeClaim ist die StorageClass standard angegeben, in der das vSphere-In-Tree-Volume-Plug-in kubernetes.io/vsphere-volume als Bereitsteiler aufgeführt ist. Dann werden die Speichervorgänge aller Arbeitslasten, die diesen PersistentVolumeClaim verwenden, an den vSphere CSI-Treiber csi.vsphere.vmware.com weitergeleitet.

Preflight-Prüfungen

Wenn Sie einen neuen Cluster erstellen oder einen Cluster aktualisieren, werden Preflight-Prüfungen durchgeführt, um sicherzustellen, dass Ihre Umgebung für die CSI-Migration geeignet ist.

Die Preflight-Prüfungen dienen beispielsweise dazu,

  • Prüfen Sie, ob Ihre vCenter- und ESXi-Versionen geeignet sind.
  • Prüfen Sie, ob der vSphere CSI-Treiber aktiviert ist, wenn es In-Tree-vSphere-PersistentVolumes gibt.
  • Prüfen Sie, ob die vSphere-Speicherklassen keine bestimmten Parameter haben, die nach der CSI-Migration ignoriert werden.
  • Prüfen Sie die Anmerkungen zu statisch erstellten In-Tree-PersistentVolumes und PersistentVolumeClaims, die für die CSI-Migration erforderlich sind.
  • Prüfen Sie, ob der Cluster eine Arbeitslast mit einem CSI-Volume ausführen kann, das vom vSphere CSI-Treiber bereitgestellt wird.

Weitere Informationen finden Sie unter Vorabprüfungen ausführen.

Bekannte Probleme

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

Migration zu CSI abschließen

Da die Kubernetes-CSI-Migrationsfunktion in 1.15 standardmäßig aktiviert ist, funktioniert das PersistentVolume, das vom In-Tree-vSphere-Volume-Plug-in unterstützt wird, auch in einer reinen CSI-Umgebung. Es werden lediglich In-Tree-Plug-in-Vorgangsaufrufe an das CSI-Plug-in weitergeleitet. Da die PersistentVolume-Spezifikation unveränderlich ist, ist sie mit der des in-tree-Volume-Plug-ins identisch.

Daher sind für solche Volumes nicht alle CSI-Funktionen wie Volume Expansion und Volume Snapshot verfügbar. Damit Sie diese Funktionen nutzen können, muss die zustandsorientierte Arbeitslast vollständig zu CSI migriert werden. Dazu müssen die Kubernetes-Ressourcenspezifikation mit CSI-Feldern neu erstellt werden. Wir haben automatisierte Tools entwickelt, mit denen sich zustandsorientierte Arbeitslasten ohne Anwendungsausfallzeiten zu CSI migrieren lassen. So können Sie das gesamte CSI-Funktionspaket nutzen.

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 StorageClass als Standard für den Cluster festlegen oder Ihre Arbeitslasten für die Verwendung der StorageClass konfigurieren (Beispiel StatefulSet).

Speicherpartner

Wir arbeiten mit vielen Speicheranbietern zusammen, um ihre Speichersysteme für die Google Distributed Cloud zu qualifizieren. Vollständige Liste der qualifizierten Speicherpartner.

Volume-Erweiterung

Sie können die Größe eines nichtflüchtigen Volumes nach seiner Bereitstellung erweitern, indem Sie die Kapazitätsanfrage im PersistentVolumeClaim bearbeiten. 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 >= 7.0 und die Onlineerweiterung in vSphere-Versionen >= 7.0 Update 2 verfügbar.

Die StorageClass standard-rwo legt allowVolumeExpansion für neu erstellte Cluster, die unter vSphere 7.0 oder höher ausgeführt werden, standardmäßig auf „wahr“ fest. Sie können mit dieser StorageClass sowohl die Online- als auch die Offlineerweiterung für Volumes verwenden. Da für einen aktualisierten Cluster StorageClasses bei Clusterupgrades nicht geändert werden, wenn ein Cluster von 1.7 auf 1.8 aktualisiert wird, bleibt die Einstellung allowVolumeExpansion in standard-rwo nicht festgelegt, d. h., eine Volume-Erweiterung ist 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. Löschen Sie alle Volumes, PersistentVolumeClaims und StatefulSets, bevor Sie den Cluster löschen.

Fehlerbehebung

Siehe Fehlerbehebung für Speicher.

Weitere Informationen