Esegui la migrazione del datastore a SPBM

Questo documento mostra come eseguire la migrazione di un datastore vSphere a Storage Policy Based Management (SPBM).

Questa pagina è rivolta agli esperti di archiviazione che configurano e gestiscono le prestazioni, l'utilizzo e le spese dell'archiviazione. Per scoprire di più sui ruoli comuni e sugli esempi di attività a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli e attività comuni per gli utenti di GKE Enterprise.

1.30: versione GA
1.29: versione di anteprima
1.16 e versioni precedenti: non disponibile

Contesto

Esistono quattro posizioni in cui puoi specificare un datastore nei file di configurazione del cluster:

L'ereditarietà di questi campi è la seguente:

adminCluster.vCenter.datastore ->
  userCluster.vCenter.datastore ->
    (userCluster.masterNode.vsphere.datastore and userCluster.nodePools[i].vsphere.datastore)

Esempi:

  • Se userCluster.vCenter.datastore è vuoto, eredita il valore da adminCluster.vCenter.datastore.

  • Se userCluster.nodePools[i].vsphere.datastore è vuoto, eredita il valore da userCluster.vCenter.datastore.

Allo stesso modo, esistono quattro posizioni in cui specificare un criterio di archiviazione:

L'eredità per i campi storagePolicyName è la stessa per i campi datastore.

Prima di iniziare

  • Si tratta di una migrazione unidirezionale. Non supportiamo la migrazione allo stato precedente.
  • Il data store deve essere compatibile con il nuovo criterio di archiviazione che hai intenzione di impostare.
  • Sono supportati solo i cluster di amministrazione ad alta disponibilità (HA). Se il tuo cluster di amministrazione non è ad alta disponibilità, devi prima eseguire la migrazione del cluster di amministrazione ad alta disponibilità.

Esegui la migrazione di un cluster utente

I passaggi da seguire per la migrazione dipendono dal fatto che tu voglia eseguire la migrazione dell'intero cluster utente o dei nodi del piano di controllo e dei pool di nodi worker distintamente. Questa opzione ti consente di selezionare diversi criteri di archiviazione per i nodi del piano di controllo e i pool di nodi worker.

Per aiutarti a pianificare un periodo di manutenzione, tieni presente quanto segue:

  • La migrazione dell'intero cluster richiede un solo aggiornamento del cluster.

  • La migrazione dei pool di nodi del piano di controllo e dei nodi worker separatamente richiede due aggiornamenti del cluster.

Intero cluster

Segui questi passaggi se vuoi eseguire la migrazione dell'intero cluster, inclusi tutti i nodi del piano di controllo e i pool di nodi worker. La versione del cluster utente deve essere almeno 1.30.

  1. Modifica il file di configurazione del cluster utente come segue:

    1. Imposta il campo vCenter.storagePolicyName con il nome del criterio di archiviazione.

    2. Rimuovi o inserisci un commento per quanto segue, se specificato:

      • Campo vCenter.datastore
      • Sezione masterNode.vsphere
      • nodepools[i].vsphere.datastore
      • nodepools[i].vsphere.storagePolicyName

    Le seguenti configurazioni di esempio mostrano queste modifiche.

    Prima delle modifiche:

    vCenter:
  datastore: ds-1

    Dopo le modifiche:

    vCenter:
  storagePolicyName: sp-1
  # datastore: ds-1

  2. Aggiorna il cluster utente:

    gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG

    Sostituisci quanto segue:

    • ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

    • USER_CLUSTER_CONFIG: il percorso del file di configurazione del cluster utente.

Aggiornare StorageClass in bundle

Dopo aver aggiornato le impostazioni di configurazione nel cluster, devi aggiornare il StorageClass incluso.

  1. Recupera il StorageClass predefinito corrente per il vsphere-csi-driver incluso, denominato standard-rwo, e salvalo in un file locale denominato storage-class.yaml.

    kubectl get storageclass standard-rwo -oyaml \
    --kubeconfig USER_CLUSTER_KUBECONFIG > storage-class.yaml

    Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster utente.

  2. Crea una copia di storage-class.yaml per precauzione, poiché dovrai apportare modifiche al file:

    cp storage-class.yaml storage-class.yaml-backup.yaml

  3. Elimina StorageClass predefinito dal cluster:

    kubectl delete storageclass standard-rwo \
    --kubeconfig USER_CLUSTER_KUBECONFIG

  4. Aggiorna la configurazione in storage-class.yaml come segue:

    1. Elimina o inserisci un commento nei seguenti campi:

      • parameters.datastoreURL
      • resourceVersion

    2. Aggiungi il campo parameters.storagePolicyName e impostalo sul nome del criterio di archiviazione.

    Le seguenti configurazioni di esempio mostrano queste modifiche.

    Prima delle modifiche:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  datastoreURL: ds//ds-1

    Dopo le modifiche:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  storagePolicyName: sp-1

  5. Applica StorageClass modificato al cluster utente:

    kubectl apply -f storage-class.yaml \
    --kubeconfig USER_CLUSTER_KUBECONFIG

