Criar e gerenciar clusters IPv6 de pilha única

Autopilot Standard

Visualizar

Este produto ou 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 produtos e 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, explicamos como criar, configurar e gerenciar clusters IPv6 de pilha única no Google Kubernetes Engine (GKE).

É possível executar cargas de trabalho conteinerizadas em um ambiente de rede somente IPv6 para evitar o esgotamento do espaço de endereços IPv4 privado (RFC 1918). Ao implantar um cluster IPv6 de pilha única, você atribui apenas endereços IPv6 aos pods, nós e Serviços, mantendo a conectividade de entrada e saída com recursos internos e externos.

Visão geral

À medida que as cargas de trabalho são escalonadas e a densidade do cluster aumenta, o espaço de endereço IPv4 particular pode se esgotar rapidamente. Em clusters somente IPv4 e de pilha dupla, cada pod requer um endereço IPv4, o que pode tornar a alocação de blocos CIDR na rede VPC um grande gargalo de escalonamento.

Nos clusters IPv6 de pilha única do GKE, você atribui endereços IPv6 exclusivamente no plano de dados do cluster, removendo totalmente as restrições de endereço IPv4. Os nós de trabalho são executados em instâncias de VM do Compute Engine de pilha única IPv6, e os pods e serviços se comunicam por conexões IPv6.

Alocação de endereços IP (IPAM)

Os clusters IPv6 de pilha única alocam endereços IPv6 na sub-rede, nos nós, nos pods e nos Serviços usando os seguintes tamanhos de prefixo:

Recurso	Prefixo do bloco CIDR	Descrição
Sub-rede	/64	Especificado como um bloco CIDR de sub-rede somente IPv6.
Nó	/96	Atribuído automaticamente pelo GKE do bloco CIDR da sub-rede, fornecendo aproximadamente 4,29 bilhões de endereços IPv6 exclusivos por nó.
Pod	/112	Atribuído de um subconjunto do subintervalo /96 do nó.
Serviço	/64	Atribuído automaticamente pelo GKE para serviços ClusterIP do intervalo de endereços IPv6 2600:2D00:0:4::0:0/64.

Tipos de acesso IPv6 externo e interno

Ao configurar a sub-rede do cluster, é possível escolher entre dois tipos de acesso IPv6 para controlar a roteabilidade da Internet:

• Interno (ULA): as sub-redes com o tipo de acesso INTERNAL usam endereços unicast locais exclusivos (ULA, na sigla em inglês) no intervalo fd20::/20. A comunicação é limitada à rede VPC, às redes de peering e às conexões híbridas. Os nós e pods não podem acessar diretamente recursos públicos da Internet IPv6 nem receber entrada direta da Internet.
• Externo (GUA): as sub-redes com o tipo de acesso EXTERNAL usam endereços unicast globais (GUA). Os nós e os pods recebem endereços IPv6 globalmente exclusivos e podem se comunicar com recursos públicos de Internet IPv6 em entrada e saída, sujeitos a regras de firewall de VPC e tabelas de roteamento.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

• Ative a API Google Kubernetes Engine.
Ativar a API Google Kubernetes Engine
• Para usar a Google Cloud CLI nesta tarefa, instale e inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.
  Observação: em instalações prévias da CLI gcloud, defina a propriedade compute/region. Se você usa principalmente clusters zonais, defina compute/zone. Ao definir um local padrão, é possível evitar erros na CLI gcloud como: One of [--zone, --region] must be supplied: Please specify location. Talvez seja necessário especificar o local em determinados comandos se o local do cluster for diferente do padrão definido.

Requisitos e limitações

Para usar clusters IPv6 de pilha única, verifique se você atende aos seguintes requisitos e limitações:

• O cluster precisa executar o GKE versão 1.37.1-gke.3020000 ou posterior.
• O cluster precisa ser cluster nativo de VPC e usar o GKE Dataplane V2. Os clusters IPv6 de pilha única não são compatíveis com clusters baseados em rotas.
• Os clusters IPv6 de pilha única são compatíveis apenas com instâncias de VM IPv6 de pilha única como nós de trabalho e não são compatíveis com pools de nós mistos ou de pilha dupla.
• É preciso usar o Cloud DNS como o provedor de DNS do cluster (--cluster-dns=clouddns). Os clusters IPv6 de pilha única não são compatíveis com kube-dns.
• O acesso ao plano de controle em clusters IPv6 de pilha única usa dois caminhos distintos:
  • Clientes externos: clientes fora do cluster (por exemplo, usando kubectl) acessam o plano de controle por um endpoint baseado em domínio no GKE Frontend (GKFE).
  • Cargas de trabalho internas: os nós e os pods se conectam com segurança ao plano de controle pelo Private Service Connect. Para dar suporte a essa comunicação, é necessário fornecer ou criar uma sub-rede com um tipo de acesso IPv6 INTERNAL (--private-endpoint-subnetwork).
