Migrar clusters nativos de VPC para o GKE Dataplane V2

Autopilot Standard

Visualizar

Este recurso está sujeito aos Termos das Soluções Pré-GA na seção Termos Gerais de Serviço 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.

Use este documento para migrar seus clusters nativos de VPC do Google Kubernetes Engine (GKE) do Dataplane V1 para o GKE Dataplane V2, monitorar a migração e revertê-la, se necessário.

Este documento é destinado a administradores e operadores de plataforma e especialistas em redes que gerenciam configurações de rede para clusters do GKE.

Antes de começar, saiba o que acontece durante cada fase de migração e como planejar interrupções de carga de trabalho em Sobre a migração para o GKE Dataplane V2.

Antes de começar

Antes de iniciar a migração, verifique se o cluster atende aos requisitos de qualificação e considere o impacto nas cargas de trabalho.

Verifique se o cluster atende a estes requisitos:

• O cluster é um cluster nativo de VPC.
• O cluster está executando a versão 1.35.3-gke.1155000 ou mais recente.
• Os pools de nós estão executando a versão 1.35.1-gke.1516000 ou mais recente.
• Se você usa o Cloud Service Mesh ou o Istio de código aberto, a versão do Istio é 1.23 ou mais recente.

Preparar o cluster

Conclua as tarefas a seguir antes de iniciar a migração:

• Remoção de NetworkPolicy: remova as políticas de rede atuais. Se o GKE aplicar políticas de rede de repente ao recriar os nós, você poderá ter uma interrupção de rede não intencional.
• Políticas de rede do Calico: se você usa um cluster padrão do GKE com a política de rede (Calico) ativada, desative a aplicação obrigatória da política de rede. Não é possível migrar esses clusters diretamente.
• Recomendações do Active Assist: confira o Active Assist ou a página de detalhes do cluster para ver recomendações que possam entrar em conflito com a migração.
• Capacidade de endereço IP: verifique se o intervalo de endereços IP do pod do cluster tem capacidade suficiente para as estratégias de upgrade do pool de nós. Para mais informações, consulte Insights de utilização de endereço IP do GKE.
  • Recursos de rede: ative recursos de rede, como o NodeLocal DNSCache ou a visibilidade entre nós, antes de iniciar a migração ou depois que ela for concluída. Não é possível ativá-los durante a migração.

Entenda as limitações

• Configurações de rede bloqueadas: depois de iniciar a migração, você não pode mudar as configurações de rede do cluster até que a migração seja concluída.
• Janelas de manutenção: a migração segue as janelas de manutenção e as exclusões de manutenção. Por isso, ela pode parecer estar parada. Para acelerar o processo, é possível corrigir pools de nós manualmente. Para conferir as etapas, consulte Acelerar a migração.
• Recursos opcionais do GKE Dataplane V2: configure recursos opcionais do GKE Dataplane V2 recursos, como a observabilidade do GKE Dataplane V2 ou o suporte a várias redes para pods, após a conclusão da migração.
• Terraform: não é possível usar o Terraform para migrar para o GKE Dataplane V2.

Cuidado:a migração ignora o orçamento de interrupção do cluster. Planeje a migração de acordo com isso.

Iniciar a migração

Para iniciar a migração manualmente e ignorar as verificações de diagnóstico automatizadas, é possível corrigir o cluster usando a Google Cloud CLI.

Execute este comando:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --enable-dataplane-v2

Substitua:

• CLUSTER_NAME: o nome do cluster.
• LOCATION: o local de computação do cluster.

Observar o progresso da migração

É possível monitorar o status da migração verificando o campo datapathProvider. Durante a transição, esse campo mostra MIGRATE_TO_ADVANCED_DATAPATH.

1. Verifique o status do cluster:

   gcloud container clusters describe CLUSTER_NAME \
       --location=LOCATION \
       --format='value(networkConfig.datapathProvider)'
   

   Substitua:

   • CLUSTER_NAME: o nome do cluster.
   • LOCATION: o local de computação do cluster.

2. Verifique o status do pool de nós:

   gcloud container node-pools list \
       --cluster=CLUSTER_NAME \
       --location=LOCATION \
       --format='value(name, networkConfig.datapathProvider)'
   

   Substitua:

   • CLUSTER_NAME: o nome do cluster.
   • LOCATION: o local de computação do cluster.
   Observação:se você usa o Autopilot ou o Standard com ComputeClasses do Autopilot, não é possível listar pools de nós gk3-.

3. Verifique o DaemonSet anetd para confirmar se os agentes estão em execução:

   kubectl get ds -n kube-system anetd
   

Acelerar a migração

Para ignorar a programação de lançamento automatizada, corrija os pools de nós manualmente.

Aviso:execute correções simultâneas de pool de nós somente depois que um ou mais pools de nós forem corrigidos sequencialmente para verificar se as cargas de trabalho estão funcionando corretamente.

