Auf dieser Seite werden die Speicherkonzepte von Google Distributed Cloud (nur Software) für VMware erläutert.
Zusammenfassung
Google Distributed Cloud lässt sich über die folgenden Komponenten in externe Block- oder Dateispeichersysteme einbetten:
- 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 für 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 des Administratorclusters
In Administratorclustern gibt es eine StorageClass namens standard, die als Standard-StorageClass festgelegt ist. In der StorageClass standard ist 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 integrierte vSphere-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 von Nutzerclustern
In Nutzerclustern gibt es eine StorageClass namens standard und eine weitere
StorageClass namens 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 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. Außerdem wird die URL 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: 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 sind jedoch veraltet, einschließlich des integrierten vSphere-Volume-Plug-ins. Weitere Informationen finden Sie im CSI-Migrations projekt.
CSI-Migration für den vSphere-Speichertreiber
In der Vergangenheit war das integrierte vSphere-Volume-Plug-in der Bereitsteller für die Standard-StorageClass in Nutzerclustern. Jetzt ist das integrierte vSphere-Volume-Plug-in 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 also ein integriertes 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 integrierte vSphere-Volume-Plug-in kubernetes.io/vsphere-volume als Bereitsteller aufgeführt ist. Dann werden alle Speicheroperationsaufrufe 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, werden Preflight-Prüfungen durchgeführt, um sicherzustellen, dass Ihre Umgebung für die CSI-Migration geeignet ist.
Beispiel für 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 integrierte vSphere-PersistentVolumes gibt.
- Prüfen Sie, ob die vSphere-StorageClasses bestimmte Parameter enthalten, die nach der CSI-Migration ignoriert werden.
- Prüfen Sie Annotationen für statisch erstellte integrierte PersistentVolumes und PersistentVolumeClaims, die für die CSI-Migration erforderlich sind.
- Prüfen Sie, ob der Cluster eine Arbeitslast ausführen kann, die ein CSI-Volume verwendet, das vom vSphere-CSI-Treiber bereitgestellt wird.
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 zum VMware vSphere CSI-Treiber 3.0 im Abschnitt „Bekannte Probleme“.
Migration zu CSI abschließen
Wenn die Kubernetes-CSI-Migrationsfunktion 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. Die Aufrufe für den Betrieb des integrierten Plug-ins werden einfach an das CSI-Plug-in weitergeleitet. Da die PersistentVolume-Spezifikation unveränderlich ist, ist sie dieselbe wie für das integrierte Volume-Plug-in.
Daher ist der vollständige Funktionsumfang von CSI wie Volume-Erweiterung 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 ein automatisiertes Tool entwickelt, mit dem Sie zustandsorientierte Arbeitslasten ohne Ausfallzeiten der Anwendung zu CSI migrieren können, damit Sie den vollständigen Funktionsumfang von CSI 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 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 Speicher partner.
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 für neu erstellte Cluster, die unter vSphere 7.0 oder höher ausgeführt werden, standardmäßig allowVolumeExpansion 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 Volumes, die vom vSphere-CSI-Treiber bereitgestellt werden, nicht gelöscht. Sie sollten alle Volumes, PersistentVolumeClaims und StatefulSets löschen, bevor Sie den Cluster löschen.
Fehlerbehebung
Siehe Fehlerbehebung für Speicher.