Solo cluster di utenti Kubeception

Per i cluster utente Kubeception, devi aggiornare StorageClass per i nodi del piano di controllo del cluster utente nel cluster di amministrazione. I cluster Kubeception hanno il campo di configurazione enableControlplaneV2 impostato su false. Quando il control plane v2 è abilitato, il control plane per il cluster utente viene eseguito nel cluster utente stesso. Quando il control plane v2 non è abilitato, il control plane per il cluster utente viene eseguito nel cluster di amministrazione, operazione nota come kubeception.

Esegui il seguente comando per determinare se nel cluster è attivato Controlplane V2:

kubectl get onpremuserclusters --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system -o jsonpath='{.items[0].spec.enableControlplaneV2}' && echo

Se l'output è false, completa i seguenti passaggi per aggiornare il valore predefinito StorageClass per i nodi del piano di controllo del cluster utente nel cluster di amministrazione:

  1. Recupera il StorageClass predefinito corrente per il vsphere-csi-driver incluso, denominato USER_CLUSTER_NAME-csi, e salvalo in un file locale denominato storage-class-kubeception.yaml.

    kubectl get storageclass USER_CLUSTER_NAME-csi -oyaml \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG > storage-class-kubeception.yaml

    Sostituisci ADMIN_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione.

  2. Crea una copia di storage-class-kubeception.yaml per precauzione, poiché devi apportare modifiche al file:

    cp storage-class-kubeception.yaml storage-class-kubeception-backup.yaml

  3. Elimina StorageClass predefinito dal cluster:

    kubectl delete storageclass USER_CLUSTER_NAME-csi \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  4. Aggiorna la configurazione in storage-class-kubeception.yaml come segue:

    1. Elimina o inserisci un commento nei seguenti campi:

      • parameters.datastoreURL
      • resourceVersion

    2. Aggiungi il campo parameters.storagePolicyName e impostalo sul nome del criterio di archiviazione.

    Le seguenti configurazioni di esempio mostrano queste modifiche.

    Prima delle modifiche:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  datastoreURL: ds//ds-1

    Dopo le modifiche:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  storagePolicyName: sp-1

  5. Applica StorageClass modificato al cluster di amministrazione:

    kubectl apply -f storage-class-kubeception.yaml \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Dopo la migrazione

Se crei un nuovo pool di nodi dopo una migrazione, il nuovo pool segue le regole di ereditarietà in base al cluster aggiornato.

Ad esempio, supponiamo che tu abbia eseguito la migrazione di vCenter.datastore a un criterio di archiviazione.

Ora, se crei un nuovo pool di nodi e lasci vuoti sia nodePools[i].vsphere.datastore sia nodePools[i].vsphere.storagePolicyName, il nuovo pool di nodi eredita il criterio di archiviazione specificato in vCenter.storagePolicyName.

Nodi separatamente

Segui questi passaggi se vuoi eseguire la migrazione dei nodi del piano di controllo e dei pool di nodi worker separatamente.

  1. Solo versione 1.29: ottieni la configurazione corrente del cluster. Questo passaggio non è necessario se il cluster utente è alla versione 1.30 o successiva.

    gkectl get-config cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --cluster-name USER_CLUSTER_NAME \
  --output-dir ./gen-files

    Sostituisci quanto segue:

    • ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig per il cluster di amministrazione.

    • USER_CLUSTER_NAME: il nome del cluster di utenti.

    In ./gen-files, individua user-cluster.yaml.

    Per ulteriori informazioni su come ottenere il file di configurazione, consulta Genera file di configurazione da un cluster.

    Il file di configurazione generato ha il nome datastore impostato a ogni livello: cluster, masterNode (per i nodi del piano di controllo) e nodepools (per i nodi worker), come mostrato nell'esempio seguente:

    apiVersion: v1
