Configura la pila doble IPv6 para Cloud Service Mesh

Nota: Esta guía solo admite Cloud Service Mesh con APIs de Google Cloud y no admite APIs de Istio. Para obtener más información, consulta la descripción general de Cloud Service Mesh.

En esta página, se muestra cómo balancear el tráfico IPv6 en Cloud Service Mesh con balanceadores de cargas basados en proxy de Traffic Director (TD), así como cómo migrar de implementaciones basadas en IPv4 a implementaciones de pila doble (IPv4 e IPv6) y cómo migrar de pila doble a IPv4.

En las implementaciones de pila doble, tienes la opción de indicar si se envía IPv4 o IPv6 al backend del servicio. El proxy o el cliente de gRPC prueba cada ruta de datos en tu orden de preferencia y selecciona la que se alinea con tu preferencia y lo que se admite.

Las funciones de pila doble son compatibles con gRPC 1.66.1 y versiones posteriores para C++ y Python, 1.12 y versiones posteriores para Node, y 1.71 y versiones posteriores para Go. Java no es compatible en este momento.

Versiones de gRPC sin compatibilidad con pila doble (es decir, Go y versiones anteriores a la 1.66 en otros idiomas) usarán solo la primera dirección de cada extremo, en el orden que envíe TD.

Antes de comenzar

En esta guía, se da por sentado que ya hiciste lo siguiente:

• Configura las APIs de enrutamiento de servicios con Envoy y cargas de trabajo sin proxy.
• Completaste los pasos de la sección Continúa el proceso de configuración de la guía de integración.

Configura el servicio de backend de IPv6

En esta sección, configurarás lo siguiente:

• Dos grupos de backend (ya sean grupos de instancias, grupos de instancias administrados o grupos de extremos de red), uno en cada una de dos zonas diferentes dentro de la misma región
• Dos instancias de VM en cada grupo de backend
• Una verificación de estado para confirmar el funcionamiento de las instancias.
• Reglas de firewall que permiten que las verificaciones de estado lleguen a los backends
• Un servicio de backend.
• El servicio de backend para incluir los dos grupos de backend configurados

Configura una subred para tus backends

El siguiente comando asigna rangos de direcciones internas para IPv4 e IPv6, y permite que las VMs de la subred se asignen con cualquier tipo de dirección.

Ten en cuenta que solo se admiten subredes de modo personalizado. No se admite el modo automático. Puedes cambiar al modo personalizado para toda la red de VPC y, luego, propagar los backends de IPv6 (MIG o NEG).

1. Crea una red de pila doble:

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

2. Crea una subred de pila doble para las VMs de backend:

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

   Reemplaza lo siguiente:

   • SUBNET: Es un nombre para la subred nueva.
   • NETWORK: Es el nombre de la red de VPC que contendrá la subred nueva.
   • PRIMARY_IPv4_RANGE: Es el rango IPv4 principal para la subred nueva, en notación CIDR. Para obtener más información, consulta Rangos de subredes IPv4.
   • IPv6_ACCESS_TYPE: Es el tipo de acceso IPv6. Puede ser EXTERNAL o INTERNAL.
   • REGION: Es la Google Cloud región en la que se creará la subred.

Configura backends

Puedes usar grupos de instancias administrados (MIG), grupos de instancias no administrados o grupos de extremos de red (NEG).

MIG

1. Crea un grupo de instancias administrado con 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. Crea un grupo de instancias administrado de proxy de puerta de enlace:

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

3. Crea un grupo de instancias administrado de backend:

   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. Agrega un puerto con nombre al grupo de instancias administrado:

   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 verificaciones de estado separadas para el balanceo de cargas y la reparación automática. Por lo general, las verificaciones de estado para el balanceo de cargas se configuran para ser más agresivas, ya que determinan si una VM recibe tráfico de usuarios y si deseas redireccionar el tráfico rápidamente si es necesario.

   La verificación de estado para la reparación automática hace que Compute Engine reemplace de forma proactiva las VMs que fallan, por lo que esta verificación debería ser más conservadora que una verificación de estado del balanceo de cargas. Ten en cuenta que la reparación automática de las VMs de pila doble se basará en las verificaciones de estado de IPv4.

5. Crea una verificación de estado de la siguiente forma:

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

6. Asegúrate de que las reglas de firewall permitan las verificaciones de estado:

   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. Aplica la verificación de estado mediante la configuración de una política de reparación automática para tu MIG:

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

La configuración de initial-delay retrasa la reparación automática para que no se lleve a cabo una potencial recreación prematura de la VM si esta está en proceso de inicio. El temporizador de retraso inicial comienza cuando el campo currentAction de la VM cambia a VERIFYING.

