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 è dedicata agli esperti di archiviazione che configurano e gestiscono le prestazioni, l'utilizzo e le spese di archiviazione. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli utente e attività comuni di GKE.

1.30: GA
1.29: 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à per 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 una policy di archiviazione:

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

Prima di iniziare

  • Questa procedura è una migrazione unidirezionale. Non supportiamo la migrazione allo stato precedente.
  • Il datastore deve essere compatibile con la nuova norma di archiviazione che imposterai.
  • Sono supportati solo i cluster di amministrazione ad alta disponibilità (HA). Se il tuo cluster di amministrazione non è HA, devi prima migrare il cluster di amministrazione ad HA.

Migrazione di un cluster utente

I passaggi utilizzati per la migrazione dipendono dal fatto che tu voglia eseguire la migrazione dell'intero cluster utente o se vuoi eseguire la migrazione separata dei nodi del control plane e dei pool di nodi worker. Questa opzione ti consente di selezionare criteri di archiviazione diversi per i nodi del control plane e i pool di nodi worker.

Per pianificare una periodo di manutenzione, tieni presente quanto segue:

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

  • La migrazione separata dei nodi del control plane e dei pool di nodi worker 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 1.30 o successive.

  1. Modifica il file di configurazione del cluster utente nel seguente modo:

    1. Imposta il campo vCenter.storagePolicyName con il nome della policy di archiviazione.

    2. Rimuovi o commenta 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.

Aggiorna StorageClass incluso

Dopo aver aggiornato le impostazioni di configurazione nel cluster, devi aggiornare StorageClass in bundle.

  1. Recupera l'StorageClass predefinito corrente per vsphere-csi-driver in bundle, 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é devi 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 nel seguente modo:

    1. Elimina o commenta i seguenti campi:

      • parameters.datastoreURL
      • resourceVersion

    2. Aggiungi il campo parameters.storagePolicyName e impostalo sul nome della norma 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 il StorageClass modificato al cluster utente:

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

Solo cluster utente Kubeception

Per i cluster utente Kubeception, devi aggiornare StorageClass per i nodi del control plane del cluster utente nel cluster di amministrazione. I cluster Kubeception hanno il campo di configurazione enableControlplaneV2 impostato su false. Quando Controlplane V2 è abilitato, il control plane per il cluster utente viene eseguito nel cluster utente stesso. Se Controlplane V2 non è abilitato, il control plane per il cluster utente viene eseguito nel cluster di amministrazione, che viene chiamato kubeception.

Esegui questo comando per determinare se Controlplane V2 è abilitato nel cluster:

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 control plane del cluster utente nel cluster di amministrazione:

  1. Recupera l'StorageClass predefinito corrente per vsphere-csi-driver in bundle, denominato USER_CLUSTER_NAME-csi, e salvalo in un file locale chiamato 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 nel seguente modo:

    1. Elimina o commenta i seguenti campi:

      • parameters.datastoreURL
      • resourceVersion

    2. Aggiungi il campo parameters.storagePolicyName e impostalo sul nome della norma 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 il file 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 di aver 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.datastoreche nodePools[i].vsphere.storagePolicyName, il nuovo pool di nodi eredita la policy di archiviazione specificata in vCenter.storagePolicyName.

Nodi separatamente

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

  1. Solo versione 1.29: ottieni la configurazione attuale del cluster. Questo passaggio non è necessario se il cluster utente ha la versione 1.30 o successive.

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

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

    Per ulteriori informazioni su come ottenere il file di configurazione, vedi Generare 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 control plane) 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

Migra i nodi del control plane

Per eseguire la migrazione dei nodi del control plane:

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

    • Imposta il campo masterNode.vsphere.storagePolicyName con il nome della policy di archiviazione.
    • Elimina o commenta il 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 della policy di archiviazione.
    • Elimina o commenta 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

(Facoltativo) Aggiorna le norme relative allo spazio 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 alcun componente del cluster. Puoi lasciare la sezione vCenter a livello di cluster così com'è 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 indica che l'impostazione viene ignorata perché viene sostituita dalle impostazioni nelle sezioni masterNode e nodepools.

Se preferisci, puoi modificare la sezione vCenter del livello del cluster in modo che corrisponda alle sezioni masterNode e nodepools e aggiornare il cluster seguendo questa procedura:

  1. Modifica il file di configurazione del cluster utente nel seguente modo:

    • Imposta il campo vCenter.storagePolicyName con il nome della policy di archiviazione.
    • Rimuovi o commenta il campo vCenter.datastore.

  2. Aggiorna il cluster utente:

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

    Questo comando di aggiornamento non apporterà modifiche al cluster, ma aggiornerà i campi OnPremUserCluster, vCenter.datastore e vCenter.storagePolicyName lato server.

Aggiorna StorageClass incluso

Dopo aver aggiornato le impostazioni di configurazione, devi aggiornare StorageClass in bundle.

  1. Recupera l'StorageClass predefinito corrente per vsphere-csi-driver in bundle, 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é devi 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 nel seguente modo:

    1. Elimina o commenta i seguenti campi:

      • parameters.datastoreURL
      • resourceVersion

    2. Aggiungi il campo parameters.storagePolicyName e impostalo sul nome della norma 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 il StorageClass modificato al cluster utente:

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

Solo cluster utente Kubeception

Per i cluster utente Kubeception, devi aggiornare StorageClass per i nodi del control plane del cluster utente nel cluster di amministrazione. I cluster Kubeception hanno il campo di configurazione enableControlplaneV2 impostato su false. Quando Controlplane V2 è abilitato, il control plane per il cluster utente viene eseguito nel cluster utente stesso. Se Controlplane V2 non è abilitato, il control plane per il cluster utente viene eseguito nel cluster di amministrazione, che viene chiamato kubeception.

Esegui questo comando per determinare se Controlplane V2 è abilitato nel cluster:

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 control plane del cluster utente nel cluster di amministrazione:

  1. Recupera l'StorageClass predefinito corrente per vsphere-csi-driver in bundle, denominato USER_CLUSTER_NAME-csi, e salvalo in un file locale chiamato 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 nel seguente modo:

    1. Elimina o commenta i seguenti campi:

      • parameters.datastoreURL
      • resourceVersion

    2. Aggiungi il campo parameters.storagePolicyName e impostalo sul nome della norma 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 il file 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 venga aggiornato con il nome della policy di archiviazione.

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

    • Rimuovi o commenta il campo vCenter.datastore.
    • Imposta il campo vCenter.storagePolicyName con il nome della policy 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 (come i dischi di dati della macchina o i volumi dei container) dal vecchio datastore.

Per spostare i carichi di lavoro di archiviazione, vedi Migrazione dell'archiviazione con la gestione basata su criteri di archiviazione.