Questo documento mostra come eseguire la migrazione dei dischi da un datastore vSphere a un altro datastore vSphere con Storage Policy Based Management (SPBM).
1.29: Disponibilità 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 dai cluster utente Controlplane 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 piano di controllo dei kubeception kubeception
Spazio di archiviazione per i carichi di lavoro di cui esegui il deployment sui nodi worker del cluster utente con PV/PVCs di cui è stato eseguito il provisioning dal plug-in del volume vSphere in-tree o dal driver CSI vSphere
Prerequisiti per un cluster di amministrazione
Il cluster di amministrazione deve avere un piano di controllo HA. Se il cluster di amministrazione ha un control plane non HA, esegui la migrazione a HA prima di continuare.
Verifica che il cluster di amministrazione abbia un piano di controllo 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 visualizzare tre nodi del piano di controllo. Ad esempio:
admin-cp-1 Ready control-plane,master ... admin-cp-2 Ready control-plane,master ... admin-cp-3 Ready control-plane,master ...
Prerequisiti per tutti i cluster (di amministrazione e utente)
Per il cluster deve essere disattivata la riparazione automatica dei nodi. Se la riparazione automatica dei nodi è attivata, disattivala.
Il cluster deve utilizzare Storage Policy Based Management (SPBM). Se il cluster non utilizza SPBM, crea una policy di archiviazione prima di continuare.
Verifica che il cluster utilizzi SPBM:
kubectl --kubeconfig CLUSTER_KUBECONFIG get onpremadmincluster --namespace kube-system \ -ojson | jq '{datastore: .items[0].spec.vCenter.datastore, storagePolicyName: .items[0].spec.vCenter.storagePolicyName}'(Solo cluster utente) Verifica che i node pool utilizzino SPBM:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get onpremnodepools --namespace USER_CLUSTER_NAME-gke-onprem-mgmt \ -ojson | jq '.items[] | {name: .metadata.name, datastore: .spec.vsphere.datastore, storagePolicyName: .spec.vsphere.storagePolicyName}'Sostituisci quanto segue:
CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster (di amministrazione o utente).
ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione
USER_CLUSTER_NAME: il nome del cluster utente
Nell'output, se il campo
datastoreè vuoto e il campostoragePolicyNamenon è vuoto, il cluster utilizza SPBM.Il cluster non deve utilizzare il plug-in del volume vSphere in-tree.
Se hai eseguito l'upgrade del cluster da una versione precedente di Google Distributed Cloud, potrebbe avere PV/PVC di cui è stato eseguito il provisioning dal plug-in del volume vSphere in-tree. Questo tipo di volume potrebbe essere in uso da un nodo del piano di controllo di un cluster utente kubeception o da un carico di lavoro creato su un nodo worker.
Elenco di tutti i PVC e delle relative StorageClass:
kubectl --kubeconfig CLUSTER_KUBECONFIG get pvc --all-namespaces \ -ojson | jq '.items[] | {namespace: .metadata.namespace, name: .metadata.name, storageClassName: .spec.storageClassName}'Elenca tutte le StorageClass e scopri quali provisioner utilizzano:
kubectl --kubeconfig CLUSTER_KUBECONFIG get storageclass
Nell'output, se la colonna
PROVISIONERèkubernetes.io/vsphere-volume, i PVC creati con questa StorageClass utilizzano il plug-in del volume vSphere in-tree. Per gli StatefulSet che utilizzano questi PV/PVC, esegui la migrazione al driver CSI vSphere.
Eseguire la migrazione dello spazio di archiviazione
Google Distributed Cloud supporta due categorie di migrazione dello spazio di archiviazione:
Storage vMotion per le VM, che sposta lo spazio di archiviazione delle VM, inclusi i volumi CNS vSphere collegati utilizzati dai pod in esecuzione su un nodo e i VMDK utilizzati da questi volumi CNS delle VM collegati ai nodi
Rilocazione dei volumi CNS, che sposta i volumi CNS vSphere specificati in un datastore compatibile senza eseguire Storage vMotion per le VM
Eseguire Storage vMotion 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 alla policy di archiviazione.
Nell'ambiente vSphere, esegui la migrazione delle VM del cluster utilizzando il vecchio datastore al nuovo datastore. Per le istruzioni, vedi Eseguire la migrazione di una macchina virtuale a una nuova risorsa di calcolo e a un nuovo spazio di archiviazione.
Sulla workstation di amministrazione, verifica che la migrazione delle VM al nuovo datastore sia stata eseguita correttamente.
Recupera gli oggetti Machine nel cluster:
kubectl --kubeconfig CLUSTER_KUBECONFIG get machines --output yaml
Nell'output, in
status.disks, puoi vedere i dischi collegati alle VM. Ad esempio:status: addresses: – address: 172.16.20.2 type: ExternalIP disks: – bootdisk: true datastore: pf-ds06 filepath: me-xvz2ccv28bf9wdbx-2/me-xvz2ccv28bf9wdbx-2.vmdk uuid: 6000C29d-8edb-e742-babc-9c124013ba54 – datastore: pf-ds06 filepath: anthos/gke-admin-nc4rk/me/ci-bluecwang-head-2-data.vmdk uuid: 6000C29e-cb12-8ffd-1aed-27f0438bb9d9
Verifica che la migrazione di tutti i dischi di tutte le macchine nel cluster sia stata eseguita al datastore di destinazione.
Sulla workstation di amministrazione, esegui
gkectl diagnoseper verificare che il cluster sia integro.
Chiamare le API di rilocazione CNS per spostare i volumi 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 container in vSphere. Questa operazione potrebbe essere più semplice se nel vecchio datastore sono presenti solo volumi CNS.
Aggiornare la policy di archiviazione, se necessario
Nell'ambiente vSphere, aggiorna la policy 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.