Para corrigir um pool de nós manualmente, execute o comando a seguir:

gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --datapath-provider=advanced-datapath

Substitua:

• NODE_POOL_NAME: o nome do pool de nós.
• CLUSTER_NAME: o nome do cluster.
• LOCATION: o local de computação do cluster.

Observação:se você usa o Autopilot ou o Standard com ComputeClasses do Autopilot, não é possível corrigir pools de nós gk3-. O plano de controle gerencia esses upgrades automaticamente.

Finalizar a migração

Depois que todos os pools de nós forem migrados para o GKE Dataplane V2, o GKE finalizará a migração automaticamente. Quando a migração for concluída, a resposta ao comando mostrará um status de ADVANCED_DATAPATH e o cluster estará executando o GKE Dataplane V2.

Observe a conclusão verificando o status do cluster:

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format='value(networkConfig.datapathProvider)'

Substitua:

• CLUSTER_NAME: o nome do cluster.
• LOCATION: o local de computação do cluster.

Quando a migração for concluída, a saída mostrará ADVANCED_DATAPATH.

Reverter uma migração

É possível reverter a migração para o Dataplane V1 a qualquer momento antes que a fase de finalização seja concluída. A reversão da migração é um processo simétrico à migração direta: depois de iniciar a reversão, o GKE corrige automaticamente os pools de nós de volta para o caminho de dados legado e, em seguida, finaliza o cluster.

1. Observe a integridade do anetd: antes de reverter a migração, verifique se os agentes estão em execução para determinar se a falha pode ser atenuada.

   kubectl get ds -n kube-system anetd
   

2. Cancelar operações de pool de nós em andamento:

   1. Identifique e cancele todas as operações de pool de nós em execução que bloqueiam a solicitação de correção do cluster.

      gcloud container operations list \
          --location=LOCATION \
          --filter="operationType=UPGRADE_NODES AND status=RUNNING AND targetLink:*/clusters/CLUSTER_NAME"
      

      Substitua:

      • LOCATION: o local de computação do cluster.
      • CLUSTER_NAME: o nome do cluster.

   2. Cancele a operação usando o ID da operação:

      gcloud container operations cancel OPERATION_ID \
          --location=LOCATION
      

      Substitua:

      • OPERATION_ID: o ID da operação em execução.
      • LOCATION: o local de computação do cluster.

3. Iniciar a reversão: emita uma solicitação de correção de cluster para reverter a migração para o Dataplane V1.

   gcloud container clusters update CLUSTER_NAME \
       --location=LOCATION \
       --no-enable-dataplane-v2
   

   Substitua:

   • CLUSTER_NAME: o nome do cluster.
   • LOCATION: o local de computação do cluster.

4. Observar o lançamento do pool de nós: verifique o status do pool de nós para verificar a migração para o caminho de dados legado.

   gcloud container node-pools list \
       --cluster=CLUSTER_NAME \
       --location=LOCATION \
       --format='value(name, networkConfig.datapathProvider)'
   

   Substitua:

   • CLUSTER_NAME: o nome do cluster.
   • LOCATION: o local de computação do cluster.

   Durante a reversão, a resposta ao comando mostra um status de LEGACY_DATAPATH para pools de nós corrigidos.

   Observação:se você usa o Autopilot ou o Standard com ComputeClasses do Autopilot, não é possível listar pools de nós gk3-.

5. Observar a finalização: depois que todos os pools de nós forem migrados para o Dataplane V1, o GKE finalizará a migração automaticamente. Observe a conclusão verificando o status do cluster:

   gcloud container clusters describe CLUSTER_NAME \
       --location=LOCATION \
       --format='value(networkConfig.datapathProvider)'
   

   Substitua:

   • CLUSTER_NAME: o nome do cluster.
   • LOCATION: o local de computação do cluster.

   Quando a reversão for concluída, a resposta ao comando mostrará um status de LEGACY_DATAPATH.

Resolver problemas da migração

Esta seção fornece informações para ajudar você a resolver problemas comuns que podem ocorrer ao migrar para o GKE Dataplane V2.

Falha na migração do pool de nós

Ao migrar pools de nós, o GKE usa a estratégia de upgrades súbitos ou upgrades azul-verde configurada para criar novos nós antes de excluir os antigos. Se a sua Google Cloud zona não tiver recursos suficientes para provisionar os novos nós, a migração falhará com um erro GCE_STOCKOUT ou ZONE_RESOURCE_POOL_EXHAUSTED_WITH_DETAILS. O GKE tenta migrar esses pools de nós automaticamente. Se você corrigir os pools de nós manualmente, aguarde e tente a migração novamente mais tarde, quando os recursos estiverem disponíveis.

A seguir

• Para saber mais sobre a observabilidade do GKE Dataplane V2, consulte Observabilidade do GKE Dataplane V2.