• Em sub-redes IPv6 internas (INTERNAL), os nós e os pods podem acessar as APIs do Google e o Artifact Registry por IPv6 sem um gateway do Cloud NAT. No entanto, pense no seguinte caso:
  • Para alcançar endpoints externos somente IPv4 (como registros de contêiner externos somente IPv4), configure o DNS64 e o Cloud NAT (NAT64).
  • Os nós e pods em sub-redes INTERNAL não podem alcançar endpoints IPv6 públicos externos fora do Google porque os endereços locais exclusivos (ULA, na sigla em inglês) não são roteáveis na Internet IPv6 pública e o Cloud NAT não é compatível com a conversão de IPv6 para IPv6 (NAT66).
• Os clusters IPv6 de pilha única não são compatíveis com as flags de cluster --private-ipv6-google-access-type e --enable-private-nodes. Em vez disso, configure o Acesso privado do Google e os tipos de acesso IPv6 (INTERNAL ou EXTERNAL) diretamente na sub-rede da VPC.
• Os clusters IPv6 de pilha única não são compatíveis com configurações de várias sub-redes.
• Os clusters IPv6 de pilha única não são compatíveis com o GKE Ingress. Para configurar balanceadores de carga de aplicativo da camada 7, use a API Gateway.
• A API de várias redes do GKE não é compatível com redes de pods IPv6. As redes de pods secundárias precisam ser apenas IPv4. Para mais informações, consulte Suporte a várias redes para pods.
• Os clusters somente IPv6 não são compatíveis com o Cloud Service Mesh.
• É possível trazer seus próprios endereços IPv6 (BYOIPv6) com clusters IPv6 de pilha única. Para saber mais sobre os requisitos que se aplicam aos prefixos BYOIPv6, consulte Criar e usar subprefixos IPv6.

Configuração do servidor de metadados de carga de trabalho

Como as cargas de trabalho em execução em pods somente IPv6 não podem acessar o endereço padrão do servidor de metadados IPv4 (169.254.169.254), aplique os seguintes ajustes:

• Configure seus aplicativos e bibliotecas de cliente para acessar o servidor de metadados usando o nome de domínio metadata.google.internal (recomendado) ou o endereço IPv6 literal de ULA [fd20:ce::254].

• Se você usa bibliotecas de cliente ou aplicativos com endpoints de servidor de metadados IPv4 codificados (por exemplo, versões anteriores das bibliotecas de cliente da API do Google), defina a variável de ambiente GCE_METADATA_HOST nas imagens de contêiner ou nas especificações do pod:

  env:
  - name: GCE_METADATA_HOST
    value: "metadata.google.internal"
  

Criar um cluster IPv6 de pilha única

É possível criar um cluster IPv6 de pilha única usando a Google Cloud CLI.

Criar um cluster e uma sub-rede simultaneamente

Se você não tiver sub-redes personalizadas preexistentes, crie um cluster IPv6 de pilha única padrão e faça com que o GKE provisione automaticamente a sub-rede de nó necessária e --private-endpoint-subnetwork em um único comando.

Execute este comando:

gcloud beta container clusters create CLUSTER_NAME \
    --cluster-version=VERSION \
    --enable-dataplane-v2 \
    --cluster-dns=clouddns \
    --stack-type=ipv6 \
    --network=NETWORK_NAME \
    --create-subnetwork name=SUBNET_NAME \
    --ipv6-access-type=ACCESS_TYPE \
    --location=COMPUTE_LOCATION

Substitua:

• CLUSTER_NAME: o nome do novo cluster.
• VERSION: GKE versão 1.37.1-gke.3020000 ou posterior.
• NETWORK_NAME: o nome de uma rede VPC de modo personalizado existente.
• SUBNET_NAME: o nome da nova sub-rede de nós a ser criada.
• ACCESS_TYPE: a capacidade de roteamento da Internet da sub-rede. Especifique INTERNAL para endereçamento ULA particular ou EXTERNAL para endereçamento GUA público. O padrão será EXTERNAL se omitido.
• COMPUTE_LOCATION: a região ou zona de computação do cluster.

