Anthos clusters on VMware ora è Google Distributed Cloud (solo software) per VMware. Per ulteriori informazioni, consulta la panoramica del prodotto.

Questa pagina è stata tradotta dall'API Cloud Translation.

Migrazione dello spazio di archiviazione con la gestione basata su criteri di archiviazione

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: 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:
```
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)

La riparazione automatica dei nodi deve essere disabilitata nel cluster. Se la riparazione automatica dei nodi è attivata, disattivala.
Il cluster deve utilizzare Storage Policy Based Management (SPBM). Se il tuo cluster non utilizza SPBM, crea un criterio 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 pool di nodi 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 (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 di archiviazione:
```
kubectl --kubeconfig CLUSTER_KUBECONFIG get pvc --all-namespaces  \
   -ojson | jq '.items[] | {namespace: .metadata.namespace, name: .metadata.name, storageClassName: .spec.storageClassName}'
```
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 dello spazio di 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 dello storage per le VM

Esegui vMotion dell'archiviazione per le VM

La migrazione prevede passaggi che esegui nel tuo ambiente vSphere e comandi che esegui sulla tua workstation di amministrazione:

Nell'ambiente vSphere, aggiungi i datastore di destinazione al tuo criterio di archiviazione.
Nell'ambiente vSphere, esegui la migrazione delle VM del cluster che utilizzano il vecchio datastore al nuovo datastore. Per le istruzioni, consulta Eseguire la migrazione di una macchina virtuale a una nuova risorsa di calcolo e a uno spazio di archiviazione.

Nella workstation di amministrazione, verifica che la migrazione delle VM al nuovo datastore sia andata a buon fine.

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 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.