Configurar a pilha dupla IPv6 para o Cloud Service Mesh

**Observação** :este guia aborda apenas o Cloud Service Mesh com Google Cloud APIs e não com APIs do Istio. Para mais informações, consulte Visão geral do Cloud Service Mesh.

Nesta página, mostramos como balancear a carga do tráfego IPv6 no Cloud Service Mesh usando balanceadores de carga baseados em proxy do Traffic Director (TD) e como migrar de implantações baseadas em IPv4 para implantações de pilha dupla (IPv4 e IPv6) e como migrar de pilha dupla para IPv4.

Em implantações de pilha dupla, é possível indicar se o IPv4 ou o IPv6 é enviado para o back-end do serviço. O proxy ou o cliente gRPC testa cada caminho de dados na ordem de preferência e seleciona aquele que está alinhado à sua preferência e ao que é compatível.

Os recursos de pilha dupla são compatíveis com o gRPC 1.66.1 e versões mais recentes para C++ e Python, 1.12 e versões mais recentes para Node e 1.71 e versões mais recentes para Go. O Java não é compatível no momento.

As versões do gRPC sem suporte a pilha dupla (ou seja, Go e versões anteriores a 1.66 em outras linguagens) usarão apenas o primeiro endereço de cada endpoint, na ordem enviada pelo TD.

Antes de começar

Este guia pressupõe que você já tenha:

• Configurado as APIs de roteamento de serviço com o Envoy e cargas de trabalho sem proxy.
• Concluído as etapas na seção Continuar o processo de configuração do guia de integração.

Configurar o serviço de back-end IPv6

Nesta seção, você vai configurar o seguinte:

• Dois grupos de back-end (grupos de instâncias, grupos gerenciados de instâncias ou grupos de endpoints de rede), um em cada uma das duas zonas diferentes na mesma região.
• Duas instâncias de VM em cada grupo de back-end.
• Uma verificação de integridade para verificar a integridade da instância.
• Regras de firewall que permitem que as verificações de integridade alcancem os back-ends.
• Um serviço de back-end.
• O serviço de back-end para incluir os dois grupos de back-end configurados.

Configurar uma sub-rede para os back-ends

O comando a seguir aloca intervalos de endereços internos para IPv4 e IPv6 e permite que as VMs na sub-rede sejam alocadas com qualquer tipo de endereço.

Observe que somente as sub-redes de modo personalizado são compatíveis. Não há suporte para o modo automático. É possível mudar para o modo personalizado para toda a rede VPC e, em seguida, preencher os back-ends IPv6 (MIGs ou NEGs).

1. Criar uma rede de pilha dupla:

   gcloud compute networks create NETWORK \
       --subnet-mode=custom \
       --enable-ula-internal-ipv6
   

2. Criar uma sub-rede de pilha dupla para VMs de back-end:

   gcloud compute networks subnets create SUBNET \
       --network=NETWORK \
       --range=PRIMARY_IPv4_RANGE \
       --stack-type=IPV4_IPV6 \
       --ipv6-access-type=IPv6_ACCESS_TYPE \
       --region=REGION
   

   Substitua:

   • SUBNET: um nome para a nova sub-rede.
   • NETWORK: o nome da rede VPC que vai conter a nova sub-rede.
   • PRIMARY_IPv4_RANGE: o intervalo IPv4 principal da nova sub-rede, em notação CIDR. Para mais informações, consulte Intervalos de sub-rede IPv4.
   • IPv6_ACCESS_TYPE: o tipo de acesso IPv6. Pode ser EXTERNAL ou INTERNAL.
   • REGION: a Google Cloud região do em que a nova sub-rede será criada.

Configurar back-ends

É possível usar grupos gerenciados de instâncias (MIG), grupos não gerenciados de instâncias, ou grupos de endpoints de rede (NEGs).

MIG

1. Criar um grupo gerenciado de instâncias com dual-stack-gateway-template:

   gcloud alpha compute instance-templates create dual-stack-gateway-template \
   --region=REGION \
   --image-family=debian-12 \
   --image-project=debian-cloud \
   --tags=dual-stack-http-server \
   --network=NETWORK \
   --subnet=SUBNET \
   --stack-type=IPV4_IPV6 \
   --service-proxy=enabled,scope=gateway-proxy
   

