Migrar o repositório de dados para o SPBM

Todo o cluster

Use estas etapas se quiser migrar todo o cluster, incluindo todos os nós do plano de controle e pools de nós de trabalho. A versão do cluster de usuário precisa ser 1.30 ou mais recente.

1. Modifique o arquivo de configuração do cluster de usuário da seguinte maneira:

   1. Defina o campo vCenter.storagePolicyName com o nome da política de armazenamento.

   2. Remova ou comente o seguinte, se especificado:

      • Campo vCenter.datastore
      • Seção masterNode.vsphere
      • nodepools[i].vsphere.datastore
      • nodepools[i].vsphere.storagePolicyName

   As configurações de exemplo a seguir mostram essas mudanças.

   Antes das mudanças:

   vCenter:
     datastore: ds-1
   

   Depois das mudanças:

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

2. Atualize o cluster de usuário:

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

   Substitua:

   • ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador

   • USER_CLUSTER_CONFIG: o caminho do arquivo de configuração do cluster de usuário.

Atualizar o StorageClass agrupado

Depois de atualizar as configurações no cluster, é necessário atualizar o StorageClass agrupado.

1. Receba o StorageClass padrão atual para o vsphere-csi-driver agrupado, que é chamado de standard-rwo, e salve-o em um arquivo local chamado storage-class.yaml.

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

   Substitua USER_CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster de usuário.

2. Faça uma cópia de storage-class.yaml como precaução, já que você precisa fazer mudanças no arquivo:

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

3. Exclua o StorageClass padrão do cluster:

   kubectl delete storageclass standard-rwo \
       --kubeconfig USER_CLUSTER_KUBECONFIG
   

4. Atualize a configuração em storage-class.yaml da seguinte forma:

   1. Exclua ou comente os seguintes campos:

      • parameters.datastoreURL
      • resourceVersion

   2. Adicione o campo parameters.storagePolicyName e defina-o como o nome da política de armazenamento.

   As configurações de exemplo a seguir mostram essas mudanças.

   Antes das mudanças:

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

   Depois das mudanças:

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

5. Aplique o StorageClass modificado ao cluster de usuário:

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

Somente clusters de usuário do Kubeception

Para clusters de usuário do Kubeception, é necessário atualizar o StorageClass dos nós do plano de controle do cluster de usuário no cluster de administrador. Os clusters Kubeception têm o campo de configuração enableControlplaneV2 definido como false. Quando o Controlplane V2 está ativado, o plano de controle do cluster de usuário é executado no próprio cluster. Quando o Controlplane V2 não está ativado, o plano de controle do cluster de usuário é executado no cluster de administrador, o que é chamado de kubeception.

Execute o comando a seguir para determinar se o cluster tem o Controlplane V2 ativado:

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

Se a saída for false, siga estas etapas para atualizar o StorageClass padrão dos nós do plano de controle do cluster de usuário no cluster de administrador:

1. Receba o StorageClass padrão atual para o vsphere-csi-driver agrupado, que é chamado de USER_CLUSTER_NAME-csi, e salve-o em um arquivo local chamado storage-class-kubeception.yaml.

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

   Substitua ADMIN_CLUSTER_KUBECONFIG pelo caminho do kubeconfig do cluster de administrador.

2. Faça uma cópia de storage-class-kubeception.yaml como precaução, já que você precisa fazer mudanças no arquivo:

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

3. Exclua o StorageClass padrão do cluster:

   kubectl delete storageclass USER_CLUSTER_NAME-csi \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

4. Atualize a configuração em storage-class-kubeception.yaml da seguinte forma:

   1. Exclua ou comente os seguintes campos:

      • parameters.datastoreURL
      • resourceVersion

   2. Adicione o campo parameters.storagePolicyName e defina-o como o nome da política de armazenamento.

   As configurações de exemplo a seguir mostram essas mudanças.

   Antes das mudanças:

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

   Depois das mudanças:

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

5. Aplique o StorageClass modificado ao cluster de administrador:

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

Após a migração

Se você criar um novo pool de nós após uma migração, ele vai seguir as regras de herança de acordo com o cluster atualizado.

Por exemplo, suponha que você tenha migrado vCenter.datastore para uma política de armazenamento.

Agora, se você criar um novo pool de nós e deixar nodePools[i].vsphere.datastore e nodePools[i].vsphere.storagePolicyName vazios, o novo pool de nós herda a política de armazenamento especificada em vCenter.storagePolicyName.

Nós separadamente

Use estas etapas se quiser migrar os nós do plano de controle e os pools de nós de trabalho separadamente.

1. Somente versão 1.29: confira a configuração atual do cluster. Essa etapa não é necessária se o cluster de usuário estiver na versão 1.30 ou mais recente.

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

   Substitua:

   • ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.

   • USER_CLUSTER_NAME: o nome do cluster do usuário.

   No ./gen-files, localize user-cluster.yaml.

   Para mais informações sobre como acessar o arquivo de configuração, consulte Gerar arquivos de configuração de um cluster.

   O arquivo de configuração gerado tem o nome datastore definido em cada nível: cluster, masterNode (para nós do plano de controle) e nodepools (para nós de trabalho), conforme mostrado no exemplo a seguir:

   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
   

Migrar nós do plano de controle

Siga estas etapas para migrar os nós do plano de controle:

