Migração de armazenamento com o gerenciamento baseado em políticas de armazenamento

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, na sigla em inglês).

1.29: disponibilidade geral
1.28: visualização
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 clusters de usuário do Controlplane V2

    • Discos de inicialização (arquivos VMDK) usados por todos os clusters de administrador e nós de cluster 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 kubeception

  • Armazenamento para cargas de trabalho implantadas em nós de trabalho do cluster de usuário com PV/PVCs provisionados pelo plug-in de volume do vSphere em árvore ou pelo driver CSI do vSphere

Pré-requisitos para um cluster de administrador

  1. 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 seja de alta disponibilidade, migre para alta disponibilidade antes de continuar.

  2. 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, verifique se são exibidos 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 (administrador e usuário)

  1. O cluster precisa estar com o reparo automático de nós desativado. Se o reparo automático de nós estiver ativado, desative esse recurso.

  2. O cluster precisa usar o gerenciamento baseado em políticas de armazenamento (SPBM, na sigla em inglês). Se o cluster não usar o SPBM, crie uma política de armazenamento antes de continuar.

  3. 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 (administrador ou usuário).

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

    • USER_CLUSTER_NAME: o nome do cluster do usuário

    Na saída, se o campo datastore estiver vazio e o campo storagePolicyName não estiver vazio, isso significa que o cluster está usando o SPBM.

  4. O cluster não pode usar o plug-in de volume na á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 na á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 criada em um nó de trabalho.

    Lista de todos os PVCs e as 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 veja quais provisionadores estão usando:

    kubectl --kubeconfig CLUSTER_KUBECONFIG get storageclass
    

    Na saída, se a coluna PROVISIONER for kubernetes.io/vsphere-volume, os PVCs criados com esse StorageClass estão usando o plug-in de volume na á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 oferece suporte a duas categorias de migração de armazenamento:

  • Storage vMotion para VMs, que move o armazenamento de VM, incluindo volumes de CNS do vSphere anexados usados por pods em execução em um nó e VMDKs usados por esses volumes de CNS de VM anexados aos nós

  • Realocação de volume de CNS, que move volumes especificados do vSphere CNS para um repositório de dados compatível sem realizar o vMotion de armazenamento para VMs

Executar vMotion de armazenamento para VMs

A migração envolve etapas executadas no ambiente do vSphere e comandos executados na estação de trabalho do administrador:

  1. No ambiente do vSphere, adicione os repositórios de dados de destino à política de armazenamento.

  2. No ambiente do vSphere, migre as VMs de cluster usando o repositório de dados antigo para o novo. Para mais instruções, consulte Migrar uma máquina virtual para um novo recurso de computação e armazenamento.

  3. Na estação de trabalho do administrador, verifique se as VMs foram migradas para o novo repositório de dados.

    Consiga os objetos Machine no cluster:

    kubectl --kubeconfig CLUSTER_KUBECONFIG get machines --output yaml

    Na saída, em status.disks, é possível ver 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 armazenamento de dados de destino.

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

Se você quiser mover apenas os volumes de 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 se você tiver apenas volumes CNS no repositório de dados antigo.

Atualizar sua 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 poderão ser atribuídos a um repositório de dados antigo.