Configurar el doble pila 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 explica cómo balancear la carga del tráfico IPv6 en Cloud Service Mesh mediante balanceadores de carga basados en proxy de Traffic Director (TD), así como migrar de implementaciones basadas en IPv4 a implementaciones de doble pila (IPv4 e IPv6) y migrar de doble pila a IPv4.

En las implementaciones de doble pila, puede 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 el orden de preferencia y selecciona la que se ajusta a tu preferencia y a lo que se admite.

Las funciones de pila dual se admiten en 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 se admite en este momento.

Versiones de gRPC sin compatibilidad con pila dual (es decir, Go y las versiones anteriores a la 1.66 en otros idiomas) solo usarán la primera dirección de cada endpoint, en el orden enviado por TD.

Antes de empezar

En esta guía se da por hecho que ya has hecho lo siguiente:

• Configura las APIs de enrutamiento de servicios con Envoy y cargas de trabajo sin proxy.
• Has completado los pasos de la sección Continuar con el proceso de configuración de la guía de incorporación.

Configurar el servicio de backend IPv6

En esta sección, puede configurar lo siguiente:

• Dos grupos de backend (grupos de instancias, grupos de instancias gestionadas o grupos de puntos finales de red), uno en cada una de las dos zonas de la misma región.
• Dos instancias de VM en cada grupo de backend.
• Comprobación del estado para verificar el estado de la instancia.
• Reglas de cortafuegos que permiten que las comprobaciones del estado lleguen a los backends.
• Un servicio de backend.
• El servicio de backend que incluye los dos grupos de backend configurados.

Configurar una subred para las back-ends

El siguiente comando asigna intervalos de direcciones internas tanto para IPv4 como para IPv6, y permite que se asignen a las VMs de la subred direcciones de cualquiera de los dos tipos.

Ten en cuenta que solo se admiten subredes en modo personalizado. No hay compatibilidad con el modo automático. Puedes cambiar al modo personalizado para toda la red VPC y, a continuación, rellenar los back-ends IPv6 (MIGs o NEGs).

1. Crea una red de doble pila:

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

2. Crea una subred de doble pila 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
   

   Haz los cambios siguientes:

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

Configurar backends

Puedes usar grupos de instancias gestionados (MIG), grupos de instancias no gestionados o grupos de puntos finales de red (NEG).

MIG

1. Crea un grupo de instancias gestionado 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 gestionado de proxy de pasarela:

   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 gestionado 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. Añade un puerto con nombre al grupo de instancias gestionado:

   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 comprobaciones del estado independientes para el balanceo de carga y la reparación automática. Las comprobaciones del estado para el balanceo de carga suelen configurarse para que sean más agresivas, ya que determinan si una VM recibe tráfico de usuarios y si quieres redirigir el tráfico rápidamente en caso necesario.

   La comprobación del estado para la reparación automática hace que Compute Engine sustituya de forma proactiva las VMs que fallan, por lo que esta comprobación del estado debe ser más conservadora que una comprobación del estado de balanceo de carga. Ten en cuenta que la reparación automática de las VMs de doble pila se basará en comprobaciones del estado de IPv4.

5. Crea una comprobación del estado:

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

6. Asegúrate de que las reglas de cortafuegos permitan las comprobaciones del 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 comprobación de estado configurando una política de recuperació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
   

El ajuste initial-delay retrasa la reparación automática para evitar que se vuelva a crear la VM prematuramente si esta está en proceso de iniciarse. El temporizador de retardo inicial se inicia cuando el campo currentAction de la máquina virtual cambia a VERIFYING.

Grupos de instancias sin gestionar

1. Configurar 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 pila dual 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. Añade VMs a 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. Añade un backend donde --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. Añade puntos finales al grupo de puntos finales 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'
   

Configurar comprobación del estado

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

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

   Sustituye SERVICE_PORT por el número de puerto, que debe estar comprendido entre 1 y 65535.

2. Crea una regla de cortafuegos para permitir las comprobaciones del 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 intervalo 2600:2d00:1:b029::/64 se usa para las direcciones IP de origen de los comprobadores de estado para sondear el estado de las VMs. Ten en cuenta que 2600:2d00:1:b029::/64 se usa como dirección IP de origen para los comprobadores de estado de IPv6 con el fin de sondear el estado de las VMs de backend del balanceo de carga de red.

Crear y actualizar un 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. Añade 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
   

Configurar un servicio de Cloud Service Mesh

En esta sección se muestra cómo configurar un servicio IPv6 en Traffic Director. El servicio puede formar parte de una configuración de Service Mesh o usarse para configurar una puerta de enlace de servicio, como una máquina virtual que ejecute Envoy.

Ahora que los servicios de backend con PREFER_IPV6 están configurados, puedes crear un recurso de pasarela de appnet.

Crear un recurso de pasarela

1. En un archivo llamado dual-stack-gateway.yaml, crea la especificación de Gateway 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 Gateway 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
   

Configurar 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, conéctate a la máquina virtual mediante SSH desde la MIG de la pasarela y ejecuta el siguiente comando:

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

   La salida es similar a la siguiente:

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

Migrar de IPv4 a pila dual

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

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

Actualizar la subred a dual-stack

Actualiza la subred del backend para que admita IPv6:

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

Haz los cambios siguientes:

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

Actualiza cada VM a dual-stack

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

Sustituye EXISTING_VM_NAME por el nombre de tu máquina virtual.

Añadir nuevas VMs de doble pila a cada grupo de instancias

1. Crea instancias 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. Añade las nuevas instancias 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 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. Añade el grupo de instancias actualizado al servicio de backend de pila dual recién creado:

   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 pila dual a IPv4

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

• Grupos de instancias de VM de doble pila us-ig-1 y us-ig-2 con IPV4_IPV6 con VMs
• Un único servicio de backend IPv6 my-ipv6-backend-service que apunta a us-ig-1 y us-ig-2
• Una subred de máquina virtual IPV4_IPV6
• Un recurso de pasarela

Cambiar cada VM a IPv4

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

Añadir nuevas VMs con pila IPv4 a cada grupo de instancias

1. Crea instancias 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. Añade las nuevas instancias 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 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. Añade los grupos de instancias actualizados al servicio de backend 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, tanto los servicios de backend IPv4 como los IPv6 pueden servir tráfico. Actualiza el mapa de URLs para dirigir una parte del tráfico de clientes al nuevo servicio backend IPv4.