In diesem Dokument wird beschrieben, wie Sie das StatefulSet-CSI-Migrationstool verwenden, um zustandsorientierte Arbeitslasten von einem In-Tree-vSphere-Volume-Plug-in zum vSphere-CSI-Treiber in Google Distributed Cloud zu migrieren.
In der folgenden Liste sehen Sie die Einführungsphase für dieses Tool nach Version:
- v1.0: GA
- v0.1: Vorschau
Unterstützte Google Distributed Cloud-Versionen: 1.30 bis 1.28.
Überblick
Google Distributed Cloud lässt sich über VMware vSphere-Speicher, integrierte Kubernetes Volume-Plug-ins (oder „Treiber“) und Container Storage Interface (CSI)-Treiber in externe Block- oder Dateispeichersysteme integrieren.
Da die Kubernetes-CSI-Migrationsfunktion in Version 1.15 standardmäßig aktiviert ist, funktioniert ein PersistentVolume, das vom In-Tree-vSphere-Volume-Plug-in unterstützt wird, weiterhin in einer reinen CSI-Umgebung. Die CSI-Migrationsfunktion leitet In-Tree-Plug-in-Vorgangsaufrufe an den CSI-Treiber weiter. Da die PersistentVolume-Spezifikation unveränderlich ist, wird sie weiterhin vom integrierten Plug-in unterstützt. Die verfügbaren Funktionen sind dieselben wie beim in-tree-volume plugin.
Der vollständige Umfang von CSI-Funktionen, z. B. Volume Expansion und Volume Snapshot, ist für solche Volumes nicht verfügbar. Damit Sie diese Funktionen nutzen können, müssen zustandsorientierte Arbeitslasten vollständig zu CSI migriert werden. Dazu müssen die PersistentVolumes, die vom vSphere CSI-Treiber unterstützt werden, neu erstellt werden. Mit dem CSI-Migrationstool können Sie zustandsorientierte Arbeitslasten zu CSI migrieren und alle CSI-Funktionen nutzen.
Dieses Tool bietet eine Möglichkeit, das PersistentVolume und den PersistentVolumeClaim eines StatefulSets per Rolling Migration zu CSI zu migrieren, ohne dass es zu Ausfallzeiten der Anwendung kommt. Mit diesen Tools werden die Kubernetes-Ressourcen in einem lokalen Verzeichnis gesichert und ReclaimPolicy vor der Migration auf Retain gesetzt. Es kommt also zu keinem Datenverlust.
Beschränkung
Die automatisierten Tools werden nur für Google Distributed Cloud-Versionen unterstützt, die vollständig unterstützt werden.
Es funktioniert nur mit StatefulSets. Sie können Preflight-Prüfungen mithilfe des Tools ausführen, um ein paar Sicherheitsprüfungen vor der Verwendung der Tools auszuführen.
./statefulset-csi-migration-tool preflight \
--kubeconfig ADMIN_KUBECONFIG \
--cluster-name USER_CLUSTER_NAME \
--sts-name STS_NAME \
--sts-namespace STS_NAMESPACE \
--intree-storageclass INTREE_STORAGECLASS \
--csi-storageclass CSI_STORAGECLASS
Ersetzen Sie dabei Folgendes:
ADMIN_KUBECONFIG: Pfad der Datei "kubeconfig" Ihres AdministratorclustersUSER_CLUSTER_NAME: Wenn das StatefulSet im Nutzercluster ausgeführt wird, geben Sie den Namen des Nutzerclusters an. Überspringen Sie dieses Flag, wenn die Arbeitslast auf dem Administratorcluster ausgeführt wird.STS_NAME: Name des StatefulSets.STS_NAMESPACE: Namespace des StatefulSets.INTREE_STORAGECLASS: der Name der in-tree-StorageClass, der das PersistentVolume des StatefulSets unterstützt.CSI_STORAGECLASS: der Name der CSI-StorageClass, der das PersistentVolume des StatefulSets nach der Migration unterstützt.
Herunterladen
Laden Sie das Tool unter gs://gke-on-prem-release/statefulset-csi-migration-tool/v1.0/statefulset-csi-migration-tool herunter.
Dieses Tool befindet sich in der Vorschau.
Vorgehensweise
In diesem Abschnitt werden die Schritte beschrieben, die zum Migrieren von StatefulSets vom integrierten internen vCP-Bereitsteller (kubernetes.io/vsphere-volume) in vSphere zum CSI-Bereitsteller (csi.vsphere.vmware.com) in vSphere erforderlich sind.
./statefulset-csi-migration-tool rolling-migration all \
--kubeconfig ADMIN_KUBECONFIG \
--cluster-name USER_CLUSTER_NAME \
--sts-name STS_NAME \
--sts-namespace STS_NAMESPACE \
--intree-storageclass INTREE_STORAGECLASS \
--csi-storageclass CSI_STORAGECLASS \
--working-directory WORKING_DIRECTORY
Ersetzen Sie dabei Folgendes:
ADMIN_KUBECONFIG: Pfad der Datei "kubeconfig" Ihres Administratorclusters
USER_CLUSTER_NAME: Wenn das StatefulSet im Nutzercluster ausgeführt wird, geben Sie den Namen des Nutzerclusters an. Überspringen Sie dieses Flag, wenn die Arbeitslast auf dem Administratorcluster ausgeführt wird.
STS_NAME: Name des StatefulSets.
STS_NAMESPACE: Namespace des StatefulSets.
INTREE_STORAGECLASS: der Name der in-tree-StorageClass, der das PersistentVolume des StatefulSets unterstützt.
CSI_STORAGECLASS: der Name der CSI-StorageClass, der das PersistentVolume des StatefulSets nach der Migration unterstützt.
WORKING_DIRECTORY: das lokale Verzeichnis, in dem die Kubernetes-Ressourcenspezifikation des StatefulSets und seines Pods, PersistentVolumeClaim und PersistentVolume gespeichert werden soll. Der Verzeichnisname muss für jedes StatefulSet eindeutig sein. Dieses Verzeichnis sollte leer sein oder nicht vorhanden sein. Es ist am besten, dieses Verzeichnis nicht zu erstellen, damit das Tooling eines für Sie erstellen kann.
Mit diesem Befehl werden die folgenden Aufgaben ausgeführt:
Erstellt eine Sicherung des StatefulSets und seiner Abhängigkeiten wie PersistentVolume, PersistentVolumeClaim und Pod-Replikat-Spezifikationen im lokalen Arbeitsverzeichnis.
Löscht das StatefulSet mit der Richtlinie zum Löschen von verwaisten Elementen. In diesem Schritt wird nur das StatefulSet gelöscht, nicht aber seine Abhängigkeiten wie die Pod-Replikate, das PersistentVolume und der PersistentVolumeClaim.
Jeder Pod wird zu CSI-Treibern migriert (ähnlich wie bei Option 1). Außerdem wird Folgendes ausgeführt:
a. Legt das Feld „ReclaimPolicy“ des PersistentVolumes auf „Retain“ fest.
b. Löscht den Pod, das PersistentVolume und den PersistentVolumeClaim.
c. Konvertiert die vorhandene VMDK in ein FCD.
d. Erstellt das PersistentVolume, den PersistentVolumeClaim und den Pod noch einmal.
Das StatefulSet wird neu erstellt, aber das Feld „PVCTemplate“ in der Spezifikation verweist auf die CSI-StorageClass. Der StatefulSet-Controller sollte sich den verwaisten Replikaten wieder zuordnen.