Observação: ao usar --create-subnetwork, o GKE provisiona automaticamente a sub-rede do nó e a sub-rede do plano de controle do PSC interno necessária. Quando você exclui o cluster, o GKE faz o possível para excluir essas sub-redes, desde que nenhum outro recurso as use.

Criar um cluster padrão em sub-redes personalizadas

Para usar sub-redes preexistentes ou personalizadas, crie a rede VPC, a sub-rede do plano de controle do PSC e a sub-rede do nó antes de criar o cluster.

1. Crie uma rede VPC de modo personalizado com endereços IPv6 internos de ULA ativados:

   gcloud compute networks create NETWORK_NAME \
       --subnet-mode=CUSTOM \
       --enable-ula-internal-ipv6
   

2. Crie a sub-rede dedicada do plano de controle interno do PSC:

   gcloud compute networks subnets create PSC_SUBNET_NAME \
       --stack-type=ipv6_only \
       --ipv6-access-type=INTERNAL \
       --network=NETWORK_NAME \
       --region=COMPUTE_REGION
   

   Substitua COMPUTE_REGION pela região em que você implanta o cluster (por exemplo, us-central1). Também é possível especificar --stack-type=ipv4_ipv6 para a sub-rede do plano de controle do PSC.

3. Crie a sub-rede do nó. Escolha o acesso interno (INTERNAL) ou externo (EXTERNAL):

   gcloud compute networks subnets create NODE_SUBNET_NAME \
       --stack-type=ipv6_only \
       --ipv6-access-type=ACCESS_TYPE \
       --network=NETWORK_NAME \
       --region=COMPUTE_REGION
   

4. Crie o cluster padrão IPv6 de pilha única que faz referência às duas sub-redes:

   gcloud container clusters create CLUSTER_NAME \
       --cluster-version=VERSION \
       --enable-dataplane-v2 \
       --cluster-dns=clouddns \
       --stack-type=ipv6 \
       --network=NETWORK_NAME \
       --subnetwork=NODE_SUBNET_NAME \
       --private-endpoint-subnetwork=PSC_SUBNET_NAME \
       --location=COMPUTE_LOCATION
   

Criar um cluster do Autopilot em sub-redes personalizadas

Os clusters do Autopilot herdam automaticamente o tipo de pilha da sub-rede de nó que você especificar. Quando você seleciona uma sub-rede somente IPv6, o GKE cria um cluster do Autopilot IPv6 de pilha única.

1. Verifique se você criou uma rede VPC personalizada, uma sub-rede PSC interna e uma sub-rede de nó somente IPv6, conforme descrito na seção anterior.

2. Crie o cluster do Autopilot:

   gcloud container clusters create-auto CLUSTER_NAME \
       --cluster-version=VERSION \
       --network=NETWORK_NAME \
       --subnetwork=NODE_SUBNET_NAME \
       --private-endpoint-subnetwork=PSC_SUBNET_NAME \
       --location=COMPUTE_LOCATION
   

Criar um cluster padrão com nós gerenciados

Também é possível criar um cluster padrão IPv6 de pilha única que use nós gerenciados configurados no nível da carga de trabalho. Para saber mais sobre como configurar ComputeClasses gerenciadas em clusters Standard, consulte Classes do Autopilot em clusters Standard.

Usar seus próprios endereços IPv6 para nós e pods

É possível criar um cluster IPv6 de pilha única em que os nós e pods usam traga seus próprios endereços IPv6 (BYOIPv6) em vez de endereços fornecidos pelo Google. Para fazer isso, crie a sub-rede do nó com um intervalo de endereços IPv6 externo que venha de um subprefixo IPv6 regional do seu prefixo delegado público (PDP). Os nós e pods recebem endereços IPv6 desse prefixo e se comunicam com a Internet e entre si usando esses endereços.

1. Crie um subprefixo IPv6 regional do seu prefixo público delegado no modo EXTERNAL_IPV6_SUBNETWORK_CREATION. Para mais informações, consulte Criar subprefixos IPv6.

