Migrar o repositório de dados para o SPBM

Este documento mostra como migrar um repositório de dados do vSphere para o gerenciamento baseado em políticas de armazenamento (SPBM, na sigla em inglês).

Esta página é destinada a especialistas em armazenamento que configuram e gerenciam o desempenho, o uso e os gastos de armazenamento. Para saber mais sobre papéis comuns e tarefas de exemplo referenciados no conteúdo do Google Cloud , consulte Tarefas e funções de usuário comuns do GKE.

1.30: GA
1.29: pré-lançamento
1.16 e versões anteriores: não disponível

Contexto

Há quatro lugares em que você pode especificar um repositório de dados em arquivos de configuração do cluster:

A herança desses campos é a seguinte:

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

Exemplos:

  • Se userCluster.vCenter.datastore estiver vazio, ele herda o valor de adminCluster.vCenter.datastore.

  • Se userCluster.nodePools[i].vsphere.datastore estiver vazio, ele herda o valor de userCluster.vCenter.datastore.

Da mesma forma, há quatro lugares para especificar uma política de armazenamento:

A herança dos campos storagePolicyName é igual à dos campos datastore.

Antes de começar

  • Esse processo é uma migração unidirecional. Não é possível migrar de volta para o estado anterior.
  • O armazenamento de dados precisa ser compatível com a nova política de armazenamento que você vai definir.
  • Somente clusters de administrador de alta disponibilidade (HA) são compatíveis. Se o cluster de administrador não for HA, primeiro migre o cluster de administrador para HA.

Migrar um cluster de usuário

As etapas usadas para a migração dependem se você quer migrar todo o cluster de usuário ou se quer migrar os nós do plano de controle e os pools de nós de trabalho separadamente. Com essa opção, é possível selecionar políticas de armazenamento diferentes para nós do plano de controle e pools de nós de trabalho.

Para ajudar no planejamento de uma janela de manutenção, observe o seguinte:

  • Migrar todo o cluster requer apenas uma atualização.

  • Migrar os nós do plano de controle e os pools de nós de trabalho separadamente exige duas atualizações de cluster.

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

Migrar um cluster de administrador

Verifique se o cluster de administrador também está atualizado com o nome da política de armazenamento.

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

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

  2. Atualize o cluster de administrador:

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

    Substitua:

    • ADMIN_CLUSTER_KUBECONFIG: o caminho até o arquivo kubeconfig do cluster de administrador.
    • ADMIN_CLUSTER_CONFIG: o caminho até o arquivo de configuração do cluster de administrador.

Migração de armazenamento com o SPBM

Após a migração do repositório de dados para o SPBM, seus clusters vão usar o SPBM. No entanto, a migração não move nenhuma carga de trabalho de armazenamento (como discos de dados de máquinas ou volumes de contêineres) do armazenamento de dados antigo.

Para mover cargas de trabalho de armazenamento, consulte Migração do armazenamento com o gerenciamento baseado em políticas de armazenamento.