1.29: disponibile a livello generale
1.28: anteprima
1.16: non disponibile
Puoi eseguire la migrazione dei seguenti tipi di spazio di archiviazione:
Spazio di archiviazione per i componenti di sistema gestiti da Google Distributed Cloud, tra cui:
Dischi dati (file VMDK) utilizzati dai nodi del piano di controllo dei cluster di amministrazione e dei cluster utente del piano di controllo v2
Dischi di avvio (file VMDK) utilizzati da tutti i nodi del cluster di amministrazione e del cluster utente
Volumi vSphere rappresentati da PV/PVC nel cluster di amministrazione e utilizzati dai componenti del control plane dei cluster utente di kubeception
Spazio di archiviazione per i carichi di lavoro di cui esegui il deployment sui nodi worker del cluster utente con PV/PVC provisionati dal plug-in dei volumi vSphere in-tree o dal driver CSI vSphere
Prerequisiti per un cluster di amministrazione
Il cluster di amministrazione deve avere un control plane ad alta disponibilità. Se il tuo cluster di amministrazione ha un
piano di controllo non ad alta disponibilità,
esegui la migrazione ad HA
prima di continuare.
Verifica che il cluster di amministrazione abbia un control plane HA:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes
Sostituisci ADMIN_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione.
Nell'output, assicurati di vedere tre nodi del piano di controllo. Ad esempio:
CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster
(amministratore o utente).
ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione
USER_CLUSTER_NAME: il nome del cluster di utenti
Nell'output, se il campo datastore è vuoto e il campo storagePolicyName
non è vuoto, il cluster utilizza SPBM.
Il cluster non deve utilizzare il plug-in dei volumi in-tree di vSphere.
Se è stato eseguito l'upgrade del cluster da una versione precedente di Google Distributed Cloud, potrebbe avere PV/PVC di cui è stato eseguito il provisioning tramite il plug-in dei volumi in-tree di vSphere.
Questo tipo di volume potrebbe essere in uso da un nodo del piano di controllo di un cluster utente kubeception o da un workload creato su un nodo worker.
Elenco di tutti i PVC e delle relative classi StorageClass:
Elenca tutti i StorageClass e controlla quali sono i provisioner in uso:
kubectl --kubeconfig CLUSTER_KUBECONFIG get storageclass
Nell'output, se la colonna PROVISIONER è kubernetes.io/vsphere-volume,
i PVC creati con questo StorageClass utilizzano il plug-in del volume in-tree vSphere. Per i StatefulSet che utilizzano questi PV/PVC,
esegui la migrazione al driver CSI vSphere.
Esegui la migrazione dello spazio di archiviazione
Google Distributed Cloud supporta due categorie di migrazione dell'archiviazione:
Storage vMotion per le VM, che sposta lo spazio di archiviazione delle VM, inclusi i volumi vSphere CNS collegati utilizzati dai pod in esecuzione su un nodo e i VMDK utilizzati da questi volumi VM CNS collegati ai nodi
Rilocazione dei volumi CNS, che sposta i volumi CNS di vSphere specificati in un
datastore compatibile senza eseguire vMotion dell'archiviazione per le VM
Esegui vMotion dell'archiviazione per le VM
La migrazione prevede passaggi da eseguire nell'ambiente vSphere e comandi
da eseguire sulla workstation di amministrazione:
Nell'ambiente vSphere, aggiungi i datastore di destinazione al tuo criterio di archiviazione.
Verifica che sia stata eseguita la migrazione di tutti i dischi di tutte le macchine del cluster al datastore di destinazione.
Sulla workstation di amministrazione, esegui
gkectl diagnose
per verificare che il cluster sia integro.
Chiama le API di spostamento del CNS per spostare i volumi del CNS
Se vuoi spostare solo i volumi CNS di cui è stato eseguito il provisioning dal driver CSI vSphere, puoi seguire le istruzioni riportate in Eseguire la migrazione dei volumi dei container in vSphere.
Questa operazione potrebbe essere più semplice se nel vecchio datastore sono presenti solo volumi CNS.
Aggiorna le norme di archiviazione, se necessario
Nell'ambiente vSphere, aggiorna il criterio di archiviazione in modo da escludere i vecchi
datastore. In caso contrario, i nuovi volumi e le VM ricreate potrebbero essere assegnati a un vecchio datastore.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-08-31 UTC."],[],[],null,["This document shows how to migrate disks from one\n[vSphere datastore](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.storage.doc/GUID-D5AB2BAD-C69A-4B8D-B468-25D86B8D39CE.html)\nto another vSphere datastore with\n[Storage Policy Based Management (SPBM)](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/configure-storage-policy).\n\n1.29: Generally available \n\n1.28: Preview \n\n1.16: Not available\n\nYou can migrate the following kinds of storage:\n\n- Storage for system components managed by Google Distributed Cloud, including:\n\n - Data disks (VMDK files) used by the control-plane nodes of admin clusters\n and Controlplane V2 user clusters\n\n - Boot disks (VMDK files) used by all admin cluster and user cluster nodes\n\n - vSphere Volumes represented by PV/PVCs in the admin cluster and used by the\n control-plane components of\n [kubeception](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/plan-ip-addresses-kubeception)\n user clusters\n\n- Storage for workloads that you deploy on user cluster worker nodes with PV/PVCs\n provisioned by the in-tree vSphere volume plugin or the\n [vSphere CSI driver](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/using-vsphere-csi-driver)\n\nPrerequisites for an admin cluster\n\n1. The admin cluster must have an HA control plane. If your admin cluster has a\n non-HA control plane,\n [migrate to HA](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/migrate-admin-cluster-ha)\n before you continue.\n\n2. Verify that the admin cluster has an HA control plane:\n\n ```\n kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes\n ```\n\n Replace \u003cvar translate=\"no\"\u003eADMIN_CLUSTER_KUBECONFIG\u003c/var\u003e with the path of the admin cluster\n kubeconfig file.\n\n In the output, make sure that you see three control-plane nodes. For example: \n\n ```\n admin-cp-1 Ready control-plane,master ...\n admin-cp-2 Ready control-plane,master ...\n admin-cp-3 Ready control-plane,master ...\n ```\n\nPrerequisites for all clusters (admin and user)\n\n1. The cluster must have node auto repair disabled. If node auto repair is\n enabled,\n [disable node auto repair](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/node-auto-repair#disabling_node_repair_and_health_checking_for_a_user_cluster).\n\n2. The cluster must use\n [Storage Policy Based Management (SPBM)](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.storage.doc/GUID-720298C6-ED3A-4E80-87E8-076FFF02655A.html).\n If your cluster doesn't use SPBM,\n [create a storage policy](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/configure-storage-policy)\n before you continue.\n\n3. Verify that the cluster uses SPBM:\n\n ```\n kubectl --kubeconfig CLUSTER_KUBECONFIG get onpremadmincluster --namespace kube-system \\\n -ojson | jq '{datastore: .items[0].spec.vCenter.datastore, storagePolicyName: .items[0].spec.vCenter.storagePolicyName}'\n ```\n\n (User cluster only) Verify that the node pools use SPBM: \n\n ```\n kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get onpremnodepools --namespace USER_CLUSTER_NAME-gke-onprem-mgmt \\\n -ojson | jq '.items[] | {name: .metadata.name, datastore: .spec.vsphere.datastore, storagePolicyName: .spec.vsphere.storagePolicyName}'\n ```\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eCLUSTER_KUBECONFIG\u003c/var\u003e: the path of the cluster kubeconfig file\n (admin or user).\n\n - \u003cvar translate=\"no\"\u003eADMIN_CLUSTER_KUBECONFIG\u003c/var\u003e: the path of the admin cluster\n kubeconfig file\n\n - \u003cvar translate=\"no\"\u003eUSER_CLUSTER_NAME\u003c/var\u003e: the name of the user cluster\n\n In the output, if the `datastore` field is empty and the `storagePolicyName`\n field is non-empty, then the cluster is using SPBM.\n4. The cluster must not use the vSphere in-tree volume plugin.\n\n If your cluster was upgraded from an earlier version of Google Distributed Cloud,\n it might have PV/PVCs that were provisioned by the\n [vSphere in-tree volume plugin](/kubernetes-engine/distributed-cloud/vmware/docs/concepts/storage#kubernetes_in-tree_volume_plugins).\n This kind of volume might be in use by a control-plane node of a kubeception\n user cluster or by a workload that you created on a worker node.\n\n List of all PVCs and their StorageClasses: \n\n ```\n kubectl --kubeconfig CLUSTER_KUBECONFIG get pvc --all-namespaces \\\n -ojson | jq '.items[] | {namespace: .metadata.namespace, name: .metadata.name, storageClassName: .spec.storageClassName}'\n ```\n\n List all StorageClasses and see what provisioners they are using: \n\n ```\n kubectl --kubeconfig CLUSTER_KUBECONFIG get storageclass\n ```\n\n In the output, if the `PROVISIONER` column is `kubernetes.io/vsphere-volume`,\n then PVCs created with this StorageClass are using the vSphere in-tree volume\n plugin. For the StatefulSets using these PV/PVCs,\n [migrate them to the vSphere CSI driver](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/using-statefulset-csi-migration-tool).\n\nPerform the storage migration\n\nGoogle Distributed Cloud supports two categories of storage migration:\n\n- Storage vMotion for VMs, which moves VM storage, including attached vSphere\n CNS volumes used by Pods running on a node, and VMDKs used by these VM CNS\n volumes attached to the nodes\n\n- CNS volume relocation, which moves specified vSphere CNS volumes to a\n compatible datastore without performing storage vMotion for VMs\n\nPerform storage vMotion for VMs\n\nMigration involves steps that you do in your vSphere environment and commands\nthat you run on your admin workstation:\n\n1. In your vSphere environment, add your target datastores to your storage\n policy.\n\n2. In your vSphere environment, migrate cluster VMs using the old datastore to\n the new datastore. For instructions, see\n [Migrate a Virtual Machine to a New Compute Resource and Storage](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vcenterhost.doc/GUID-23E67822-4559-4870-982A-BCE2BB88D491.html).\n\n3. On your admin workstation, verify that the VMs have been successfully\n migrated to the new datastore.\n\n Get the Machine objects in the cluster: \n\n ```\n kubectl --kubeconfig CLUSTER_KUBECONFIG get machines --output yaml\n ```\n\n In the output, under `status.disks`, you can see the disks attached to the\n VMs. For example: \n\n ```\n status:\n addresses:\n – address: 172.16.20.2\n type: ExternalIP\n disks:\n – bootdisk: true\n datastore: pf-ds06\n filepath: me-xvz2ccv28bf9wdbx-2/me-xvz2ccv28bf9wdbx-2.vmdk\n uuid: 6000C29d-8edb-e742-babc-9c124013ba54\n – datastore: pf-ds06\n filepath: anthos/gke-admin-nc4rk/me/ci-bluecwang-head-2-data.vmdk\n uuid: 6000C29e-cb12-8ffd-1aed-27f0438bb9d9\n ```\n\n Verify that all the disks of all the machines in the cluster have been\n migrated to the target datastore.\n4. On your admin workstation, run\n [`gkectl diagnose`](/kubernetes-engine/distributed-cloud/vmware/docs/troubleshooting/diagnose)\n to verify that the cluster is healthy.\n\nCall CNS Relocation APIs for moving CNS volumes\n\nIf you only want to move CNS volumes provisioned by the vSphere CSI driver, you\ncan follow the instructions in\n[Migrating Container Volumes in vSphere](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.storage.doc/GUID-536DEB75-84F5-48DC-A425-3BF703B8F54E.html).\nThis might be simpler if you only have CNS volumes in the old datastore.\n\nUpdate your storage policy if needed\n\nIn your vSphere environment, update the storage policy to exclude the old\ndatastores. Otherwise, new volumes and re-created VMs might get assigned to\nan old datastore."]]