1. Faça as seguintes mudanças no arquivo de configuração do cluster de usuário:

   • Defina o campo masterNode.vsphere.storagePolicyName com o nome da política de armazenamento.
   • Exclua ou comente o campo masterNode.vsphere.datastore.

   As configurações de exemplo a seguir mostram essas mudanças.

   Antes das mudanças:

   masterNode:
     vsphere:
       datastore: ds-1
   

   Depois das mudanças:

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

2. Atualize o cluster de usuário:

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

   Substitua:

   • ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador

   • USER_CLUSTER_CONFIG: o caminho do arquivo de configuração do cluster de usuário.

   Aguarde a conclusão do comando de atualização antes de atualizar os pools de nós.

Migrar pools de nós

Siga estas etapas para migrar todos os pools de nós:

1. Faça as seguintes mudanças no arquivo de configuração do cluster de usuário:

   • Defina cada campo nodePools[i].vsphere.storagePolicyName com o nome da política de armazenamento.
   • Exclua ou comente cada campo nodePools[i].vsphere.datastore.

   As configurações de exemplo a seguir mostram essas mudanças.

   Antes das mudanças:

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

   Depois das mudanças:

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

2. Atualize o cluster de usuário:

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

Se quiser, atualize a política de armazenamento no nível do cluster

Para clusters de usuários, os campos datastore e storagePolicyName na seção vCenter no nível do cluster são um valor padrão usado pelas seções masterNode e nodepools. Depois de concluir as etapas anteriores, as configurações de vCenter datastore e storagePolicyName no nível do cluster não serão usadas por nenhum componente do cluster. Você pode deixar a seção vCenter no nível do cluster como está ou atualizá-la para que seja consistente com masterNode e nodepools.

Se você deixar a configuração como está, recomendamos adicionar um comentário acima da seção vCenter no nível do cluster informando que a configuração é ignorada porque é substituída pelas configurações nas seções masterNode e nodepools.

Se preferir, mude a seção vCenter no nível do cluster para corresponder às seções masterNode e nodepools e atualize o cluster seguindo estas etapas:

1. Modifique o arquivo de configuração do cluster de usuário da seguinte maneira:

   • Defina o campo vCenter.storagePolicyName com o nome da política de armazenamento.
   • Remova ou comente o campo vCenter.datastore.

2. Atualize o cluster de usuário:

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

   Esse comando de atualização não fará mudanças no cluster, mas vai atualizar os campos vCenter.datastore e vCenter.storagePolicyName do lado do servidor (OnPremUserCluster).

Atualizar o StorageClass agrupado

Depois de atualizar as configurações, é necessário atualizar o StorageClass agrupado.

1. Receba o StorageClass padrão atual para o vsphere-csi-driver agrupado, que é chamado de standard-rwo, e salve-o em um arquivo local chamado storage-class.yaml.

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

   Substitua USER_CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster de usuário.

2. Faça uma cópia de storage-class.yaml como precaução, já que você precisa fazer mudanças no arquivo:

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

3. Exclua o StorageClass padrão do cluster:

   kubectl delete storageclass standard-rwo \
       --kubeconfig USER_CLUSTER_KUBECONFIG
   

4. Atualize a configuração em storage-class.yaml da seguinte forma:

   1. Exclua ou comente os seguintes campos:

      • parameters.datastoreURL
      • resourceVersion

   2. Adicione o campo parameters.storagePolicyName e defina-o como o nome da política de armazenamento.

   As configurações de exemplo a seguir mostram essas mudanças.

   Antes das mudanças:

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

   Depois das mudanças:

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

5. Aplique o StorageClass modificado ao cluster de usuário:

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

Somente clusters de usuário do Kubeception

Para clusters de usuário do Kubeception, é necessário atualizar o StorageClass dos nós do plano de controle do cluster de usuário no cluster de administrador. Os clusters Kubeception têm o campo de configuração enableControlplaneV2 definido como false. Quando o Controlplane V2 está ativado, o plano de controle do cluster de usuário é executado no próprio cluster. Quando o Controlplane V2 não está ativado, o plano de controle do cluster de usuário é executado no cluster de administrador, o que é chamado de kubeception.

Execute o comando a seguir para determinar se o cluster tem o Controlplane V2 ativado:

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

Se a saída for false, siga estas etapas para atualizar o StorageClass padrão dos nós do plano de controle do cluster de usuário no cluster de administrador:

1. Receba o StorageClass padrão atual para o vsphere-csi-driver agrupado, que é chamado de USER_CLUSTER_NAME-csi, e salve-o em um arquivo local chamado storage-class-kubeception.yaml.

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

   Substitua ADMIN_CLUSTER_KUBECONFIG pelo caminho do kubeconfig do cluster de administrador.

2. Faça uma cópia de storage-class-kubeception.yaml como precaução, já que você precisa fazer mudanças no arquivo:

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

3. Exclua o StorageClass padrão do cluster:

   kubectl delete storageclass USER_CLUSTER_NAME-csi \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

4. Atualize a configuração em storage-class-kubeception.yaml da seguinte forma:

   1. Exclua ou comente os seguintes campos:

      • parameters.datastoreURL
      • resourceVersion

   2. Adicione o campo parameters.storagePolicyName e defina-o como o nome da política de armazenamento.

   As configurações de exemplo a seguir mostram essas mudanças.

   Antes das mudanças:

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

   Depois das mudanças:

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

5. Aplique o StorageClass modificado ao cluster de administrador:

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