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 ou mais recente usando o kubeception para o Controlplane V2.

1.29: visualização
1.28: não disponível
1.16: não disponível

Sobre os planos de controle do cluster de usuário

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 é chamado de 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.

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 de 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 uma localização geográfica 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 ter a versão 1.29 ou mais recente. O cluster de administrador e os pools de nós podem ser uma ou duas versões secundárias menores que o 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 não pode ser modificado. 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ário estiver usando o balanceador de carga SeeSaw, migre-o 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 extra para um novo IP virtual (VIP) do plano de controle.

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.
Se quiser, torne o plano de controle para o cluster de usuário do Controlplane V2 altamente disponível (HA, na sigla em inglês). Para mudar de um cluster que não é de alta disponibilidade para um cluster de alta disponibilidade, altere masterNode.replicas de 1 para 3.
Adicione os endereços IP estáticos dos 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 balanceamento de carga manual, configure o balanceador de carga para incluir os IPs de nó do plano de controle para o tráfego do plano de dados:
- (ingressVIP:80) -> (CP_NODE_IP_ADDRESSES:ingressHTTPNodePort)
- (ingressVIP:443) -> (CP_NODE_IP_ADDRESSES:ingressHTTPSNodePort)
Atualize o campo loadBalancer.vips.controlPlaneVIP com o novo endereço IP do VIP do plano de controle. Observe que ele precisa estar na mesma VLAN que os IPs de nó do plano de controle.
Todos os campos anteriores são imutáveis, exceto durante a atualização do cluster para a migração. Verifique todas as configurações.
Execute gkectl diagnose cluster e corrija todos os problemas que o comando encontrar.
```
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
- CLUSTER_NAME: o nome do cluster do usuário.

Ajustar a configuração manual do balanceador de carga

Se o cluster de usuário usar 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, configure os mapeamentos no balanceador de carga para cada um dos três novos endereços IP do nó do plano de controle especificados na seção network.controlPlaneIPBlock:

(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.
Interrompa o plano de controle do Kubernetes do cluster do Kubeception.
Crie um snapshot do etcd do cluster do Kubeception.
Desligue os nós do plano de controle do cluster de usuário do cluster do kubeception. Para recuperação de falhas, ou seja, para o cluster de 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 acima.
Conecte os nós do pool de nós do cluster do 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á inatividade para as cargas de trabalho do cluster de usuário.
Durante a migração, há algum tempo de inatividade para o 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. Com base em nossos testes, o tempo de inatividade é inferior a sete minutos, mas a duração real depende da sua infraestrutura.
No final da migração, os nós do plano de controle do cluster de usuário dos clusters de 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 utilizados 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 ver quais IPs estão em uso.