Anthos Service Mesh et Traffic Director sont désormais Cloud Service Mesh. Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Configurer la double pile IPv6 pour Cloud Service Mesh

Cette page explique comment équilibrer la charge du trafic IPv6 sur Cloud Service Mesh à l'aide d'équilibreurs de charge basés sur un proxy Traffic Director (TD). Elle explique également comment migrer des déploiements basés sur IPv4 vers des déploiements à double pile (IPv4 et IPv6) et comment migrer des déploiements à double pile vers IPv4.

Dans les déploiements à double pile, vous pouvez indiquer si IPv4 ou IPv6 est envoyé au backend du service. Le proxy ou le client gRPC testent chaque chemin de données selon votre ordre de préférence et sélectionnent celui qui correspond à votre préférence et à ce qui est pris en charge.

Les fonctionnalités à double pile sont compatibles avec gRPC 1.66.1 et versions ultérieures pour C++ et Python, 1.12 et versions ultérieures pour Node, et 1.71 et versions ultérieures pour Go. Java n'est pas compatible pour le moment.

Versions de gRPC sans compatibilité double pile (c'est-à-dire Go et les versions antérieures à 1.66 dans d'autres langues) n'utiliseront que la première adresse de chaque point de terminaison, dans l'ordre envoyé par TD.

Avant de commencer

Ce guide suppose que vous avez déjà :

Configurer les API de routage de services avec des charges de travail Envoy et sans proxy
Vous avez suivi les étapes de la section Poursuivre le processus de configuration du guide d'intégration.

Configurer le service de backend IPv6

Dans cette section, vous allez configurer les éléments suivants :

Deux groupes de backend (groupes d'instances, groupes d'instances gérés ou groupes de points de terminaison réseau), un dans chacune des deux zones différentes d'une même région.
Deux instances de VM dans chaque groupe de backend.
Une vérification de l'état pour examiner l'état de l'instance.
Règles de pare-feu autorisant les vérifications d'état à atteindre les backends.
Un service de backend
Le service de backend pour inclure les deux groupes de backends configurés.

Configurer un sous-réseau pour vos backends

La commande suivante alloue des plages d'adresses internes pour IPv4 et IPv6, et permet d'attribuer aux VM du sous-réseau l'un ou l'autre type d'adresse.

Notez que seuls les sous-réseaux en mode personnalisé sont acceptés. Le mode automatique n'est pas compatible. Vous pouvez passer en mode personnalisé pour l'ensemble du réseau VPC, puis renseigner les backends IPv6 (MIG ou NEG).

Créez un réseau à double pile :

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