kind: UserCluster
...
# VCenter config in cluster level:
vCenter:
  datastore: ds-1
...
# VCenter config in master node level:
masterNode:
  vsphere:
    datastore: ds-1
...
# VCenter config in nodepool level:
nodepools:
- name: pool-1
  vsphere:
    datastore: ds-1
- name: pool-2
  vsphere:
    datastore: ds-1

Esegui la migrazione dei nodi del control plane

Per eseguire la migrazione dei nodi del piano di controllo:

  1. Apporta le seguenti modifiche al file di configurazione del cluster utente:

    • Imposta il campo masterNode.vsphere.storagePolicyName con il nome del criterio di archiviazione.
    • Elimina o inserisci un commento nel campo masterNode.vsphere.datastore.

    Le seguenti configurazioni di esempio mostrano queste modifiche.

    Prima delle modifiche:

    masterNode:
  vsphere:
    datastore: ds-1

    Dopo le modifiche:

    masterNode:
  vsphere:
    # datastore: ds-1
    storagePolicyName: sp-1

  2. Aggiorna il cluster utente:

    gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG

    Sostituisci quanto segue:

    • ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

    • USER_CLUSTER_CONFIG: il percorso del file di configurazione del cluster utente.

    Attendi il completamento del comando di aggiornamento prima di aggiornare i pool di nodi.

Esegui la migrazione dei node pool

Per eseguire la migrazione di tutti i pool di nodi:

  1. Apporta le seguenti modifiche al file di configurazione del cluster utente:

    • Imposta ogni campo nodePools[i].vsphere.storagePolicyName con il nome del criterio di archiviazione.
    • Elimina o inserisci un commento in ogni campo nodePools[i].vsphere.datastore.

    Le seguenti configurazioni di esempio mostrano queste modifiche.

    Prima delle modifiche:

    nodepools:
- name: pool-1
  vsphere:
    datastore: ds-1
- name: pool-2
  vsphere:
    datastore: ds-1

    Dopo le modifiche:

    nodepools:
- name: pool-1
  vsphere:
    # datastore: ds-1
    storagePolicyName: sp-1
- name: pool-2
  vsphere:
    # datastore: ds-1
    storagePolicyName: sp-1

  2. Aggiorna il cluster utente:

    gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG

Se vuoi, aggiorna il criterio di archiviazione a livello di cluster

Per i cluster di utenti, i campi datastore e storagePolicyName nella sezione vCenter a livello di cluster sono un valore predefinito utilizzato dalle sezioni masterNode e nodepools. Dopo aver completato i passaggi precedenti, le impostazioni vCenter datastore e storagePolicyName a livello di cluster non verranno utilizzate da nessun componente del cluster. Puoi lasciare invariata la sezione vCenter a livello di cluster o aggiornarla in modo che sia coerente con masterNode e nodepools.

Se lasci l'impostazione così com'è, ti consigliamo di aggiungere un commento sopra la sezione vCenter a livello di cluster che indichi che l'impostazione viene ignorata perché sostituita dalle impostazioni nelle sezioni masterNode e nodepools.

Se preferisci, puoi modificare la sezione vCenter a livello di cluster in modo che corrisponda alle sezioni masterNode e nodepools e aggiornare il cluster seguendo questi passaggi:

  1. Modifica il file di configurazione del cluster utente come segue:

    • Imposta il campo vCenter.storagePolicyName con il nome del criterio di archiviazione.
    • Rimuovi o inserisci un commento nel campo vCenter.datastore.

  2. Aggiorna il cluster utente:

    gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG

    Questo comando di aggiornamento non apporta modifiche al cluster, ma aggiorna i campi lato server (OnPremUserCluster) vCenter.datastore e vCenter.storagePolicyName.

Aggiornare StorageClass in bundle

