Neste documento, mostramos como migrar discos de um repositório de dados do vSphere para outro com o gerenciamento baseado em políticas de armazenamento (SPBM):
1.29: disponibilidade geral
1.28: pré-lançamento
1.16: não disponível
É possível migrar os seguintes tipos de armazenamento:
Armazenamento para componentes do sistema gerenciados pelo Google Distributed Cloud, incluindo:
Discos de dados (arquivos VMDK) usados pelos nós do plano de controle dos clusters de administrador e de usuário do Controlplane V2
Discos de inicialização (arquivos VMDK) usados por todos os nós dos clusters de administrador e de usuário
Volumes do vSphere representados por PV/PVCs no cluster de administrador e usados pelos componentes do plano de controle dos clusters de usuário do kubeception
Armazenamento para cargas de trabalho que você implanta em nós de trabalho do cluster de usuário com PV/PVCs provisionados pelo plug-in de volume em árvore do vSphere ou pelo driver CSI do vSphere
Pré-requisitos para um cluster de administrador
O cluster de administrador precisa ter um plano de controle de alta disponibilidade. Se o cluster de administrador tiver um plano de controle que não é de alta disponibilidade, migre para a alta disponibilidade antes de continuar.
Verifique se o cluster de administrador tem um plano de controle de alta disponibilidade:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes
Substitua ADMIN_CLUSTER_KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster de administrador.
Na saída, confira se há três nós do plano de controle. Exemplo:
admin-cp-1 Ready control-plane,master ... admin-cp-2 Ready control-plane,master ... admin-cp-3 Ready control-plane,master ...
Pré-requisitos para todos os clusters (de administrador e de usuário)
O reparo automático de nós do cluster precisa estar desativado. Se o reparo automático de nós estiver ativado, desative o reparo automático de nós.
O cluster precisa usar o gerenciamento baseado em políticas de armazenamento (SPBM). Se o cluster não usar o SPBM, crie uma política de armazenamento antes de continuar.
Verifique se o cluster usa o SPBM:
kubectl --kubeconfig CLUSTER_KUBECONFIG get onpremadmincluster --namespace kube-system \ -ojson | jq '{datastore: .items[0].spec.vCenter.datastore, storagePolicyName: .items[0].spec.vCenter.storagePolicyName}'
(Somente cluster de usuário) Verifique se os pools de nós usam o 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}'
Substitua:
CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster (de administrador ou de usuário).
ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador
USER_CLUSTER_NAME: o nome do cluster de usuário
Na saída, quando o campo
datastore
está vazio e o campostoragePolicyName
não está, isso significa que o cluster está usando o SPBM.O cluster não pode usar o plug-in de volume em árvore do vSphere.
Se o cluster foi atualizado de uma versão antiga do Google Distributed Cloud, ele pode ter PV/PVCs provisionados pelo plug-in de volume em árvore do vSphere. Esse tipo de volume pode estar em uso por um nó do plano de controle de um cluster de usuário do kubeception ou por uma carga de trabalho que você criou em um nó de trabalho.
Lista de todos os PVCs e as respectivas StorageClasses:
kubectl --kubeconfig CLUSTER_KUBECONFIG get pvc --all-namespaces \ -ojson | jq '.items[] | {namespace: .metadata.namespace, name: .metadata.name, storageClassName: .spec.storageClassName}'
Liste todas as StorageClasses e confira quais provisionadores elas estão usando:
kubectl --kubeconfig CLUSTER_KUBECONFIG get storageclass
Na saída, se a coluna
PROVISIONER
forkubernetes.io/vsphere-volume
, os PVCs criados com essa StorageClass vão usar o plug-in de volume em árvore do vSphere. No caso dos StatefulSets que usam esses PV/PVCs, migre-os para o driver CSI do vSphere.
Executar a migração do armazenamento
O Google Distributed Cloud dá suporte a duas categorias de migração de armazenamento:
vMotion de armazenamento para VMs, que move o armazenamento de VMs, incluindo os volumes CNS do vSphere anexados usados por pods em execução em um nó, e os VMDKs usados por esses volumes CNS de VM anexados aos nós
Realocação de volumes CNS, que move volumes CNS do vSphere especificados para um repositório de dados compatível sem executar o vMotion de armazenamento para VMs
Executar o vMotion de armazenamento para VMs
A migração envolve etapas que você executa no ambiente do vSphere e comandos que você executa na estação de trabalho de administrador:
No ambiente do vSphere, adicione os repositórios de dados de destino à política de armazenamento.
No ambiente do vSphere, migre as VMs do cluster usando o repositório de dados antigo para o novo repositório de dados. Para conferir instruções, consulte Migrar uma máquina virtual para um novo recurso de computação e um novo armazenamento.
Na estação de trabalho do administrador, verifique se as VMs foram migradas para o novo repositório de dados.
Acesse os objetos de máquina no cluster:
kubectl --kubeconfig CLUSTER_KUBECONFIG get machines --output yaml
Na saída, em
status.disks
, é possível conferir os discos anexados às VMs. Exemplo: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
Verifique se todos os discos de todas as máquinas no cluster foram migrados para o repositório de dados de destino.
Na estação de trabalho do administrador, execute
gkectl diagnose
para verificar se o cluster está íntegro.
Chamar APIs de realocação de CNS para mover volumes de CNS
Para mover apenas volumes CNS provisionados pelo driver CSI do vSphere, siga as instruções em Como migrar volumes de contêiner no vSphere. Isso pode ser mais simples quando você tem apenas volumes CNS no repositório de dados antigo.
Atualize a política de armazenamento, se necessário
No ambiente do vSphere, atualize a política de armazenamento para excluir os repositórios de dados antigos. Caso contrário, novos volumes e VMs recriadas podem ser atribuídos a um repositório de dados antigo.