Os clusters do Anthos no VMware agora são o Google Distributed Cloud (somente software) para VMware. Para mais informações, consulte a visão geral do produto.

Esta página foi traduzida pela API Cloud Translation.

Migrar um cluster de usuário para o Controlplane V2

Neste documento, mostramos como migrar um cluster de usuário da versão 1.29 usando o kubeception para o Controlplane V2. Se os clusters estiverem na versão 1.30 ou mais recente, recomendamos que você siga as instruções em Planejar a migração de clusters para recursos recomendados.

1.29: prévia
1.28: indisponível

Sobre os planos de controle do cluster de usuários

Antes da versão 1.13 do Google Distributed Cloud, o plano de controle de um cluster de usuário era executado em um ou mais nós em um cluster de administrador. Esse tipo de plano de controle é conhecido como kubeception. Na versão 1.13, o Controlplane V2 foi introduzido para novos clusters de usuário. Quando o Controlplane V2 está ativado, o plano de controle do cluster de usuário é executado no próprio cluster de usuário.

Os benefícios do Controlplane V2 incluem:

Isolamento de falhas. Uma falha no cluster de administrador não afeta os clusters de usuário.
Separação operacional. Um upgrade do cluster de administrador não causa inatividade para clusters de usuário.
Separação de implantação. É possível colocar os clusters de administrador e de usuário em diferentes domínios de falha ou locais geográficos. Por exemplo, um cluster de usuário em um local de borda pode estar em um local geográfico diferente do cluster de administrador.

Requisitos

Para migrar um cluster de usuário para o Controlplane V2, ele precisa atender aos seguintes requisitos:

O cluster de usuário precisa estar na versão 1.29 ou mais recente. O cluster de administrador e os pools de nós podem ter uma ou duas versões secundárias anteriores ao cluster de usuário. Se necessário, faça upgrade do cluster.
O cluster de usuário precisa ter o Dataplane V2 ativado. Esse campo é imutável. Portanto, se o Dataplane V2 não estiver ativado no cluster, não será possível migrá-lo para o Controlplane V2.
O cluster de usuário precisa ser configurado para usar o MetalLB ou um balanceador de carga manual. Se o cluster de usuários estiver usando o balanceador de carga SeeSaw, é possível migrar para o MetalLB.
Consulte o documento de planejamento de endereços IP e verifique se você tem endereços IP suficientes disponíveis para os nós do plano de controle do cluster de usuário. Os nós do plano de controle exigem endereços IP estáticos, e você vai precisar de um endereço IP adicional para um novo IP virtual (VIP) do plano de controle.

Prepare-se para a migração

Se a criptografia de secrets sempre ativada tiver sido ativada no cluster de usuários, siga as etapas em Desativar a criptografia de secrets sempre ativada e descriptografar secrets antes de iniciar a migração. Caso contrário, o novo cluster do Controlplane V2 não conseguirá descriptografar segredos.

Antes de iniciar a migração, execute o comando abaixo para saber se a criptografia de secrets sempre ativa foi ativada em algum momento:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  get onpremusercluster USER_CLUSTER_NAME \
  -n USER_CLUSTER_NAME-gke-onprem-mgmt \
  -o jsonpath={.spec.secretsEncryption}

Se a saída do comando anterior estiver vazia, a criptografia de secrets sempre ativada nunca foi ativada. Você pode iniciar a migração.

Se a saída do comando anterior não estiver vazia, a criptografia de secrets sempre ativada foi ativada anteriormente. Antes de migrar, siga as etapas na próxima seção para garantir que o novo cluster do Controlplane V2 possa descriptografar secrets.

O exemplo a seguir mostra uma saída não vazia:

{"generatedKeyVersions":{"keyVersions":[1]}}

Desativar a criptografia de secrets sempre ativada e descriptografar secrets, se necessário

Para desativar a criptografia de secrets sempre ativada e descriptografar secrets, siga estas etapas:

No arquivo de configuração do cluster de usuário, para desativar a criptografia de segredos sempre ativa, adicione um campo disabled: true à seção secretsEncryption:
```
secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: true
```
Atualize o cluster:
```
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

Faça uma atualização gradual em um DaemonSet específico, da seguinte maneira:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  rollout restart statefulsets kube-apiserver \
  -n USER_CLUSTER_NAME

Receba os manifestos de todos os segredos no cluster de usuários no formato YAML:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  get secrets -A -o yaml > SECRETS_MANIFEST.yaml

Para que todos os secrets sejam armazenados no etcd como texto simples, reaplique todos os secrets no cluster de usuários:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  apply -f SECRETS_MANIFEST.yaml
```
Agora você pode iniciar a migração para o Controlplane V2. Depois que a migração for concluída, você poderá reativar a criptografia de secrets sempre ativada no cluster.