2. Crie a sub-rede do nó com um tipo de acesso IPv6 EXTERNAL e faça referência ao subprefixo usando a flag --ip-collection. O Compute Engine aloca o intervalo de endereços IPv6 /64 da sub-rede do subprefixo:

   gcloud compute networks subnets create NODE_SUBNET_NAME \
       --stack-type=ipv6_only \
       --ipv6-access-type=EXTERNAL \
       --ip-collection=SUB_PREFIX_NAME \
       --network=NETWORK_NAME \
       --region=COMPUTE_REGION
   

   Substitua SUB_PREFIX_NAME pelo nome do subprefixo que você criou na etapa anterior. O subprefixo precisa estar na mesma região que a sub-rede. Para escolher um intervalo /64 específico do subprefixo em vez de permitir que o Compute Engine aloque um, adicione a flag --external-ipv6-prefix.

3. Crie o cluster nessa sub-rede de nós seguindo as etapas em Criar um cluster padrão em sub-redes personalizadas ou Criar um cluster do Autopilot em sub-redes personalizadas. A sub-rede do plano de controle do PSC não precisa de um intervalo de endereços BYOIPv6.

4. Depois que o GKE criar o cluster, verifique se os nós e os pods têm endereços IPv6 do seu prefixo:

   kubectl get nodes -o wide
   kubectl get pods --all-namespaces -o wide
   

Lembre-se:

• Este procedimento usa uma sub-rede de nó com o tipo de acesso IPv6 EXTERNAL, para que os nós e pods recebam endereços roteáveis globalmente do seu prefixo. Também é possível usar uma sub-rede de nó com o tipo de acesso IPv6 INTERNAL referenciando um subprefixo no modo INTERNAL_IPV6_SUBNETWORK_CREATION. Nesse caso, os nós e os pods recebem endereços BYOIPv6 internos, e as limitações de conectividade do tipo de acesso IPv6 interno se aplicam. Para mais informações, consulte Conectar-se a recursos externos e particulares.
• Para expor cargas de trabalho em endereços BYOIPv6 com serviços LoadBalancer, consulte Traga seus próprios endereços IPv6 (BYOIPv6), que não requer uma sub-rede de nó BYOIPv6.
• Para os requisitos que se aplicam aos prefixos BYOIPv6, consulte Criar e usar subprefixos IPv6.

Verificar o tipo de pilha do cluster

Depois que a criação do cluster for concluída, liste os clusters para verificar se o seu está sendo executado no modo IPv6 de pilha única:

gcloud beta container clusters list

A saída confirma que a coluna STACK_TYPE está definida como IPV6:

NAME               LOCATION       MASTER_VERSION      MASTER_IP                                 MACHINE_TYPE  NODE_VERSION        NUM_NODES  STACK_TYPE  STATUS
v6-only-cluster-1  us-central1-c  1.37.0-gke.1000000  gke-3a3234-123456.us-central1-c.gke.goog  e2-medium     1.37.0-gke.1000000  1          IPV6        RUNNING

Balanceamento de carga em clusters IPv6 de pilha única

É possível expor aplicativos em execução em clusters IPv6 de pilha única usando balanceadores de carga de camada 7 e camada 4:

• Balanceamento de carga de aplicativo da camada 7 (API Gateway): use a API Gateway do Kubernetes para implantar balanceadores de carga de aplicativo da camada 7 (gke-l7-rilb, gke-l7-regional-external-managed ou gke-l7-global-external-managed). Esses gateways podem atender a clientes IPv4 e IPv6 internos e externos enquanto roteiam o tráfego de maneira transparente para endpoints de pod internos somente IPv6. O Ingress do GKE não é compatível com clusters IPv6 de pilha única. Ao implantar gateways regionais (gke-l7-rilb e gke-l7-regional-external-managed) em clusters IPv6 de pilha única, considere os seguintes requisitos de sub-rede:

  • Sub-rede somente proxy: em clusters IPv6 de pilha única, a sub-rede regional somente proxy (--purpose=REGIONAL_MANAGED_PROXY) precisa ser de pilha dupla (--stack-type=IPV4_IPV6). Em clusters somente IPv4 e de pilha dupla, a sub-rede pode ser somente IPv4 ou de pilha dupla.
  • Sub-rede VIP do gateway: ao contrário dos gateways externos regionais IPv4 (que não alocam VIPs de uma sub-rede), os gateways externos regionais IPv6 (gke-l7-regional-external-managed) exigem uma sub-rede com acesso IPv6 EXTERNAL, e os gateways internos regionais (gke-l7-rilb) exigem uma sub-rede com acesso IPv6 INTERNAL (ou um intervalo IPv4 para um VIP IPv4 interno). Para alocar um VIP de gateway regional temporário de uma sub-rede personalizada, em vez da sub-rede de nós do cluster, especifique o nome da sub-rede no campo spec.default.subnetwork de um GCPGatewayPolicy anexado ao gateway.

  Para instruções de configuração, consulte Implantar gateways.