Grupos de instancias no administrados

1. Configura grupos de instancias:

   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. Crea dos instancias de VM de doble pila en cada grupo de instancias:

   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
   

   La dirección IPv6 se asignará automáticamente.

3. Agrega VMs a los grupos de instancias:

   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. Agrega un backend en el que --network-endpoint-type sea 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. Agrega extremos al grupo de extremos de red:

   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'
   

Configura la verificación de estado

1. Crea una verificación de estado para el servicio de backend:

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

   Reemplaza SERVICE_PORT por el número de puerto, de 1 a 65535.

2. Crea una regla de firewall para permitir las verificaciones de estado:

   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
   

El rango 2600:2d00:1:b029::/64 se usa para las direcciones IP de origen de los verificadores de estado para sondear el estado de las VMs. Ten en cuenta que 2600:2d00:1:b029::/64 se usa como la dirección IP de origen para los verificadores de estado IPv6 para sondear el estado de la VM de backend del balanceo de cargas de red.

Crea y actualiza el servicio de backend con Backends

1. Crea el servicio de backend:

   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. Agrega los backends al servicio de backend:

   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
   

Configura un servicio de Cloud Service Mesh

En esta sección, se muestra cómo configurar un servicio IPv6 en Traffic Director. El servicio puede ser parte de una configuración de Service Mesh o puede usarse para configurar una puerta de enlace de servicio, como una VM que ejecuta Envoy.

Ahora que se configuraron los servicios de backend con PREFER_IPV6, puedes crear un recurso de puerta de enlace de appnet.

Crea un recurso de puerta de enlace

1. En un archivo llamado dual-stack-gateway.yaml, crea la especificación de la puerta de enlace para el tráfico HTTP:

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

2. Crea el recurso de puerta de enlace a partir de la especificación dual-stack-gateway.yaml:

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

Configura el enrutamiento con HTTPRoute

1. En un archivo llamado dual-stack-http_route.yaml, crea la especificación 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. Usa la especificación de dual-stack-http-route.yaml para crear el recurso HTTPRoute.

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

3. Para verificar la conectividad de extremo a extremo, establece una conexión SSH a la VM desde la MIG de la puerta de enlace y ejecuta el siguiente comando:

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

   El resultado es similar al siguiente:

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

Migra de IPv4 a pila doble

Debes cumplir con los siguientes requisitos previos para poder migrar de IPv4 a doble pila:

• Grupos de instancias de VM de pila única existentes us-ig-1 y us-ig-2 con pila IPV4_ONLY con VMs existentes
• Un solo servicio de backend IPv4 my-ipv4-backend-service que apunta a us-ig-1 y us-ig-2
• Una subred de VM IPV4_ONLY
• Un recurso de puerta de enlace configurado con una dirección de versión IPv4

Actualiza la subred a pila doble

Actualiza la subred existente para que el backend admita IPv6:

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

Reemplaza lo siguiente:

• SUBNET: Es un nombre para la subred nueva.
• IPv6_ACCESS_TYPE: Es el tipo de acceso IPv6. Puede ser EXTERNAL o INTERNAL.

Actualiza cada VM a la pila doble

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

Reemplaza EXISTING_VM_NAME por el nombre de tu VM existente.

Agrega nuevas VMs de pila doble a cada grupo de instancias

1. Crea instancias de VM nuevas:

   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. Agrega las instancias nuevas a los grupos de instancias:

   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. Crea un servicio de backend de 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. Agrega el grupo de instancias actualizado al servicio de backend de pila doble que acabas de crear:

   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
   

Migra de pila doble a IPv4

Debes cumplir con los siguientes requisitos previos para poder migrar de la pila doble a IPv4:

• Grupos de instancias de VM de doble pila existentes us-ig-1 y us-ig-2 con pila IPV4_IPV6 con VMs existentes
• Un solo servicio de backend IPv6 my-ipv6-backend-service que apunta a us-ig-1 y us-ig-2
• Una subred de VM IPV4_IPV6
• Un recurso de puerta de enlace

Revierte cada VM a IPv4

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

Agrega nuevas VMs de pila IPv4 a cada grupo de instancias

1. Crea instancias de VM nuevas:

   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. Agrega las instancias nuevas a los grupos de instancias:

   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. Crea un servicio de backend de 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. Agrega los grupos de instancias actualizados al servicio de backend de IPv4 recién creado:

   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
   

   Ahora, los servicios de backend IPv4 e IPv6 pueden entregar tráfico. Actualiza el mapa de URL para dirigir una fracción del tráfico del cliente al nuevo servicio de backend IPv4.