Atualizar o arquivo de configuração do cluster de usuário

Faça as seguintes alterações no arquivo de configuração do cluster de usuário atual:

Defina enableControlplaneV2 como verdadeiro.
Opcionalmente, torne o plano de controle do cluster de usuário do Controlplane V2 altamente disponível (HA). Para mudar de um cluster sem HA para um cluster HA, mude masterNode.replicas de 1 para 3.
Adicione o endereço IP estático (ou os endereços) para os nós do plano de controle do cluster de usuário à seção network.controlPlaneIPBlock.ips.
Preencha a máscara de rede e o gateway na seção network.controlPlaneIPBlock.
Se a seção network.hostConfig estiver vazia, preencha-a.
Se o cluster de usuário usar o balanceamento de carga manual, configure o balanceador de carga conforme descrito na próxima seção.
Se o cluster de usuário usar o balanceamento de carga manual, defina loadBalancer.manualLB.controlPlaneNodePort e loadBalancer.manualLB.konnectivityServerNodePort como 0, porque eles não são necessários quando o ControlPlane V2 está ativado.
Atualize o campo loadBalancer.vips.controlPlaneVIP com o novo endereço IP do VIP do plano de controle. Ele precisa estar na mesma VLAN dos IPs do nó do plano de controle.
Todos os campos anteriores são imutáveis, exceto quando o cluster é atualizado para a migração. Verifique todas as configurações.
Execute gkectl diagnose cluster e corrija os problemas encontrados pelo comando.
```
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
      --cluster-name=USER_CLUSTER_NAME
```
Substitua:
- ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador
- USER_CLUSTER_NAME: o nome do cluster do usuário.

Ajustar a configuração do balanceador de carga manual

Se o cluster de usuário usar o balanceamento de carga manual, siga a etapa desta seção. Caso contrário, pule esta seção.

Da mesma forma que configurar o balanceador de carga para um cluster de usuário do CPv2, para cada um dos três novos endereços IP do nó do plano de controle especificados na seção network.controlPlaneIPBlock, configure os mapeamentos no balanceador de carga:

(ingressVIP:80) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)
(ingressVIP:443) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)

Atualizar o cluster

Execute o comando a seguir para migrar o cluster para o Controlplane V2:

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.

O comando faz o seguinte:

Crie o plano de controle de um novo cluster com o ControlPlane V2 ativado.
Interromper o plano de controle do Kubernetes do cluster kubeception.
Tire um snapshot do etcd do cluster kubeception.
Desligue os nós do plano de controle do cluster de usuário do cluster kubeception. Para fins de recuperação de falhas, ou seja, voltar ao cluster kubeception, os nós não são excluídos até a conclusão da migração.
Restaure os dados do cluster no novo plano de controle com o snapshot do etcd mencionado.
Conecte os nós do nodepool do cluster kubeception ao novo plano de controle, que pode ser acessado com o novo controlPlaneVIP.
Reconcilie o cluster de usuário restaurado para atender ao estado final do cluster com o ControlPlane V2 ativado.

Observações

Durante a migração, não há tempo de inatividade para as cargas de trabalho do cluster de usuários.
Durante a migração, há um tempo de inatividade do plano de controle do cluster de usuário. Mais especificamente, o plano de controle fica indisponível entre a etapa 2 e a conclusão da etapa 6. O tempo de inatividade é de menos de 7 minutos com base nos nossos testes, mas a duração real depende da sua infraestrutura.
Ao final da migração, os nós do plano de controle do cluster de usuário dos clusters kubeception são excluídos. Se o cluster de administrador tiver network.ipMode.type definido como "static", você poderá reciclar alguns dos IPs estáticos não usados removendo-os do arquivo de configuração do cluster de administrador e executando gkectl update admin. É possível listar os objetos de nó do cluster de administrador com kubectl get nodes -o wide para saber quais IPs estão em uso.

Após a migração

Se você desativou a criptografia de secrets sempre ativada antes da migração, siga estas etapas para reativar o recurso:

No arquivo de configuração do cluster de usuário, defina secretsEncryption.generatedKey.disabled como falso. Exemplo:
```
secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: false
```

Atualize o cluster de usuário:

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