• Balanceamento de carga de passagem de camada 4 (API Service): é possível expor cargas de trabalho a clientes IPv6 usando os serviços do Kubernetes configurados com type: LoadBalancer. Dependendo se os nós do cluster são executados em uma sub-rede INTERNAL (ULA) ou EXTERNAL (GUA), talvez seja necessário provisionar uma sub-rede de balanceador de carga dedicada e referenciá-la usando a anotação networking.gke.io/load-balancer-subnet:

  • Para balanceadores de carga internos, consulte Criar um serviço LoadBalancer interno em um cluster IPv6 de pilha única.
  • Para balanceadores de carga externos, consulte Criar um serviço LoadBalancer externo em um cluster IPv6 de pilha única.
  • Para atribuir endereços BYOIPv6 a balanceadores de carga, consulte Traga seus próprios endereços IPv6 (BYOIPv6). Os serviços LoadBalancer externos podem alocar os endereços diretamente de um prefixo público delegado BYOIPv6, independentemente do tipo de acesso da sub-rede do nó.

Conectar-se a recursos externos e particulares

As cargas de trabalho no cluster IPv6 de pilha única geralmente precisam se comunicar com serviços externos pela Internet ou serviços privados no Google Cloud.

Conectar-se a recursos públicos de Internet IPv6

Se os nós do cluster forem executados em uma sub-rede configurada com o tipo de acesso IPv6 EXTERNAL (--ipv6-access-type=EXTERNAL), a conectividade de saída e entrada para endpoints IPv6 públicos da Internet será ativada por padrão. Verifique se as regras de firewall da VPC permitem o tráfego IPv6 necessário. Para saber mais, consulte Usar regras de firewall da VPC.

Conectar-se a recursos públicos de Internet IPv4 (DNS64 e NAT64)

Como os pods em um cluster IPv6 de pilha única têm apenas endereços IPv6, a conexão com endpoints públicos da Internet somente IPv4 requer conversão de rede. É possível configurar o Cloud DNS e o Cloud NAT na rede VPC para fornecer tradução automática de DNS64 e NAT64:

1. Crie uma política de servidor DNS64:

   gcloud dns policies create POLICY_NAME \
       --description="DNS64 policy for single-stack IPv6 cluster" \
       --networks=NETWORK_NAME \
       --enable-dns64-all-queries
   

2. Crie um Cloud Router na região em que o cluster está implantado:

   gcloud compute routers create ROUTER_NAME \
       --network=NETWORK_NAME \
       --region=COMPUTE_REGION
   

3. Crie um gateway do Cloud NAT configurado para a conversão NAT64:

   gcloud compute routers nats create NAT_NAME \
       --router=ROUTER_NAME \
       --region=COMPUTE_REGION \
       --auto-allocate-nat-external-ips \
       --nat64-all-v6-subnet-ip-ranges
   

   Para configurar o NAT64 com sub-redes específicas ou endereços IP externo manuais, use --nat64-custom-v6-subnet-ip-ranges e --nat-external-ip-pool.

Para saber mais sobre a conversão de endereços, consulte Configurar DNS64 e NAT64 e DNS64 e NAT64 para conectividade 6to4.

Conectar-se a serviços particulares usando o Private Service Connect

O Private Service Connect (PSC) é compatível com a conversão de endereços IPv6 para IPv4 em endpoints e regras de encaminhamento. É possível conectar cargas de trabalho no cluster IPv6 de pilha única aos serviços gerenciados do Google Cloud (como instâncias do Cloud SQL) ou a serviços de produtores de terceiros:

1. Reserve um endereço IPv6 interno estático da sub-rede do PSC do cluster:

   gcloud compute addresses create ADDRESS_NAME \
       --ip-version=IPV6 \
       --subnet=PSC_SUBNET_NAME \
       --region=COMPUTE_REGION
   

