Auf dieser Seite werden Speicherkonzepte für Google Distributed Cloud (nur Software) für VMware erläutert.
Zusammenfassung
Google Distributed Cloud lässt sich über die folgenden Methoden 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 vSphere-Datenspeicher 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 mit dem Namen 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 standard-StorageClass 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 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
...
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 ist als Bereitsteller aufgeführt.
So rufen Sie die standard-rwo-StorageClass 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 auch die URL eines vSphere-Datenspeichers aufrufen:
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 In-Tree-Volume-Plug-ins sind jedoch veraltet, einschließlich des In-Tree-Volume-Plug-ins für vSphere. Weitere Informationen finden Sie im Projekt CSI-Migration.
CSI-Migration für den vSphere-Speichertreiber
Bisher war das integrierte vSphere-Volume-Plug-in der Provisioner für die Standard-StorageClass in Nutzerclustern. Das integrierte vSphere-Volume-Plug-in ist jedoch jetzt veraltet und der vSphere-CSI-Treiber ist der Bereitsteller für die Standard-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 integrierte vSphere-Volume-Plug-in aktiviert. Wenn eine Arbeitslast ein In-Tree-vSphere-Volume verwendet, werden alle internen Speicheroperationsaufrufe automatisch an den vSphere-CSI-Treiber weitergeleitet.
Angenommen, ein PersistentVolumeClaim gibt die StorageClass standard an, in der das vSphere-In-Tree-Volume-Plug-in kubernetes.io/vsphere-volume als Bereitsteller aufgeführt ist. Alle Arbeitslasten, die diesen PersistentVolumeClaim verwenden, haben dann ihre Speicheroperationsaufrufe an den vSphere CSI-Treiber csi.vsphere.vmware.com umgeleitet.
Preflight-Prüfungen
Wenn Sie einen neuen Cluster erstellen oder einen Cluster upgraden, werden Preflight-Prüfungen ausgeführt, um sicherzustellen, 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 es In-Tree-vSphere-PersistentVolumes gibt.
- Prüfen Sie, ob die vSphere-StorageClasses bestimmte Parameter haben, die nach der CSI-Migration ignoriert werden.
- Prüfen Sie die Annotationen für statisch erstellte 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 wurde.
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-Treiber 3.0.
Migration zu CSI abschließen
Da die Kubernetes-CSI-Migrationsfunktion in Version 1.15 standardmäßig aktiviert ist, funktionieren die PersistentVolume, die vom In-Tree-vSphere-Volume-Plug-in unterstützt werden, weiterhin in einer reinen CSI-Umgebung. Die In-Tree-Plug-in-Vorgangsaufrufe werden lediglich an das CSI-Plug-in weitergeleitet. Da die PersistentVolume-Spezifikation unveränderlich ist, ist sie dieselbe wie beim in-tree-volume plugin.
Daher ist der vollständige Umfang von CSI-Funktionen, z. B. Volume Expansion und Volume Snapshot, für solche Volumes nicht verfügbar. Damit Sie diese Funktionen nutzen können, muss die zustandsorientierte Arbeitslast vollständig zu CSI migriert werden. Dazu müssen Sie die Kubernetes-Ressourcenspezifikation mit CSI-Feldern neu erstellen. Wir haben automatisierte Tools entwickelt, mit denen zustandsorientierte Arbeitslasten ohne Anwendungsunterbrechung zu CSI migriert werden können. So können Sie das gesamte CSI-Funktionsset nutzen.
Drittanbietertreiber 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).
Storage-Partner
Wir arbeiten mit vielen Speicheranbietern zusammen, um ihre Speichersysteme für 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 „true“ 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.