Créez un sous-réseau à double pile pour les VM 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
```
Remplacez les éléments suivants :
- SUBNET : Nom du nouveau sous-réseau.
- NETWORK: nom du réseau VPC qui contiendra le nouveau sous-réseau.
- PRIMARY_IPv4_RANGE : plage d'adresses IPv4 principales pour le nouveau sous-réseau, au format CIDR. Pour en savoir plus, consultez la section sur les plages de sous-réseaux IPv4.
- IPv6_ACCESS_TYPE: type d'accès IPv6. Il peut s'agir de EXTERNAL ou de INTERNAL.
- REGION : région Google Cloud dans laquelle le nouveau sous-réseau sera créé.

Configurer des backends

Vous pouvez choisir d'utiliser des groupes d'instances gérés (MIG), des groupes d'instances non gérés ou des groupes de points de terminaison du réseau (NEG).

MIG

Créez un groupe d'instances géré avec 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

Créez un groupe d'instances géré pour le proxy de passerelle :

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

Créez un groupe d'instances géré pour le 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

Ajoutez un port nommé au groupe d'instances géré :
```
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
```
Nous utilisons des vérifications d'état distinctes pour l'équilibrage de charge et l'autoréparation. Les vérifications de l'état pour l'équilibrage de charge sont généralement configurées pour être plus agressives, car elles déterminent si une VM reçoit du trafic utilisateur et si vous souhaitez rediriger rapidement le trafic si nécessaire.

Les vérifications de l'état pour l'autoréparation entraînent le remplacement proactif des VM défaillantes par Compute Engine. Ces vérification de l'état de l'état devraient donc être plus conservatrices que vérification de l'état destinées à l'équilibrage de charge. Notez que l'autoréparation des VM à double pile sera basée sur les vérifications d'état IPv4.

Créez une vérification d'état :

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

Assurez-vous que les règles de pare-feu autorisent les vérifications de l'état :

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

Appliquez la vérification de l'état en configurant une règle d'autoréparation pour votre MIG :

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

Le paramètre "initial-delay" permet de retarder l'autoréparation et la potentielle recréation prématurée de la VM si celle-ci est en cours de démarrage. Le délai initial commence au moment où le champ currentAction de la VM passe à VERIFYING.

Groupes d'instances non gérés

Configurer des groupes d'instances :

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

Créez deux instances de VM à double pile dans chaque groupe d'instances :

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

L'adresse IPv6 sera attribuée automatiquement.

Ajoutez des VM aux groupes d'instances :

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

Ajoutez un backend où --network-endpoint-type est 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

Ajoutez des points de terminaison au groupe de points de terminaison du réseau :

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'

Configurer la vérification de l'état

Créez une vérification d'état pour le service de backend :

  gcloud compute health-checks create http[s] my-health-check 

    --global 

    --request-path '/' 

    --port SERVICE_PORT

Remplacez SERVICE_PORT par le numéro de port (entre 1 et 65 535).

Créez une règle de pare-feu pour autoriser les vérifications de l'état :

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

La plage 2600:2d00:1:b029::/64 est utilisée pour les adresses IP sources des vérificateurs d'état afin de vérifier l'état des VM. Notez que 2600:2d00:1:b029::/64 est utilisé comme adresse IP source pour les vérificateurs d'état IPv6 afin de vérifier l'état des VM de backend de l'équilibrage de charge réseau.

Créer et mettre à jour un service de backend avec des backends

Créez le service 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

Ajoutez les backends au service 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

Configurer un service Cloud Service Mesh

Cette section explique comment configurer un service IPv6 dans Traffic Director. Le service peut faire partie d'une configuration Service Mesh ou être utilisé pour configurer une passerelle de service telle qu'une VM exécutant Envoy.

Maintenant que les services de backend avec PREFER_IPV6 sont configurés, vous pouvez créer une ressource de passerelle appnet.

Créer une ressource de passerelle

Dans un fichier nommé dual-stack-gateway.yaml, créez la spécification Gateway pour le trafic HTTP :

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

Créez la ressource Gateway à partir de la spécification dual-stack-gateway.yaml :

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

Configurer le routage avec HTTPRoute

Dans un fichier nommé dual-stack-http_route.yaml, créez la spécification 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

Utilisez la spécification dans dual-stack-http-route.yaml pour créer la ressource HTTPRoute.

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

Pour vérifier la connectivité de bout en bout, connectez-vous en SSH à la VM depuis le MIG de passerelle et exécutez la commande suivante :
```
curl -H 'Host: dual-stack-server' http://[::]
```
Le résultat est semblable à :
```
<!doctype <html><body><h1>'`dual-stack-server`'</h1></body></html>
```

Migrer d'IPv4 vers la double pile

Avant de pouvoir migrer d'IPv4 vers le double pile, vous devez remplir les conditions préalables suivantes :

Groupes d'instances de VM à pile unique existants us-ig-1 et us-ig-2 avec pile IPV4_ONLY avec les VM existantes
Un seul service de backend IPv4 my-ipv4-backend-service pointant vers us-ig-1 et us-ig-2
Un sous-réseau de VM IPV4_ONLY
Ressource de passerelle configurée avec une adresse de version IPv4

Mettre à niveau le sous-réseau vers une double pile

Mettez à jour le sous-réseau existant pour le backend afin qu'il soit compatible avec IPv6 :

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

Remplacez les éléments suivants :

SUBNET : Nom du nouveau sous-réseau.
IPv6_ACCESS_TYPE: type d'accès IPv6. Il peut s'agir de EXTERNAL ou de INTERNAL.

Mettre à niveau chaque VM vers la double pile

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

Remplacez EXISTING_VM_NAME par le nom de votre VM.

Ajouter des VM à double pile à chaque groupe d'instances

Créez des instances 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

Ajoutez les nouvelles instances aux groupes d'instances :

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

Créez un service 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

Ajoutez le groupe d'instances mis à jour au service de backend double pile nouvellement créé :

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

Migrer de la double pile vers IPv4

Avant de pouvoir migrer d'une pile double vers IPv4, vous devez remplir les conditions préalables suivantes :

Groupes d'instances de VM à double pile existants us-ig-1 et us-ig-2 avec pile IPV4_IPV6 avec les VM existantes
Un seul service de backend IPv6 my-ipv6-backend-service pointant vers us-ig-1 et us-ig-2
Sous-réseau de VM IPV4_IPV6
Une ressource de passerelle

Rétrograder chaque VM vers IPv4

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

Ajouter des VM à double pile IPv4 à chaque groupe d'instances

Créez des instances 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

Ajoutez les nouvelles instances aux groupes d'instances :

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

Créez un service 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

Ajoutez les groupes d'instances mis à jour au service de backend IPv4 nouvellement créé :

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

Les services de backend IPv4 et IPv6 peuvent désormais diffuser du trafic. Mettez à jour le mappage d'URL pour diriger une partie du trafic client vers le nouveau service de backend IPv4.