2. Crie uma regra de encaminhamento de endpoint do PSC que segmenta o anexo de serviço:

   gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
       --address=ADDRESS_NAME \
       --region=COMPUTE_REGION \
       --network=NETWORK_NAME \
       --target-service-attachment=SERVICE_ATTACHMENT_URL \
       --allow-psc-global-access
   

3. Recupere o endereço IPv6 atribuído:

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME \
       --region=COMPUTE_REGION \
       --format='value(IPAddress)'
   

4. Use o endereço IPv6 recuperado nas strings de conexão do aplicativo. O PSC traduz o tráfego para que os pods IPv6 possam acessar com segurança os serviços de produtor IPv4 ou de pilha dupla.

Para saber mais sobre como consumir serviços publicados, consulte Criar um endpoint do Private Service Connect e Conectar-se ao Cloud SQL com o Private Service Connect. Para publicar um serviço LoadBalancer interno em execução no cluster para consumidores em outras redes VPC usando um recurso ServiceAttachment, consulte Criar um balanceador de carga interno com o Private Service Connect.

Redes e aceleradores avançados

É possível configurar clusters IPv6 de pilha única com interfaces de rede secundárias para pools de nós aceleradores e pods de várias redes.

Rede de acelerador com várias NICs

Em clusters IPv6 de pilha única padrão, é possível anexar redes de dados secundárias (RDMA ou DIORITE) a pools de nós de acelerador (GPUs e TPUs) usando rede automatizada (--accelerator-network-profile=auto) ou configuração manual de várias redes (--additional-node-network). As interfaces secundárias podem ser executadas em sub-redes IPv4, sub-redes de pilha dupla ou sub-redes somente IPv6.

Para instruções detalhadas, consulte Configurar redes de nós com várias NICs em clusters IPv6 de pilha única.

Suporte a várias redes para pods

Os clusters IPv6 de pilha única oferecem suporte a várias redes para pods com as seguintes características:

• A interface de rede principal do pod (eth0) usa rede IPv6 de pilha única.
• As interfaces de rede de pod adicionais precisam ser somente IPv4 (redes VPC de camada 3). Os clusters IPv6 de pilha única não são compatíveis com redes de pods IPv6 em outras interfaces de rede.
• A anotação de pod networking.gke.io/default-interface configura a interface padrão apenas para o tráfego IPv4. Nenhuma interface padrão é configurada para o tráfego IPv6.

Para saber como configurar redes de pods IPv4 secundárias apoiadas por sub-redes VPC, consulte Configurar o suporte a várias redes para pods em clusters IPv6 de pilha única.

Migrar para clusters IPv6 de pilha única

Não é possível converter diretamente ou atualizar no local clusters IPv4 ou de pilha dupla em clusters IPv6 de pilha única. Para fazer a transição de cargas de trabalho, use uma migração azul-verde:

1. Auditar dependências: verifique se as configurações do aplicativo, as bibliotecas de cliente e os agentes usam nomes DNS (como metadata.google.internal) em vez de endereços IPv4 codificados. Configure o GCE_METADATA_HOST, se necessário.
2. Provisionar o cluster verde: implante um novo cluster IPv6 de pilha única lado a lado com o cluster atual na mesma rede VPC ou em uma rede VPC com peering. Verifique se o Cloud DNS, o DNS64, o Cloud NAT (NAT64) e as regras de encaminhamento do PSC estão configurados.
3. Implantar cargas de trabalho: aplique os manifestos do Kubernetes ao cluster verde e verifique se os pods são iniciados e se comunicam corretamente.
4. Mudar o tráfego: usando os balanceadores de carga (API Gateway ou políticas de roteamento do Cloud DNS), mude gradualmente o tráfego do cluster legado para o novo cluster IPv6 enquanto monitora as métricas e as taxas de erro.
5. Desativar o cluster legado: depois que todo o tráfego for transferido e o cluster verde for verificado como estável, drene e exclua o cluster antigo.

A seguir

• Para saber mais sobre a rede do GKE, consulte a visão geral da rede do GKE.
• Para saber como o GKE atribui endereços IP, consulte Noções básicas sobre endereçamento IP no GKE.
• Para configurar o balanceamento de carga da camada 7, consulte Como implantar gateways.
• Para configurar redes de pods secundárias, consulte Configurar o suporte a várias redes para pods.