2. Criar um grupo gerenciado de instâncias de proxy de gateway:

   gcloud compute instance-groups managed create dual-stack-ZONE-gateway-mig \
   --zone=ZONE \
   --size=1 \
   --template=dual-stack-gateway-template
   

3. Criar um grupo gerenciado de instâncias de back-end:

   gcloud compute instance-templates create dual-stack-backend-template \
     --region=REGION \
     --image-family=debian-12 \
     --image-project=debian-cloud \
     --tags=dual-stack-http-server \
     --network=NETWORK \
     --subnet=SUBNET \
     --stack-type=IPV4_IPV6 \
     --metadata=startup-script="#! /bin/bash
   sudo apt-get update -y
   sudo apt-get install apache2 -y
   sudo service apache2 restart
   echo '<!doctype <html><body><h1>'\`dual-stack-server\`'</h1></body></html>' | sudo tee /var/www/html/index.html"
   

   gcloud compute instance-groups managed create dual-stack-ZONE-backend-mig \
   --zone=ZONE \
   --size=1 \
   --template=dual-stack-backend-template
   

4. Adicionar uma porta nomeada ao grupo gerenciado de instâncias:

   gcloud compute instance-groups set-named-ports us-ig-1 \
     --named-ports http:80 \
     --zone ZONE \
   
   gcloud compute instance-groups set-named-ports us-ig-2 \
     --named-ports http:80 \
     --zone ZONE
   

   Usamos verificações de integridade separadas para balanceamento de carga e recuperação automática. As verificações de integridade para balanceamento de carga são normalmente configuradas para serem mais agressivas, porque determinam se uma VM recebe tráfego do usuário e se você quer redirecionar o tráfego rapidamente, se necessário.

   A verificação de integridade para recuperação automática faz com que o Compute Engine substitua proativamente as VMs com falha. Portanto, essa verificação de integridade precisa ser mais conservadora do que uma verificação de integridade de balanceamento de carga. A recuperação automática para VMs de pilha dupla será baseada em verificações de integridade IPv4.

5. Crie uma verificação de integridade:

   gcloud compute health-checks create http dualstack-health-check-http \
   

6. Verifique se as regras de firewall permitem verificações de integridade:

   IPv4

   gcloud compute firewall-rules create dual-stack-allow-ipv4-health-check \
   --network=NETWORK \
   --action=ALLOW \
   --direction=INGRESS \
   --source-ranges=35.191.0.0/16,130.211.0.0/22 \
   --target-tags=dual-stack-http-server \
   --rules=tcp:22,80
   

   IPv6

   gcloud compute firewall-rules create dual-stack-allow-ipv6-health-check \
   --network=NETWORK \
   --action=ALLOW \
   --direction=INGRESS \
   --source-ranges=::/0 \
   --target-tags=dual-stack-http-server \
   --rules=tcp:22,80
   

7. Aplique a verificação de integridade configurando uma política de recuperação automática para o MIG:

   gcloud compute instance-groups managed update us-mig-1 \
     --health-check dualstack-health-check-http \
     --initial-delay 300 \
     --zone us-central1-a
   

A configuração de atraso inicial atrasa a recuperação automática da recriação prematura da VM, caso ela esteja em processo de inicialização. O timer de atraso inicial começa quando o campo currentAction da VM muda para VERIFYING.

Grupos não gerenciados de instâncias

1. Configurar grupos de instâncias:

   gcloud compute instance-groups unmanaged create us-ig-1 \
   --zone us-central1-a \
   
   gcloud compute instance-groups unmanaged create us-ig-2 \
   --zone us-central1-b
   

2. Criar duas instâncias de VM de pilha dupla em cada grupo de instâncias:

   gcloud compute instances create inst-us-central1-1 \
   --image-family debian-12 \
   --image-project debian-cloud \
   --tags network-lb \
   --zone us-central1-a \
   --network-interface [--network=NETWORK | --subnet=SUBNET] \
   --stack-type=IPV4_IPV6 \
   
   gcloud compute instances create inst-us-central1-2 \
   --image-family debian-12 \
   --image-project debian-cloud \
   --tags network-lb \
   --zone us-central1-a \
   --network-interface [--network=NETWORK | --subnet=SUBNET] \
   --stack-type=IPV4_IPV6 \
   
   gcloud compute instances create inst-us-central1-3 \
   --image-family debian-12 \
   --image-project debian-cloud \
   --tags network-lb \
   --zone us-central1-b \
   --network-interface [--network=NETWORK | --subnet=SUBNET] \
   --stack-type=IPV4_IPV6 \
   
   gcloud compute instances create inst-us-central1-4 \
   --image-family debian-12 \
   --image-project debian-cloud \
   --tags network-lb \
   --zone us-central1-b \
   --network-interface [--network=NETWORK | --subnet=SUBNET] \
   --stack-type=IPV4_IPV6
   

   O endereço IPv6 será atribuído automaticamente.

3. Adicionar VMs a grupos de instâncias:

   gcloud compute instance-groups unmanaged add-instances us-ig-1 \
   --instances inst-us-central1-1,inst-us-central1-2 \
   --zone us-central1-a \
   
   gcloud compute instance-groups unmanaged add-instances us-ig-2 \
   --instances inst-us-central1-3,inst-us-central1-4 \
   --zone us-central1-b
   

NEG

1. Adicionar um back-end em que --network-endpoint-type seja GCE_VM_IP_PORT:

   gcloud compute network-endpoint-groups create us-neg-lb-1 \
     --network=NETWORK SUBNET \
     --zone=us-central1-a --network-endpoint-type=GCE_VM_IP_PORT \
   
   gcloud compute network-endpoint-groups create us-neg-lb-2 \
     --network=NETWORK SUBNET \
     --zone=us-central1-b  --network-endpoint-type=GCE_VM_IP_PORT
   

2. Adicionar endpoints ao grupo de endpoints de rede:

   gcloud compute network-endpoint-groups update us-neg-lb-1 \--zone=us-central1-a \
   --add-endpoint 'instance=inst-us-central1-1,ip=IPV4_ADRS_1, ipv6=IPV6_ADRS_1,port=80' \
   --add-endpoint 'instance=inst-us-central1-2,ip=IPV4_ADRS_2, ipv6=IPV6_ADRS_2,port=80' \
   
   gcloud compute network-endpoint-groups update us-neg-lb-2 --zone=us-central1-b \
   --add-endpoint 'instance=inst-us-central1-3,ip=IPV4_ADRS_3, ipv6=IPV6_ADRS_3,port=80' \
   --add-endpoint 'instance=inst-us-central1-4,ip=IPV4_ADRS_4,ipv6=IPV6_ADRS_4,port=80'
   

Configurar a verificação de integridade

1. Criar uma verificação de integridade para o serviço de back-end:

     gcloud compute health-checks create http[s] my-health-check 
   
       --global 
   
       --request-path '/' 
   
       --port SERVICE_PORT
     

   Substitua SERVICE_PORT pelo número da porta, de 1 a 65535.

2. Criar uma regra de firewall para permitir verificações de integridade:

   gcloud compute firewall-rules create allow-scan-probe \
       --action allow \
       --description "allow-scan-probe" \
       --rules tcp:SERVICE_PORT \
       --source-ranges 2600:2d00:1:b029::/64 \
       --priority 10 \
       --network=NETWORK
   

O intervalo 2600:2d00:1:b029::/64 é usado para os endereços IP de origem dos verificadores de integridade para testar a integridade das VMs. O endereço 2600:2d00:1:b029::/64 é usado como o endereço IP de origem para verificadores de integridade IPv6 para testar a integridade da VM de back-end do balanceamento de carga de rede.

Criar e atualizar o serviço de back-end com back-ends

1. Crie o serviço de back-end:

   gcloud compute backend-services create my-backend-service \
   --ip-address-selection-policy PREFER_IPV6  \
   --global \
   --health-checks my-health-check \
   --load-balancing-scheme=INTERNAL_SELF_MANAGED \
   --timeout=5m
   

2. Adicione os back-ends ao serviço de back-end:

   gcloud compute backend-services add-backend my-backend-service \
   --instance-group us-ig-1 \
   --instance-group-zone us-central1-a \
   --global \
   
   gcloud compute backend-services add-backend my-backend-service \
   --instance-group us-ig-2 \
   --instance-group-zone us-central1-b \
   --global
   

Configurar um serviço do Cloud Service Mesh

Esta seção mostra como configurar um serviço IPv6 no Traffic Director. O serviço pode fazer parte de uma configuração do Service Mesh ou ser usado para configurar um gateway de serviço, como uma VM que executa o Envoy.

Agora que os serviços de back-end com PREFER_IPV6 estão configurados, é possível criar um recurso de gateway appnet.

Criar um recurso de gateway

1. Em um arquivo chamado dual-stack-gateway.yaml, crie a especificação do gateway para o tráfego HTTP:

   cat <<EOF | tee dual-stack-gateway.yaml
   name: dual-stack-gateway
   scope: gateway-proxy
   ipVersion: IPV6
   ports:
   - 80
   type: OPEN_MESH
   EOF
   

2. Crie o recurso de gateway na especificação dual-stack-gateway.yaml:

   gcloud network-services gateways import dual-stack-gateway \
     --source=dual-stack-gateway.yaml \
     --location=global
   

Configurar o roteamento com HTTPRoute

1. Em um arquivo chamado dual-stack-http_route.yaml, crie a especificação HTTPRoute:

   cat <<EOF | tee dual-stack-http-route.yaml
   name: dual-stack-http-route
   hostnames:
   - dual-stack-server
   gateways:
   - projects/PROJECT_ID/locations/global/gateways/dual-stack-gateway
   rules:
   - action:
       destinations:
       - serviceName: "projects/PROJECT_ID/locations/global/backendServices/dual-stack-backend-service"
   EOF
   

2. Use a especificação em dual-stack-http-route.yaml para criar o recurso HTTPRoute.

   gcloud network-services http-routes import dual-stack-http-route \
     --source=dual-stack-http-route.yaml \
     --location=global
   

3. Para verificar a conectividade de ponta a ponta, faça SSH na VM do MIG do gateway e execute o seguinte comando:

   curl -H 'Host: dual-stack-server' http://[::]
   

   A saída é semelhante a:

   <!doctype <html><body><h1>'`dual-stack-server`'</h1></body></html>
   

Migrar de IPv4 para pilha dupla

É preciso atender aos seguintes pré-requisitos antes de migrar do IPv4 para a pilha dupla:

• Grupos de instâncias de VM de pilha única us-ig-1 e us-ig-2 com pilha IPV4_ONLY com VMs atuais
• Um único serviço de back-end IPv4 my-ipv4-backend-service apontando para us-ig-1 e us-ig-2
• Uma sub-rede de VM IPV4_ONLY
• Um recurso de gateway configurado com um endereço de versão IPv4

Fazer upgrade da sub-rede para pilha dupla

Atualize a sub-rede atual para que o back-end seja compatível com IPv6:

gcloud compute networks subnets update SUBNET \
  --stack-type IPV4_IPV6 \
  --ipv6-access-type=IPv6_ACCESS_TYPE \

Substitua:

• SUBNET: um nome para a nova sub-rede.
• IPv6_ACCESS_TYPE: o tipo de acesso IPv6. Pode ser EXTERNAL ou INTERNAL.

Fazer upgrade de cada VM para pilha dupla

gcloud compute instances network-interfaces update EXISTING_VM_NAME \
  --stack-type=IPV4_IPV6 \
  --zone=us-central1

Substitua EXISTING_VM_NAME pelo nome da VM atual.

Adicionar novas VMs de pilha dupla a cada grupo de instâncias

1. Criar novas instâncias de VM:

   gcloud compute instances create my-new-vm-1 \
     --image-family debian-12 \
     --tags network-lb \
     --zone us-central1-a \
     --network-interface [--network=NETWORK | --subnet=SUBNET] \
     --stack-type=IPV4_IPV6 \
   
   gcloud compute instances create my-new-vm-2 \
     --image-family debian-12 \
     --tags network-lb \
     --zone us-central1-b \
     --network-interface [--network=NETWORK | --subnet=SUBNET] \
     --stack-type=IPV4_IPV6
   

2. Adicionar as novas instâncias a grupos de instâncias:

   gcloud compute instance-groups unmanaged add-instances us-ig-1 \
     --instances my-new-vm-1 \
     --zone us-central1-a \
   
   gcloud compute instance-groups unmanaged add-instances us-ig-2 \
     --instances my-new-vm-2 \
     --zone us-central1-b
   

3. Criar um serviço de back-end IPv6:

   gcloud compute backend-services create dual-stack-backend-service \
     --global \
     --load-balancing-scheme=INTERNAL_SELF_MANAGED \
     --protocol=HTTP \
     --health-checks=dual-stack-health-check-http \
     --ip-address-selection-policy=PREFER_IPV6
   

4. Adicionar o grupo de instâncias atualizado ao serviço de back-end de pilha dupla recém-criado:

   gcloud compute backend-services add-backend dual-stack-backend-service \
     --instance-group=us-ig-1 \
     --instance-group-zone=ZONE \
     --global
   

   gcloud compute backend-services add-backend dual-stack-backend-service \
     --instance-group=us-ig-2 \
     --instance-group-zone=ZONE \
     --global
   

Migrar de pilha dupla para IPv4

É preciso atender aos seguintes pré-requisitos antes de migrar da pilha dupla para o IPv4:

• Grupos de instâncias de VM de pilha dupla us-ig-1 e us-ig-2 com pilha IPV4_IPV6 com VMs atuais
• Um único serviço de back-end IPv6 my-ipv6-backend-service apontando para us-ig-1 e us-ig-2
• Uma sub-rede de VM IPV4_IPV6
• Um recurso de gateway

Fazer downgrade de cada VM para IPv4

gcloud compute instances network-interfaces update EXISTING_VM_NAME \
  --stack-type=IPV4_ONLY \
  --zone=us-central1

Adicionar novas VMs de pilha IPv4 a cada grupo de instâncias

1. Criar novas instâncias de VM:

   gcloud compute instances create my-new-vm-1 \
     --image-family debian-12 \
     --tags network-lb \
     --zone us-central1-a \
     --network-interface [--network=NETWORK | --subnet=SUBNET] \
     --stack-type=IPV4_ONLY \
   
   gcloud compute instances create my-new-vm-2 \
     --image-family debian-12 \
     --tags network-lb \
     --zone us-central1-b \
     --network-interface [--network=NETWORK | --subnet=SUBNET] \
     --stack-type=IPV4_ONLY
   

2. Adicionar as novas instâncias a grupos de instâncias:

   gcloud compute instance-groups unmanaged add-instances us-ig-1 \
     --instances my-new-vm-1 \
     --zone us-central1-a \
   
   gcloud compute instance-groups unmanaged add-instances us-ig-2 \
     --instances my-new-vm-2 \
     --zone us-central1-b
   

3. Criar um serviço de back-end IPv4:

   gcloud compute backend-services create my-ipv4-backend-service \
     –ip-address-selection-policy IPV4_ONLY \
     --global \
     --health-checks my-health-check \
     --load-balancing-scheme INTERNAL_SELF_MANAGED \
     --timeout=5m
   

4. Adicionar os grupos de instâncias atualizados ao serviço de back-end IPv4 recém-criado:

   gcloud compute backend-services add-backend my-ipv4-backend-service \
     --instance-group us-ig1 \
     --instance-group-zone us-central1-a \
     --global \
   
   gcloud compute backend-services add-backend my-ipv4-backend-service \
     --instance-group us-ig2 \
     --instance-group-zone us-central1-b \
     --global
   

   Agora, os serviços de back-end IPv4 e IPv6 podem veicular tráfego. Atualize o mapa de URL para direcionar parte do tráfego do cliente para o novo serviço de back-end IPv4.