Migrar um cluster de usuário para o Controlplane V2

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Neste documento, mostramos como migrar um cluster de usuário da versão 1.29 ou superior usando o kubeception para o Controlplane V2.

1.29: Pré-lançamento
1.28: Indisponível
1.16: Indisponí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 de 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 plano de controle V2 está ativado, o plano de controle do cluster do usuário é executado no próprio cluster.

Os benefícios do plano de controle 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 dos 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 site 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 ser 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ário estiver usando o balanceador de carga SeeSaw, será possível migrá-lo 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 outro endereço IP 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:

1. Defina enableControlplaneV2 como verdadeiro.

2. Outra opção é tornar o plano de controle do cluster de usuário do plano de controle V2 altamente disponível (HA, na sigla em inglês). Para mudar de um cluster que não é de alta disponibilidade para um de alta disponibilidade, altere masterNode.replicas de 1 para 3.

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. Remova o endereço IP (ou endereços) dos nós do plano de controle do cluster de usuário do kubeception do arquivo de bloco de IP do cluster de administrador.

4. Preencha a máscara de rede e o gateway na seção network.controlPlaneIPBlock.

5. Se a seção network.hostConfig estiver vazia, preencha-a.

6. Se o cluster de usuário usar o 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)

7. Atualize o campo loadBalancer.vips.controlPlaneVIP com o novo endereço IP para o VIP do plano de controle.

8. Todos os campos anteriores são imutáveis, exceto ao atualizar o cluster para a migração. Verifique todas as configurações.

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

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

Para configurar o balanceador de carga de um cluster de usuário CPv2, configure os mapeamentos no balanceador de carga para cada um dos três novos endereços IP de 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 seguinte comando para migrar o cluster para o plano de controle 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.