Dopo aver aggiornato le impostazioni di configurazione, devi aggiornare il StorageClass incluso.

  1. Recupera il StorageClass predefinito corrente per il vsphere-csi-driver incluso, denominato standard-rwo, e salvalo in un file locale denominato storage-class.yaml.

    kubectl get storageclass standard-rwo -oyaml \
    --kubeconfig USER_CLUSTER_KUBECONFIG > storage-class.yaml

    Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster utente.

  2. Crea una copia di storage-class.yaml per precauzione, poiché dovrai apportare modifiche al file:

    cp storage-class.yaml storage-class.yaml-backup.yaml

  3. Elimina StorageClass predefinito dal cluster:

    kubectl delete storageclass standard-rwo \
    --kubeconfig USER_CLUSTER_KUBECONFIG

  4. Aggiorna la configurazione in storage-class.yaml come segue:

    1. Elimina o inserisci un commento nei seguenti campi:

      • parameters.datastoreURL
      • resourceVersion

    2. Aggiungi il campo parameters.storagePolicyName e impostalo sul nome del criterio di archiviazione.

    Le seguenti configurazioni di esempio mostrano queste modifiche.

    Prima delle modifiche:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  datastoreURL: ds//ds-1

    Dopo le modifiche:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  storagePolicyName: sp-1

  5. Applica StorageClass modificato al cluster utente:

    kubectl apply -f storage-class.yaml \
    --kubeconfig USER_CLUSTER_KUBECONFIG

Solo cluster di utenti Kubeception

Per i cluster utente Kubeception, devi aggiornare StorageClass per i nodi del piano di controllo del cluster utente nel cluster di amministrazione. I cluster Kubeception hanno il campo di configurazione enableControlplaneV2 impostato su false. Quando il control plane v2 è abilitato, il control plane per il cluster utente viene eseguito nel cluster utente stesso. Quando il control plane v2 non è abilitato, il control plane per il cluster utente viene eseguito nel cluster di amministrazione, operazione nota come kubeception.

Esegui il seguente comando per determinare se nel cluster è attivato Controlplane V2:

kubectl get onpremuserclusters --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system -o jsonpath='{.items[0].spec.enableControlplaneV2}' && echo

Se l'output è false, completa i seguenti passaggi per aggiornare il valore predefinito StorageClass per i nodi del piano di controllo del cluster utente nel cluster di amministrazione:

  1. Recupera il StorageClass predefinito corrente per il vsphere-csi-driver incluso, denominato USER_CLUSTER_NAME-csi, e salvalo in un file locale denominato storage-class-kubeception.yaml.

    kubectl get storageclass USER_CLUSTER_NAME-csi -oyaml \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG > storage-class-kubeception.yaml

    Sostituisci ADMIN_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione.

  2. Crea una copia di storage-class-kubeception.yaml per precauzione, poiché devi apportare modifiche al file:

    cp storage-class-kubeception.yaml storage-class-kubeception-backup.yaml

  3. Elimina StorageClass predefinito dal cluster:

    kubectl delete storageclass USER_CLUSTER_NAME-csi \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  4. Aggiorna la configurazione in storage-class-kubeception.yaml come segue:

    1. Elimina o inserisci un commento nei seguenti campi:

      • parameters.datastoreURL
      • resourceVersion

    2. Aggiungi il campo parameters.storagePolicyName e impostalo sul nome del criterio di archiviazione.

    Le seguenti configurazioni di esempio mostrano queste modifiche.

    Prima delle modifiche:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  datastoreURL: ds//ds-1

    Dopo le modifiche:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  storagePolicyName: sp-1

  5. Applica StorageClass modificato al cluster di amministrazione:

    kubectl apply -f storage-class-kubeception.yaml \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Esegui la migrazione di un cluster di amministrazione

Assicurati che anche il cluster di amministrazione sia aggiornato con il nome del criterio di archiviazione.

  1. Apporta le seguenti modifiche al file di configurazione del cluster di amministrazione:

    • Rimuovi o inserisci un commento nel campo vCenter.datastore.
    • Imposta il campo vCenter.storagePolicyName con il nome del criterio di archiviazione.

  2. Aggiorna il cluster di amministrazione:

    gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config ADMIN_CLUSTER_CONFIG

    Sostituisci quanto segue:

    • ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
    • ADMIN_CLUSTER_CONFIG: il percorso del file di configurazione del cluster di amministrazione.

Migrazione dello spazio di archiviazione con SPBM

Dopo la migrazione del datastore a SPBM, i tuoi cluster ora utilizzano SPBM. Tuttavia, la migrazione non sposta i workload di archiviazione (ad esempio i dischi di dati della macchina o i volumi dei contenitori) dal vecchio datastore.

Per spostare i carichi di lavoro di archiviazione, consulta Migrazione dello spazio di archiviazione con la gestione basata su criteri di archiviazione.