Configurer un équilibreur de charge d'application interne régional avec des backends de groupes d'instances de VM

Ce document fournit des instructions de configuration d'un équilibreur de charge d'application interne régional pour vos services exécutés sur des VM Compute Engine.

Pour configurer l'équilibrage de charge pour vos services exécutés dans des pods Google Kubernetes Engine (GKE), consultez les sections Équilibrage de charge natif en conteneurs avec des NEG autonomes et Associer un équilibreur de charge d'application régional interne à des NEG autonomes.

Pour configurer l'équilibrage de charge pour accéder aux API et services Google à l'aide de Private Service Connect, consultez la page Configurer Private Service Connect avec des commandes de services HTTP(S) grand public.

La configuration des équilibreurs de charge d'application internes comporte deux parties :

• Effectuer des tâches préalables, comme s'assurer que les comptes requis disposent des autorisations adéquates et préparer le réseau cloud privé virtuel (VPC)
• Configurer les ressources de l'équilibreur de charge

Avant de suivre ce guide, familiarisez-vous avec les points suivants :

• Présentation de l'équilibreur de charge d'application interne, y compris la section Limites
• Présentation des règles de pare-feu VPC

Autorisations

Pour suivre ce guide, vous devez savoir comment créer des instances et modifier un réseau dans un projet. Vous devez être propriétaire ou éditeur du projet, ou disposer de tous les rôles IAM Compute Engine suivants :

Tâche	Rôle requis
Créer des réseaux, des sous-réseaux et des composants de l'équilibreur de charge	Administrateur de réseaux Compute
Ajouter et supprimer des règles de pare-feu	Administrateur de sécurité de Compute
Créer des instances	Administrateur d'instances Compute

Pour en savoir plus, consultez les guides suivants :

• Access control (Contrôle des accès)
• Conditions IAM

Vue d'ensemble de la configuration

Vous pouvez configurer un équilibreur de charge d'application interne, comme décrit dans le flux de configuration de haut niveau suivant. Les étapes numérotées font référence aux numéros du diagramme.

Composants numérotés de l'équilibreur de charge d'application interne (cliquez pour agrandir).

Comme le montre le schéma, cet exemple crée un équilibreur de charge d'application interne dans un réseau VPC dans la région us-west1, avec un service de backend et deux groupes de backend.

Le schéma montre les éléments suivants :

1. Un réseau VPC avec deux sous-réseaux :

   1. Un sous-réseau est utilisé pour les backends (groupes d'instances) et la règle de transfert. Sa plage d'adresses IP principale est 10.1.2.0/24.

   2. Un sous-réseau est un sous-réseau proxy uniquement dans la région us-west1. Vous devez créer un sous-réseau proxy réservé dans chaque région d'un réseau VPC dans laquelle vous utilisez des équilibreurs de charge d'application internes. Le sous-réseau proxy réservé de la région est partagé entre tous les équilibreurs de charge d'application internes de la région. Les adresses sources des paquets envoyés depuis l'équilibreur de charge d'application interne vers les backends de votre service sont attribuées à partir du sous-réseau proxy réservé. Dans cet exemple, le sous-réseau proxy réservé de la région possède la plage d'adresses IP principale 10.129.0.0/23, qui est la taille de sous-réseau recommandée. Pour en savoir plus, consultez la section Sous-réseaux proxy réservés.

2. Une règle de pare-feu qui autorise les flux de trafic de sous-réseau proxy réservé dans votre réseau. Cela signifie ajouter une règle qui autorise le trafic sur le port TCP 80, 443 et 8080 à partir de 10.129.0.0/23 (la plage du sous-réseau proxy réservé dans cet exemple). Une autre règle de pare-feu pour les vérifications de l'état.

3. Instances de VM Compute Engine backend

4. Groupes d'instances gérés ou non gérés pour les déploiements de VM Compute Engine.

   Dans chaque zone, vous pouvez combiner différents types de groupes de backend en fonction des exigences de votre déploiement.

   Remarque : Cette configuration vous montre comment équilibrer la charge des requêtes sur les backends de groupes d'instances de VM. Pour savoir comment équilibrer la charge des requêtes sur les pods GKE, consultez la page GKE Ingress pour l'équilibrage de charge HTTP(S).

5. Une vérification d'état régionale indiquant la disponibilité de vos backends.

6. Un service de backend régional surveillant l'utilisation et l'état des backends.

7. Un mappage d'URL régional qui analyse l'URL des requêtes et les transfère à des services de backend spécifiques en fonction de l'hôte et du chemin d'accès de l'URL de la requête.

8. Un proxy HTTP ou HTTPS régional cible qui reçoit la requête de l'utilisateur et la transfère au mappage d'URL. Pour le protocole HTTPS, configurez une ressource de certificat SSL régional. Le proxy cible utilise le certificat SSL pour déchiffrer le trafic SSL si vous configurez l'équilibrage de charge HTTPS. Le proxy cible peut transférer le trafic vers vos instances à l'aide du protocole HTTP ou HTTPS.

9. Une règle de transfert, qui possède l'adresse IP interne de votre équilibreur de charge, pour transmettre chaque requête entrante au proxy cible.

   L'adresse IP interne associée à la règle de transfert peut provenir de n'importe quel sous-réseau du même réseau et de la même région. Veuillez noter les conditions suivantes :

   • L'adresse IP peut (mais ne doit pas nécessairement) provenir du même sous-réseau que les groupes d'instances backend.
   • L'adresse IP ne doit pas provenir d'un sous-réseau proxy réservé dont l'option --purpose est définie sur REGIONAL_MANAGED_PROXY.
   • Si vous souhaitez partager l'adresse IP interne avec plusieurs règles de transfert, définissez l'option --purpose de l'adresse IP sur SHARED_LOADBALANCER_VIP.

   L'exemple de cette page définit explicitement une adresse IP interne réservée pour la règle de transfert interne de l'équilibreur de charge d'application interne régional, au lieu d'autoriser l'allocation d'une adresse IP interne éphémère. Nous vous recommandons de réserver les adresses IP pour les règles de transfert.

Configurer le réseau et les sous-réseaux

Vous avez besoin d'un réseau VPC avec deux sous-réseaux : un pour les backends de l'équilibreur de charge et l'autre pour les proxys de l'équilibreur de charge. Les équilibreurs de charge d'application internes sont régionaux. Le trafic au sein du réseau VPC est acheminé vers l'équilibreur de charge si la source du trafic se trouve dans un sous-réseau dans la même région que l'équilibreur de charge.

Cet exemple utilise le réseau VPC, la région et les sous-réseaux suivants :

• Réseau : le réseau est un réseau VPC en mode personnalisé nommé lb-network.

• Sous-réseau pour les backends : un sous-réseau nommé backend-subnet dans la région us-west1 utilise 10.1.2.0/24 pour sa plage d'adresses IP principale.

• Sous-réseau pour les proxys : un sous-réseau nommé proxy-only-subnet dans la région us-west1 utilise 10.129.0.0/23 pour sa plage d'adresses IP principale.

Pour faire la démonstration de l'accès mondial, cet exemple crée une deuxième VM cliente de test dans une région et un sous-réseau différents :

• Région : europe-west1
• Sous-réseau : europe-subnet, avec plage d'adresses IP principale 10.3.4.0/24

Remarque : Vous pouvez modifier le nom du réseau, la région et les paramètres des sous-réseaux. Toutefois, les étapes suivantes de ce guide utilisent les paramètres de réseau, de région et de sous-réseau décrits ici.

Configurer le réseau et les sous-réseaux

Console

1. Dans la console Google Cloud, accédez à la page Réseaux VPC.

   Accéder aux réseaux VPC

2. Cliquez sur Créer un réseau VPC.

3. Dans le champ Nom, saisissez lb-network.

4. Dans la section Sous-réseaux, définissez le Mode de création du sous-réseau sur Personnalisé.

5. Créez un sous-réseau pour les backends de l'équilibreur de charge. Dans la section Nouveau sous-réseau, saisissez les informations suivantes :

   • Nom : backend-subnet
   • Région : us-west1
   • Plage d'adresses IP : 10.1.2.0/24

6. Cliquez sur OK.

7. Cliquez sur Ajouter un sous-réseau.

8. Créez un sous-réseau pour faire la démonstration de l'accès mondial. Dans la section Nouveau sous-réseau, saisissez les informations suivantes :

   • Nom : europe-subnet
   • Région : europe-west1
   • Plage d'adresses IP : 10.3.4.0/24

9. Cliquez sur OK.

10. Cliquez sur Créer.

gcloud

1. Créez le réseau VPC personnalisé à l'aide de la commande gcloud compute networks create :

   gcloud compute networks create lb-network --subnet-mode=custom
   

2. Créez un sous-réseau dans le réseau lb-network de la région us-west1 à l'aide de la commande gcloud compute networks subnets create :

   gcloud compute networks subnets create backend-subnet \
       --network=lb-network \
       --range=10.1.2.0/24 \
       --region=us-west1
   

3. Créez un sous-réseau dans le réseau lb-network de la région europe-west1 à l'aide de la commande gcloud compute networks subnets create :

   gcloud compute networks subnets create europe-subnet \
       --network=lb-network \
       --range=10.3.4.0/24 \
       --region=europe-west1
   

API

Envoyez une requête POST à la méthode networks.insert. Remplacez PROJECT_ID par l'ID du projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks

{
 "routingConfig": {
   "routingMode": "REGIONAL"
 },
 "name": "lb-network",
 "autoCreateSubnetworks": false
}

Envoyez une requête POST à la méthode subnetworks.insert. Remplacez PROJECT_ID par l'ID du projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks

{
 "name": "backend-subnet",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "ipCidrRange": "10.1.2.0/24",
 "region": "projects/PROJECT_ID/regions/us-west1",
}

Envoyez une requête POST à la méthode subnetworks.insert. Remplacez PROJECT_ID par l'ID du projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/europe-west1/subnetworks

{
 "name": "europe-subnet",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "ipCidrRange": "10.3.4.0/24",
 "region": "projects/PROJECT_ID/regions/europe-west1",
}

Configurer le sous-réseau proxy réservé

Ce sous-réseau proxy réservé est utilisé par tous les équilibreurs de charge régionaux basés sur Envoy dans la région us-west1 du lb-network.

Important : N'essayez pas d'attribuer des adresses du sous-réseau proxy réservé à la règle de transfert ou aux backends de votre équilibreur de charge. Vous devez attribuer l'adresse IP de la règle de transfert et les adresses IP de l'instance backend depuis une ou plusieurs plages de sous-réseaux différentes, et non depuis celle-ci. Google Cloud réserve cette plage de sous-réseaux aux proxys gérés par Google Cloud.

Console

Si vous utilisez Google Cloud Console, vous pouvez créer le sous-réseau proxy réservé ultérieurement sur la page Équilibrage de charge.

Si vous souhaitez créer le sous-réseau proxy réservé maintenant, procédez comme suit :

1. Dans la console Google Cloud, accédez à la page Réseaux VPC.

   Accéder aux réseaux VPC

2. Cliquez sur le nom du réseau VPC partagé : lb-network.

3. Cliquez sur Ajouter un sous-réseau.

4. Dans le champ Nom, saisissez proxy-only-subnet.

5. Pour Région, sélectionnez us-west1.

6. Définissez le champ Objectif sur Proxy géré régional.

7. Dans Plage d'adresses IP, saisissez 10.129.0.0/23.

8. Cliquez sur Ajouter.

gcloud

Créez le sous-réseau proxy réservé à l'aide de la commande gcloud compute networks subnets create.

gcloud compute networks subnets create proxy-only-subnet \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=us-west1 \
  --network=lb-network \
  --range=10.129.0.0/23

API

Créez le sous-réseau proxy réservé avec la méthode subnetworks.insert, en remplaçant PROJECT_ID par votre ID de projet.

POST https://compute.googleapis.com/compute/projects/PROJECT_ID/regions/us-west1/subnetworks

{
  "name": "proxy-only-subnet",
  "ipCidrRange": "10.129.0.0/23",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "region": "projects/PROJECT_ID/regions/us-west1",
  "purpose": "REGIONAL_MANAGED_PROXY",
  "role": "ACTIVE"
}

Configurer des règles de pare-feu

Cet exemple utilise les règles de pare-feu suivantes :

• fw-allow-ssh : règle d'entrée, applicable aux instances faisant l'objet d'un équilibrage de charge, qui autorise la connectivité SSH entrante sur le port TCP 22 à partir de n'importe quelle adresse. Vous pouvez choisir une plage d'adresses IP sources plus restrictive pour cette règle. Par exemple, vous pouvez spécifier uniquement les plages d'adresses IP du système à partir duquel vous souhaitez lancer des sessions SSH. Cet exemple utilise le tag cible allow-ssh pour identifier les VM auxquelles la règle de pare-feu s'applique.

• fw-allow-health-check : règle d'entrée applicable aux instances faisant l'objet d'un équilibrage de charge, qui autorise tout le trafic TCP issu des systèmes de vérification d'état Google Cloud (dans 130.211.0.0/22 et 35.191.0.0/16). Cet exemple utilise le tag cible load-balanced-backend pour identifier les VM auxquelles la règle de pare-feu s'applique.

• fw-allow-proxies : règle d'entrée applicable aux instances faisant l'objet d'un équilibrage de charge, qui autorise le trafic TCP sur les ports 80, 443 et 8080 à partir des proxys gérés de l'équilibreur de charge d'application interne. Cet exemple utilise le tag cible load-balanced-backend pour identifier les VM auxquelles la règle de pare-feu s'applique.

Sans ces règles de pare-feu, la règle d'entrée interdite par défaut bloque le trafic entrant vers les instances backend.

Les tags cibles définissent les instances backend. Sans les tags cibles, les règles de pare-feu s'appliquent à toutes les instances backend du réseau VPC. Lorsque vous créez les VM de backend, veillez à inclure les tags cibles spécifiés, comme décrit dans la section Créer un groupe d'instances géré.

Console

1. Dans la console Google Cloud, accédez à la page Règles d'administration.

   Accéder à la page "Stratégies de pare-feu"

2. Cliquez de nouveau sur Créer une règle de pare-feu pour créer la règle autorisant les connexions SSH entrantes :

   • Nom : fw-allow-ssh
   • Réseau : lb-network
   • Sens du trafic : entrée
   • Action en cas de correspondance : autoriser
   • Cibles : Tags cibles spécifiés
   • Tags cibles : allow-ssh
   • Filtre source : Plages IPv4
   • Plages IPv4 sources : 0.0.0.0/0
   • Protocoles et ports :
     • Choisissez Protocoles et ports spécifiés.
     • Cochez la case TCP, puis saisissez 22 pour le numéro de port.

3. Cliquez sur Créer.

4. Cliquez une deuxième fois sur Créer une règle de pare-feu pour créer la règle autorisant les vérifications d'état Google Cloud :

   • Nom : fw-allow-health-check
   • Réseau : lb-network
   • Sens du trafic : entrée
   • Action en cas de correspondance : autoriser
   • Cibles : Tags cibles spécifiés
   • Tags cibles : load-balanced-backend
   • Filtre source : Plages IPv4
   • Plages IPv4 sources : 130.211.0.0/22 et 35.191.0.0/16
   • Protocoles et ports :
     • Choisissez Protocoles et ports spécifiés.
     • Cochez la case TCP, puis saisissez 80 pour le numéro de port.
       Nous vous recommandons de limiter cette règle aux seuls protocoles et ports qui correspondent à ceux utilisés par votre vérification de l'état. Si vous utilisez tcp:80 pour le protocole et le port, Google Cloud peut contacter vos VM via HTTP sur le port 80, mais pas via HTTPS sur le port 443.

5. Cliquez sur Créer.

6. Cliquez une troisième fois sur Créer une règle de pare-feu pour créer la règle autorisant les serveurs proxy de l'équilibreur de charge à se connecter aux backends :

   • Nom : fw-allow-proxies
   • Réseau : lb-network
   • Sens du trafic : entrée
   • Action en cas de correspondance : autoriser
   • Cibles : Tags cibles spécifiés
   • Tags cibles : load-balanced-backend
   • Filtre source : Plages IPv4
   • Plages IPv4 sources : 10.129.0.0/23
   • Protocoles et ports :
     • Choisissez Protocoles et ports spécifiés.
     • Cochez la case TCP, puis saisissez 80, 443, 8080 pour les numéros de port.

7. Cliquez sur Créer.

gcloud

1. Créez la règle de pare-feu fw-allow-ssh pour autoriser la connectivité SSH aux VM avec le tag réseau allow-ssh. Lorsque vous omettez source-ranges, Google Cloud interprète la règle comme désignant n'importe quelle source.

   gcloud compute firewall-rules create fw-allow-ssh \
       --network=lb-network \
       --action=allow \
       --direction=ingress \
       --target-tags=allow-ssh \
       --rules=tcp:22
   

2. Créez la règle fw-allow-health-check pour autoriser les vérifications d'état Google Cloud. Cet exemple autorise tout le trafic TCP provenant des tests de vérification d'état. Toutefois, vous pouvez configurer un ensemble de ports plus restreint en fonction de vos besoins.

   gcloud compute firewall-rules create fw-allow-health-check \
       --network=lb-network \
       --action=allow \
       --direction=ingress \
       --source-ranges=130.211.0.0/22,35.191.0.0/16 \
       --target-tags=load-balanced-backend \
       --rules=tcp
   

3. Créez la règle fw-allow-proxies pour autoriser les proxys de l'équilibreur de charge d'application interne à se connecter à vos backends. Définissez source-ranges sur les plages allouées de votre sous-réseau proxy réservé, par exemple 10.129.0.0/23.

   gcloud compute firewall-rules create fw-allow-proxies \
     --network=lb-network \
     --action=allow \
     --direction=ingress \
     --source-ranges=source-range \
     --target-tags=load-balanced-backend \
     --rules=tcp:80,tcp:443,tcp:8080
   

API

Créez la règle de pare-feu fw-allow-ssh en envoyant une requête POST à la méthode firewalls.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-allow-ssh",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "sourceRanges": [
   "0.0.0.0/0"
 ],
 "targetTags": [
   "allow-ssh"
 ],
 "allowed": [
  {
    "IPProtocol": "tcp",
    "ports": [
      "22"
    ]
  }
 ],
"direction": "INGRESS"
}

Créez la règle de pare-feu fw-allow-health-check en envoyant une requête POST à la méthode firewalls.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-allow-health-check",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "sourceRanges": [
   "130.211.0.0/22",
   "35.191.0.0/16"
 ],
 "targetTags": [
   "load-balanced-backend"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp"
   }
 ],
 "direction": "INGRESS"
}

Créez la règle de pare-feu fw-allow-proxies pour autoriser le trafic TCP dans le sous-réseau proxy pour la méthode firewalls.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-allow-proxies",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "sourceRanges": [
   "10.129.0.0/23"
 ],
 "targetTags": [
   "load-balanced-backend"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "80"
     ]
   },
 {
     "IPProtocol": "tcp",
     "ports": [
       "443"
     ]
   },
   {
     "IPProtocol": "tcp",
     "ports": [
       "8080"
     ]
   }
 ],
 "direction": "INGRESS"
}

Réserver l'adresse IP de l'équilibreur de charge

Par défaut, une adresse IP est utilisée pour chaque règle de transfert. Vous pouvez réserver une adresse IP partagée, ce qui vous permet d'utiliser la même adresse IP avec plusieurs règles de transfert. Toutefois, si vous souhaitez publier l'équilibreur de charge à l'aide de Private Service Connect, n'utilisez pas d'adresse IP partagée pour la règle de transfert.

Pour l'adresse IP de la règle de transfert, utilisez le sous-réseau backend-subnet. Si vous essayez d'utiliser le sous-réseau proxy réservé, la création de la règle de transfert échoue.

Console

Vous pouvez réserver une adresse IP interne autonome à l'aide de la console Google Cloud.

1. Accédez à la page des réseaux VPC.

   Accéder aux réseaux VPC

2. Cliquez sur le réseau utilisé pour configurer la connectivité hybride entre les environnements.
3. Cliquez sur Adresses IP internes statiques, puis sur Réserver une adresse statique.
4. Dans le champ Nom, saisissez l7-ilb-ip-address.
5. Pour le sous-réseau, sélectionnez backend-subnet.
6. Si vous souhaitez spécifier l'adresse IP à réserver, sous Adresse IP statique, sélectionnez Laissez-moi choisir, puis indiquez une adresse IP personnalisée. Sinon, le système attribue automatiquement une adresse IP dans le sous-réseau.
7. Si vous souhaitez utiliser cette adresse IP avec plusieurs règles de transfert, sous Usage, sélectionnez Partagée.
8. Cliquez sur Réserver pour terminer le processus.

gcloud

1. En utilisant gcloud CLI, exécutez la commande compute addresses create :

   gcloud compute addresses create l7-ilb-ip-address \
     --region=us-west1 \
     --subnet=backend-subnet
   

   Si vous souhaitez utiliser la même adresse IP avec plusieurs règles de transfert, spécifiez --purpose=SHARED_LOADBALANCER_VIP.

2. Utilisez la commande compute addresses describe pour afficher l'adresse IP allouée :

   gcloud compute addresses describe l7-ilb-ip-address \
     --region=us-west1
   

Créer un backend de groupe d'instances de VM géré

Cette section explique comment créer un modèle de groupe d'instances et un groupe d'instances géré. Le groupe d'instances géré fournit des instances de VM exécutant les serveurs de backend d'un exemple d'équilibreur de charge d'application interne régional. Pour votre groupe d'instances, vous pouvez définir un service HTTP et mapper un nom de port sur le port correspondant. Le service de backend de l'équilibreur de charge transfère le trafic vers les ports nommés. Le trafic des clients fait l'objet d'un équilibrage de charge par rapport aux serveurs de backend. À des fins de démonstration, les backends diffusent leurs propres noms d'hôte.

Console

1. Créez un modèle d'instance. Dans la console Google Cloud, accédez à la page Modèles d'instances.

   Accéder à la page Modèles d'instances

   1. Cliquez sur Create instance template (Créer un modèle d'instance).
   2. Dans le champ Nom, saisissez l7-ilb-backend-template.
   3. Assurez-vous que le disque de démarrage est défini sur une image Debian, telle que Debian GNU/Linux 12 (bookworm). Ces instructions utilisent des commandes uniquement disponibles dans Debian, comme apt-get.
   4. Cliquez sur Options avancées.
   5. Cliquez sur Mise en réseau et configurez les champs suivants :
      1. Pour Tags réseau, saisissez allow-ssh et load-balanced-backend.
      2. Pour Interfaces réseau, sélectionnez l'option suivante :
         • Réseau : lb-network
         • Sous-réseau : backend-subnet

   6. Cliquez sur Gestion. Saisissez le script suivant dans le champ Script de démarrage.

      #! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      vm_hostname="$(curl -H "Metadata-Flavor:Google" \
      http://metadata.google.internal/computeMetadata/v1/instance/name)"
      echo "Page served from: $vm_hostname" | \
      tee /var/www/html/index.html
      systemctl restart apache2
      

   7. Cliquez sur Créer.

2. Créez un groupe d'instances géré. Dans la console Google Cloud, accédez à la page Groupes d'instances.

   Accéder à la page "Groupes d'instances"

   1. Cliquez sur Créer un groupe d'instances.
   2. Sélectionnez Nouveau groupe d'instances géré (sans état). Pour plus d'informations, consultez la page Groupes d'instances gérés (MIG) sans état ou avec état.
   3. Dans le champ Nom, saisissez l7-ilb-backend-example.
   4. Pour Emplacement, sélectionnez Zone unique.
   5. Pour Région, sélectionnez us-west1.
   6. Pour Zone, sélectionnez us-west1-a.
   7. Pour Modèle d'instance, sélectionnez l7-ilb-backend-template.

   8. Spécifiez le nombre d'instances que vous souhaitez créer au sein du groupe.

      Pour cet exemple, spécifiez les options suivantes sous Autoscaling :

      • Dans le champ Mode autoscaling, sélectionnez Off:do not autoscale.
      • Dans le champ Nombre maximal d'instances, saisissez 2.

      Si vous le souhaitez, dans la section Autoscaling de l'interface utilisateur, vous pouvez configurer le groupe d'instances de manière à ajouter ou supprimer automatiquement des instances en fonction de l'utilisation du processeur.

   9. Cliquez sur Créer.

gcloud

Les instructions gcloud de ce guide supposent que vous utilisez Cloud Shell ou un autre environnement avec bash installé.

1. Créez un modèle d'instance de VM avec le serveur HTTP à l'aide de la commande gcloud compute instance-templates create.

   gcloud compute instance-templates create l7-ilb-backend-template \
   --region=us-west1 \
   --network=lb-network \
   --subnet=backend-subnet \
   --tags=allow-ssh,load-balanced-backend \
   --image-family=debian-12 \
   --image-project=debian-cloud \
   --metadata=startup-script='#! /bin/bash
     apt-get update
     apt-get install apache2 -y
     a2ensite default-ssl
     a2enmod ssl
     vm_hostname="$(curl -H "Metadata-Flavor:Google" \
     http://metadata.google.internal/computeMetadata/v1/instance/name)"
     echo "Page served from: $vm_hostname" | \
     tee /var/www/html/index.html
     systemctl restart apache2'
   

2. Créez un groupe d'instances géré dans la zone à l'aide de la commande gcloud compute instance-groups managed create.

   gcloud compute instance-groups managed create l7-ilb-backend-example \
       --zone=us-west1-a \
       --size=2 \
       --template=l7-ilb-backend-template
   

API

Créez le modèle d'instance avec la méthode instanceTemplates.insert, en remplaçant PROJECT_ID par votre ID de projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates
{
  "name":"l7-ilb-backend-template",
  "properties":{
     "machineType":"e2-standard-2",
     "tags":{
       "items":[
         "allow-ssh",
         "load-balanced-backend"
       ]
     },
     "metadata":{
        "kind":"compute#metadata",
        "items":[
          {
            "key":"startup-script",
            "value":"#! /bin/bash\napt-get update\napt-get install
            apache2 -y\na2ensite default-ssl\na2enmod ssl\n
            vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\"
            \\\nhttp://metadata.google.internal/computeMetadata/v1/instance/name)\"\n
            echo \"Page served from: $vm_hostname\" | \\\ntee
            /var/www/html/index.html\nsystemctl restart apache2"
          }
        ]
     },
     "networkInterfaces":[
       {
         "network":"projects/PROJECT_ID/global/networks/lb-network",
         "subnetwork":"regions/us-west1/subnetworks/backend-subnet",
         "accessConfigs":[
           {
             "type":"ONE_TO_ONE_NAT"
           }
         ]
       }
     ],
     "disks":[
       {
         "index":0,
         "boot":true,
         "initializeParams":{
           "sourceImage":"projects/debian-cloud/global/images/family/debian-12"
         },
         "autoDelete":true
       }
     ]
  }
}

Créez un groupe d'instances géré dans chaque zone à l'aide de la méthode instanceGroupManagers.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/{zone}/instanceGroupManagers
{
  "name": "l7-ilb-backend-example",
  "zone": "projects/PROJECT_ID/zones/us-west1-a",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/l7-ilb-backend-template",
  "baseInstanceName": "l7-ilb-backend-example",
  "targetSize": 2
}

Configurer l'équilibreur de charge

Cet exemple vous explique comment créer les ressources suivantes pour l'équilibreur de charge d'application interne régional :

• Vérification d'état HTTP
• Un service de backend avec un groupe d'instances géré en tant que backend
• Un mappage d'URL
  • Veillez à faire référence à un mappage d'URL régional si une région est définie pour le proxy HTTP(S) cible. Un mappage d'URL régional achemine les requêtes vers un service de backend régional en fonction des règles que vous définissez pour l'hôte et le chemin d'une URL entrante. Un mappage d'URL régional peut être référencé par une règle de proxy cible régionale de la même région uniquement.
• Un certificat SSL (pour HTTPS)
• Proxy cible
• Règle de transfert

Disponibilité du proxy

Parfois, les régions Google Cloud ne disposent pas d'une capacité de proxy suffisante pour un nouvel équilibreur de charge. Dans ce cas, la console Google Cloud fournit un message d'avertissement de disponibilité du proxy lors de la création de votre équilibreur de charge. Pour résoudre ce problème, vous pouvez effectuer l'une des opérations suivantes :

• Sélectionnez une autre région pour votre équilibreur de charge. Cette option peut être pratique si vous avez des backends dans une autre région.
• Sélectionnez un réseau VPC comportant déjà un sous-réseau proxy réservé alloué.

• Attendez que le problème de capacité soit résolu.

Console

Démarrer la configuration

1. Dans Google Cloud Console, accédez à la page Équilibrage de charge.

   Accéder à la page "Équilibrage de charge"

2. Cliquez sur Créer un équilibreur de charge.
3. Dans le champ Type d'équilibreur de charge, sélectionnez Équilibreur de charge d'application (HTTP/HTTPS), puis cliquez sur Suivant.
4. Pour Public ou interne, sélectionnez Interne, puis cliquez sur Suivant.
5. Pour Déploiement interrégional ou dans une seule région, sélectionnez Recommandé pour les charges de travail régionales, puis cliquez sur Suivant.
6. Cliquez sur Configurer.

Configuration de base

1. Pour le nom de l'équilibreur de charge, saisissez l7-ilb-map.
2. Pour Région, sélectionnez us-west1.
3. Pour Réseau, sélectionnez lb-network.

Réserver un sous-réseau proxy réservé

Remarque : Si vous avez déjà réservé un sous-réseau proxy, comme indiqué dans la configuration de préparation, le bouton Réserver un sous-réseau n'apparaît pas. Vous devez donc ignorer cette section et passer aux étapes de configuration du service de backend.

Réserver un sous-réseau proxy réservé

1. Cliquez sur Réserver un sous-réseau.
2. Dans le champ Nom, saisissez proxy-only-subnet.
3. Dans Plage d'adresses IP, saisissez 10.129.0.0/23.
4. Cliquez sur Ajouter.

Configurer le service de backend

1. Cliquez sur Configuration du backend.
2. Dans le menu Créer ou sélectionner des services de backend, sélectionnez Créer un service backend.
3. Définissez le nom du service de backend sur l7-ilb-backend-service.
4. Définissez Type de backend sur Groupe d'instances.
5. Dans la section Nouveau backend :
   1. Définissez le paramètre Groupe d'instances sur l7-ilb-backend-example.
   2. Définissez le paramètre Numéros de ports sur 80.
   3. Définissez le Mode d'équilibrage sur Utilisation.
   4. Cliquez sur OK.
6. Dans le menu déroulant Vérification d'état, cliquez sur Créer une vérification d'état avec les paramètres suivants :
   1. Nom : l7-ilb-basic-check
   2. Protocole : HTTP
   3. Port : 80
   4. Cliquez sur Enregistrer.
7. Cliquez sur Créer.

Configurez le mappage d'URL

1. Cliquez sur Règles d'hôte et de chemin d'accès.

2. Sous Mode, sélectionnez Règle d'hôte et de chemin d'accès simple.

3. Assurez-vous que l7-ilb-backend-service est le seul service de backend pour tous les hôtes et chemins sans correspondance.

Pour en savoir plus sur la gestion du trafic, consultez la page Configurer la gestion du trafic.

Configurer l'interface

Pour HTTP :

1. Cliquez sur Configuration de l'interface.
2. Définissez le nom de la règle de transfert sur l7-ilb-forwarding-rule.
3. Définissez le paramètre Protocole sur HTTP.
4. Définissez le sous-réseau sur backend-subnet.
5. Définissez le paramètre Port sur 80.
6. Dans la liste Adresse IP, sélectionnez l7-ilb-ip-address.
7. Cliquez sur OK.

Pour HTTPS :

1. Cliquez sur Configuration de l'interface.
2. Définissez le nom de la règle de transfert sur l7-ilb-forwarding-rule.
3. Définissez le paramètre Protocole sur HTTPS (includes HTTP/2).
4. Définissez le sous-réseau sur backend-subnet.
5. Assurez-vous que le port est défini sur la valeur 443 pour autoriser le trafic HTTPS.
6. Dans la liste Adresse IP, sélectionnez l7-ilb-ip-address.
7. Cliquez sur la liste déroulante Certificat.
   1. Si vous possédez déjà une ressource de certificat SSL autogérée que vous souhaitez utiliser comme certificat SSL principal, sélectionnez-la dans la liste.
   2. Sinon, sélectionnez Créer un certificat.
      1. Définissez le nom du certificat sur l7-ilb-cert.
      2. Dans les champs appropriés, importez vos fichiers au format PEM :
         • Certificat de clé publique
         • Chaîne de certificats
         • Clé privée
      3. Cliquez sur Créer.
8. Pour ajouter des ressources de certificat en plus de la ressource de certificat SSL principale, procédez comme suit :
   1. Cliquez sur Ajouter un certificat.
   2. Sélectionnez un certificat dans la liste Certificats ou cliquez sur Créer un certificat, puis suivez les instructions.

9. Sélectionnez une règle SSL dans la liste Règle SSL. Si vous souhaitez créer une règle SSL, procédez comme suit:

   1. Dans la liste Règle SSL, sélectionnez Créer une règle.
   2. Donnez un nom à la règle SSL.
   3. Sélectionnez une Version minimale de TLS. La valeur par défaut est TLS 1.0.
   4. Sélectionnez l'un des profils gérés par Google préconfigurés ou un profil personnalisé qui vous permet de sélectionner des fonctionnalités SSL individuellement. Les Fonctionnalités activées et les Fonctionnalités désactivées s'affichent.
   5. Cliquez sur Enregistrer.

   Si vous n'avez pas créé de règle SSL, une règle SSL Google Cloud par défaut est appliquée.

10. Cliquez sur OK.

Vérifier la configuration

1. Cliquez sur Vérifier et finaliser.
2. Vérifiez les paramètres de configuration de votre équilibreur de charge.
3. Facultatif : cliquez sur Code équivalent pour afficher la requête API REST qui sera utilisée pour créer l'équilibreur de charge.
4. Cliquez sur Créer.

gcloud

1. Définissez la vérification d'état HTTP à l'aide de la commande gcloud compute health-checks create http.

   gcloud compute health-checks create http l7-ilb-basic-check \
      --region=us-west1 \
      --use-serving-port
   

2. Définissez le service de backend avec la commande gcloud compute backend-services create.

   gcloud compute backend-services create l7-ilb-backend-service \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --protocol=HTTP \
     --health-checks=l7-ilb-basic-check \
     --health-checks-region=us-west1 \
     --region=us-west1
   

3. Ajoutez des backends au service de backend à l'aide de la commande gcloud compute backend-services add-backend.

   gcloud compute backend-services add-backend l7-ilb-backend-service \
     --balancing-mode=UTILIZATION \
     --instance-group=l7-ilb-backend-example \
     --instance-group-zone=us-west1-a \
     --region=us-west1
   

4. Créez le mappage d'URL à l'aide de la commande gcloud compute url-maps create.

   gcloud compute url-maps create l7-ilb-map \
     --default-service=l7-ilb-backend-service \
     --region=us-west1
   

5. Créez le proxy cible.

   Pour HTTP :

   Pour un équilibreur de charge HTTP interne, créez le proxy cible à l'aide de la commande gcloud compute target-http-proxies create.

   gcloud compute target-http-proxies create l7-ilb-proxy \
     --url-map=l7-ilb-map \
     --url-map-region=us-west1 \
     --region=us-west1
   

   Pour HTTPS :

   Vous pouvez créer des certificats Compute Engine ou via le gestionnaire de certificats. Utilisez l'une des méthodes suivantes pour créer des certificats à l'aide du gestionnaire de certificats :

   • Certificats régionaux autogérés. Pour en savoir plus sur la création et l'utilisation de certificats autogérés régionaux, consultez la page Déployer un certificat régional autogéré. Les mappages de certificats ne sont pas acceptés.

   • Certificats régionaux gérés par Google. Les mappages de certificats ne sont pas acceptés.

     Les types de certificats régionaux gérés par Google suivants sont compatibles avec le gestionnaire de certificats :

     • Certificats régionaux gérés par Google avec une autorisation DNS par projet. Pour en savoir plus, consultez la page Déployer un certificat régional géré par Google.
     • Certificats régionaux gérés par Google (privés) avec Certificate Authority Service. Pour en savoir plus, consultez la page Déployer un certificat régional géré par Google avec le service d'autorité de certification.

   Après avoir créé des certificats, associez-les directement au proxy cible.

   Attribuez vos chemins de fichiers à des noms de variables.

   export LB_CERT=path to PEM-formatted file
   

   export LB_PRIVATE_KEY=path to PEM-formatted file
   

   Créez un certificat SSL régional à l'aide de la commande gcloud compute ssl-certificates create.

   gcloud compute ssl-certificates create l7-ilb-cert \
     --certificate=$LB_CERT \
     --private-key=$LB_PRIVATE_KEY \
     --region=us-west1
   

   Utilisez le certificat SSL régional pour créer le proxy cible à l'aide de la commande gcloud compute target-https-proxies create.

   gcloud compute target-https-proxies create l7-ilb-proxy \
     --url-map=l7-ilb-map \
     --region=us-west1 \
     --ssl-certificates=l7-ilb-cert
   

   • Créez la règle de transfert.

     Pour les réseaux personnalisés, vous devez faire référence au sous-réseau dans la règle de transfert. Notez qu'il s'agit du sous-réseau de VM et non du sous-réseau proxy.

     Pour HTTP :

     Utilisez la commande gcloud compute forwarding-rules create avec les options appropriées.

     gcloud compute forwarding-rules create l7-ilb-forwarding-rule \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=lb-network \
       --subnet=backend-subnet \
       --address=l7-ilb-ip-address \
       --ports=80 \
       --region=us-west1 \
       --target-http-proxy=l7-ilb-proxy \
       --target-http-proxy-region=us-west1
     

     Pour HTTPS :

     Créez la règle de transfert à l'aide de la commande gcloud compute forwarding-rules create avec les options appropriées.

     gcloud compute forwarding-rules create l7-ilb-forwarding-rule \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=lb-network \
       --subnet=backend-subnet \
       --address=l7-ilb-ip-address \
       --ports=443 \
       --region=us-west1 \
       --target-https-proxy=l7-ilb-proxy \
       --target-https-proxy-region=us-west1
     

API

Créez la vérification de l'état en envoyant une requête POST à la méthode regionHealthChecks.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/{region}/healthChecks

{
"name": "l7-ilb-basic-check",
"type": "HTTP",
"httpHealthCheck": {
  "portSpecification": "USE_SERVING_PORT"
}
}

Créez le service de backend régional en envoyant une requête POST à la méthode regionBackendServices.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices

{
"name": "l7-ilb-backend-service",
"backends": [
  {
    "group": "projects/PROJECT_ID/zones/us-west1-a/instanceGroups/l7-ilb-backend-example",
    "balancingMode": "UTILIZATION"
  }
],
"healthChecks": [
  "projects/PROJECT_ID/regions/us-west1/healthChecks/l7-ilb-basic-check"
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}

Créez le mappage d'URL en envoyant une requête POST à la méthode regionUrlMaps.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/urlMaps

{
"name": "l7-ilb-map",
"defaultService": "projects/PROJECT_ID/regions/us-west1/backendServices/l7-ilb-backend-service"
}

Pour HTTP :

Créez le proxy HTTP cible en envoyant une requête POST à la méthode regionTargetHttpProxies.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/targetHttpProxy

{
"name": "l7-ilb-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map",
"region": "us-west1"
}

Créez la règle de transfert en envoyant une requête POST à la méthode forwardingRules.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules

{
"name": "l7-ilb-forwarding-rule",
"IPAddress": "IP_ADDRESS",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/regions/us-west1/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/us-west1/subnetworks/backend-subnet",
"network": "projects/PROJECT_ID/global/networks/lb-network",
"networkTier": "PREMIUM"
}

Pour HTTPS :

Vous pouvez créer des certificats Compute Engine ou via le gestionnaire de certificats. Utilisez l'une des méthodes suivantes pour créer des certificats à l'aide du gestionnaire de certificats :

• Certificats régionaux autogérés. Pour en savoir plus sur la création et l'utilisation de certificats autogérés régionaux, consultez la page Déployer un certificat régional autogéré. Les mappages de certificats ne sont pas acceptés.

• Certificats régionaux gérés par Google. Les mappages de certificats ne sont pas acceptés.

  Les types de certificats régionaux gérés par Google suivants sont compatibles avec le gestionnaire de certificats :

  • Certificats régionaux gérés par Google avec une autorisation DNS par projet. Pour en savoir plus, consultez la page Déployer un certificat régional géré par Google.
  • Certificats régionaux gérés par Google (privés) avec Certificate Authority Service. Pour en savoir plus, consultez la page Déployer un certificat régional géré par Google avec le service d'autorité de certification.

Après avoir créé des certificats, associez-les directement au proxy cible.

Lisez les fichiers de certificat et de clé privée, puis créez le certificat SSL. L'exemple suivant montre comment effectuer cette opération avec Python.

from pathlib import Path
from pprint import pprint
from typing import Union

from googleapiclient import discovery


def create_regional_certificate(
    project_id: str,
    region: str,
    certificate_file: Union[str, Path],
    private_key_file: Union[str, Path],
    certificate_name: str,
    description: str = "Certificate created from a code sample.",
) -> dict:
    """
    Create a regional SSL self-signed certificate within your Google Cloud project.

    Args:
        project_id: project ID or project number of the Cloud project you want to use.
        region: name of the region you want to use.
        certificate_file: path to the file with the certificate you want to create in your project.
        private_key_file: path to the private key you used to sign the certificate with.
        certificate_name: name for the certificate once it's created in your project.
        description: description of the certificate.

        Returns:
        Dictionary with information about the new regional SSL self-signed certificate.
    """
    service = discovery.build("compute", "v1")

    # Read the cert into memory
    with open(certificate_file) as f:
        _temp_cert = f.read()

    # Read the private_key into memory
    with open(private_key_file) as f:
        _temp_key = f.read()

    # Now that the certificate and private key are in memory, you can create the
    # certificate resource
    ssl_certificate_body = {
        "name": certificate_name,
        "description": description,
        "certificate": _temp_cert,
        "privateKey": _temp_key,
    }
    request = service.regionSslCertificates().insert(
        project=project_id, region=region, body=ssl_certificate_body
    )
    response = request.execute()
    pprint(response)

    return response

Créez le proxy HTTPS cible en envoyant une requête POST à la méthode regionTargetHttpsProxies.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/regionTargetHttpsProxy

{
"name": "l7-ilb-proxy",
"urlMap": "projects/PROJECT_ID/regions/us-west1/urlMaps/l7-ilb-map",
"sslCertificates": /projects/PROJECT_ID/regions/us-west1/sslCertificates/SSL_CERT_NAME
}

Créez la règle de transfert en envoyant une requête POST à la méthode forwardingRules.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules

{
"name": "l7-ilb-forwarding-rule",
"IPAddress": "IP_ADDRESS",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/regions/us-west1/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/us-west1/subnetworks/backend-subnet",
"network": "projects/PROJECT_ID/global/networks/lb-network",
"networkTier": "PREMIUM",
}

Tester l'équilibreur de charge

Pour tester l'équilibreur de charge, créez une VM cliente. Établissez ensuite une session SSH avec la VM et envoyez le trafic de la VM à l'équilibreur de charge.

Créer une instance de VM pour tester la connectivité

Console

1. Dans la console Google Cloud, accédez à la page Instances de VM.

   Accéder à la page "Instances de VM"

2. Cliquez sur Créer une instance.

3. Pour Nom, définissez l7-ilb-client-us-west1-a.

4. Définissez le champ Zone sur us-west1-a.

5. Cliquez sur Options avancées.

6. Cliquez sur Mise en réseau et configurez les champs suivants :

   1. Pour Tags réseau, saisissez allow-ssh.
   2. Pour Interfaces réseau, sélectionnez l'option suivante :
      1. Réseau : lb-network
      2. Sous-réseau : backend-subnet

7. Cliquez sur Créer.

gcloud

gcloud compute instances create l7-ilb-client-us-west1-a \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=lb-network \
    --subnet=backend-subnet \
    --zone=us-west1-a \
    --tags=allow-ssh

Envoyer du trafic vers l'équilibreur de charge

Connectez-vous à l'instance que vous venez de créer et vérifiez que les services HTTP(S) sur les backends sont accessibles via l'adresse IP de la règle de transfert de l'équilibreur de charge d'application interne régional, et que le trafic fait l'objet d'un équilibrage de charge sur les instances de backend.

Se connecter à chaque instance de client via SSH

gcloud compute ssh l7-ilb-client-us-west1-a \
    --zone=us-west1-a

Obtenir l'adresse IP de l'équilibreur de charge

Utilisez la commande gcloud compute addresses describe pour afficher l'adresse IP allouée :

gcloud compute addresses describe l7-ilb-ip-address \
    --region=us-west1

Vérifiez que l'adresse IP diffuse son nom d'hôte.

Remplacez IP_ADDRESS par l'adresse IP de l'équilibreur de charge.

curl IP_ADDRESS

Pour le test HTTPS, remplacez curl par :

curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:IP_ADDRESS:443

L'option -k indique à curl d'ignorer l'étape de validation du certificat.

Exécuter 100 requêtes et vérifier que leur charge est équilibrée

Remplacez IP_ADDRESS par l'adresse IP de l'équilibreur de charge.

Pour HTTP :

{
  RESULTS=
  for i in {1..100}
  do
      RESULTS="$RESULTS:$(curl --silent IP_ADDRESS)"
  done
  echo "***"
  echo "*** Results of load-balancing: "
  echo "***"
  echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
  echo
}

Pour HTTPS :

{
  RESULTS=
  for i in {1..100}
  do
      RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:IP_ADDRESS:443)"
  done
  echo "***"
  echo "*** Results of load-balancing: "
  echo "***"
  echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
  echo
}

Options de configuration supplémentaires

Cette section développe l'exemple de configuration et propose d'autres options de configuration. Toutes les tâches décrites ici sont facultatives. Vous pouvez les exécuter dans n'importe quel ordre.

Activer l'accès mondial

Vous pouvez activer l'accès mondial pour l'équilibreur de charge d'application interne régional et l'équilibreur de charge réseau interne proxy interne régional pour les rendre accessibles aux clients de toutes les régions. Les backends de votre exemple d'équilibreur de charge doivent toujours être situés dans une région (us-west1).

Équilibreur de charge d'application interne régional avec accès global (cliquez pour agrandir).

Vous ne pouvez pas modifier une règle de transfert régionale existante pour activer l'accès mondial. Vous devez créer une règle de transfert à cette fin et supprimer la règle de transfert précédente. En outre, une fois qu'une règle de transfert a été créée avec l'accès mondial activé, elle ne peut plus être modifiée. Pour désactiver l'accès mondial, vous devez créer une règle de transfert d'accès régional et supprimer la règle de transfert d'accès global précédente.

Pour configurer l'accès mondial, procédez aux modifications de configuration ci-dessous.

Console

Créez une règle de transfert pour l'équilibreur de charge :

1. Dans la console Google Cloud, accédez à la page Équilibrage de charge.

   Accéder à la page "Équilibrage de charge"

2. Dans la colonne Nom, cliquez sur votre équilibreur de charge.

3. Cliquez sur Configuration de l'interface.

4. Cliquez sur Ajouter une adresse IP et un port frontend.

5. Saisissez le nom et les détails du sous-réseau pour la nouvelle règle de transfert.

6. Pour Sous-réseau, sélectionnez backend-subnet.

7. Pour Adresse IP, vous pouvez sélectionner la même adresse IP qu'une règle de transfert existante, réserver une nouvelle adresse IP ou utiliser une adresse IP éphémère. Le partage d'une même adresse IP entre plusieurs règles de transfert n'est possible que si vous définissez l'option --purpose de l'adresse IP sur SHARED_LOADBALANCER_VIP, lors de la création de l'adresse IP.

8. Pour Numéro de port, saisissez 110.

9. Pour Accès mondial, sélectionnez Activer.

10. Cliquez sur OK.

11. Cliquez sur Update (Mettre à jour).

gcloud

1. Créez une règle de transfert pour l'équilibreur de charge avec l'option --allow-global-access.

   Pour HTTP :

   gcloud compute forwarding-rules create l7-ilb-forwarding-rule-global-access \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network=lb-network \
     --subnet=backend-subnet \
     --address=10.1.2.99 \
     --ports=80 \
     --region=us-west1 \
     --target-http-proxy=l7-ilb-proxy \
     --target-http-proxy-region=us-west1 \
     --allow-global-access
   

   Pour HTTPS :

   gcloud compute forwarding-rules create l7-ilb-forwarding-rule-global-access \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network=lb-network \
     --subnet=backend-subnet \
     --address=10.1.2.99 \
     --ports=443 \
     --region=us-west1 \
     --target-https-proxy=l7-ilb-proxy \
     --target-https-proxy-region=us-west1 \
     --allow-global-access
   

2. Vous pouvez utiliser la commande gcloud compute forwarding-rules describe pour déterminer si l'accès mondial est activé pour une règle de transfert. Exemple :

   gcloud compute forwarding-rules describe l7-ilb-forwarding-rule-global-access \
     --region=us-west1 \
     --format="get(name,region,allowGlobalAccess)"
   

   Lorsque l'accès mondial est activé, le mot True apparaît dans la sortie après le nom et la région de la règle de transfert.

Créer une VM cliente pour tester l'accès mondial

Console

1. Dans la console Google Cloud, accédez à la page Instances de VM.

   Accéder à la page "Instances de VM"

2. Cliquez sur Créer une instance.

3. Pour Nom, définissez europe-client-vm.

4. Définissez le champ Zone sur europe-west1-b.

5. Cliquez sur Options avancées.

6. Cliquez sur Mise en réseau et configurez les champs suivants :

   1. Pour Tags réseau, saisissez allow-ssh.
   2. Pour Interfaces réseau, sélectionnez l'option suivante :
      • Réseau : lb-network
      • Sous-réseau : europe-subnet

7. Cliquez sur Créer.

gcloud

Créez une VM cliente dans la zone europe-west1-b.

gcloud compute instances create europe-client-vm \
    --zone=europe-west1-b \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=europe-subnet

Se connecter à la VM cliente et tester la connectivité

1. Utilisez ssh pour vous connecter à l'instance cliente.

   gcloud compute ssh europe-client-vm \
       --zone=europe-west1-b
   

2. Testez les connexions à l'équilibreur de charge comme vous l'avez fait depuis le client vm-client dans la région us-west1.

   curl http://10.1.2.99
   

Activer l'affinité de session

Ces procédures vous montrent comment mettre à jour un service de backend pour l'exemple d'équilibreur de charge d'application interne régional ou l'équilibreur de charge d'application interne interrégional afin que le service de backend utilise l'affinité basée sur les cookies générés, l'affinité de champ d'en-tête ou l'affinité de cookie HTTP.

Lorsque l'affinité basée sur les cookies générés est activée, l'équilibreur de charge émet un cookie lors de la première requête. Pour chaque requête suivante présentant le même cookie, l'équilibreur de charge dirige celle-ci vers les mêmes instances de machine virtuelle (VM) ou point de terminaison de backend. Dans cet exemple, le cookie est nommé GCILB.

Lorsque l'affinité du champ d'en-tête est activée, l'équilibreur de charge achemine les requêtes vers les VM ou les points de terminaison de backend dans un groupe de points de terminaison du réseau (NEG) en fonction de la valeur de l'en-tête HTTP nommé dans l'option --custom-request-header. L'affinité du champ d'en-tête n'est valide que si la stratégie de localité d'équilibrage de charge est RING_HASH ou MAGLEV et que le hachage cohérent du service de backend spécifie le nom de l'en-tête HTTP.

Lorsque l'affinité basée sur les cookies HTTP est activée, l'équilibreur de charge achemine les requêtes vers les VM ou les points de terminaison de backend dans un NEG, en fonction d'un cookie HTTP nommé dans l'option HTTP_COOKIE avec l'option --affinity-cookie-ttl facultative. Si le client ne fournit pas le cookie dans sa requête HTTP, le proxy génère le cookie et le renvoie au client dans un en-tête Set-Cookie. L'affinité basée sur les cookies HTTP n'est valide que si la règle de localité d'équilibrage de charge est RING_HASH ou MAGLEV et que le hachage cohérent du service de backend spécifie le cookie HTTP.

Console

Pour activer ou modifier l'affinité de session pour un service de backend :

1. Dans Google Cloud Console, accédez à la page Équilibrage de charge.

   Accéder à la page "Équilibrage de charge"

2. Cliquez sur Backends.
3. Cliquez sur l7-ilb-backend-service (le nom du service de backend que vous avez créé pour cet exemple) et cliquez sur Modifier.
4. Sur la page Détails du service backend, cliquez sur Configuration avancée.
5. Sous Affinité de session, sélectionnez le type d'affinité de session souhaité.
6. Cliquez sur Mettre à jour.

gcloud

Utilisez les commandes Google Cloud CLI suivantes pour mettre à jour le service de backend vers différents types d'affinité de session :

    gcloud compute backend-services update l7-ilb-backend-service \
        --session-affinity=[GENERATED_COOKIE | HEADER_FIELD | HTTP_COOKIE | CLIENT_IP] \
        --region=us-west1
    

API

Pour définir l'affinité de session, envoyez une requête `PATCH` à la méthode backendServices/patch.

    PATCH https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/regionBackendServices/l7-ilb-backend-service
    {
      "sessionAffinity": ["GENERATED_COOKIE" | "HEADER_FIELD" | "HTTP_COOKIE" | "CLIENT_IP" ]
    }
    

Restreindre les clients autorisés à envoyer du trafic vers l'équilibreur de charge

Remarque :Cette section explique comment limiter l'accès des clients à votre équilibreur de charge d'application interne régional à l'aide de règles de pare-feu. Vous pouvez également utiliser Google Cloud Armor pour limiter l'accès des clients à votre équilibreur de charge. Pour en savoir plus, consultez la section Présentation des règles de sécurité dans la documentation Google Cloud Armor.

Vous pouvez empêcher les clients de se connecter à une adresse IP virtuelle de règle de transfert d'équilibreur de charge d'application interne en configurant des règles de pare-feu de sortie sur ces clients. Définissez ces règles de pare-feu sur des VM clientes spécifiques en fonction de comptes de service ou de tags.

Vous ne pouvez pas utiliser de règles de pare-feu pour limiter le trafic entrant à certaines adresses IP virtuelles de règle de transfert de l'équilibreur de charge d'application interne. Tout client situé sur le même réseau VPC et dans la même région que l'adresse IP virtuelle de règle de transfert peut généralement envoyer du trafic à celle-ci.

De plus, toutes les requêtes adressées aux backends proviennent de proxys qui utilisent des adresses IP comprises dans la plage de sous-réseau proxy réservé. Il est impossible de créer des règles de pare-feu qui autorisent ou interdisent le trafic entrant sur ces backends en fonction de l'adresse IP virtuelle de la règle de transfert utilisée par un client.

Voici quelques exemples d'utilisation des règles de pare-feu de sortie pour limiter le trafic à l'adresse IP virtuelle de la règle de transfert de l'équilibreur de charge.

Console

Pour identifier les VM clientes, ajoutez un tag aux VM spécifiques que vous souhaitez restreindre. Ces tags sont utilisés pour associer les règles de pare-feu aux VM clientes taguées. Ajoutez ensuite le tag au champ TARGET_TAG dans les étapes suivantes.

Pour cela, vous pouvez utiliser une seule règle de pare-feu ou plusieurs règles.

Une seule règle de pare-feu de sortie

Vous pouvez configurer une règle de pare-feu de sortie pour refuser tout le trafic sortant des VM clientes taguées à destination de l'adresse IP virtuelle d'un équilibreur de charge.

1. Dans Google Cloud Console, accédez à la page Règles de pare-feu.

   Accéder aux règles de pare-feu

2. Cliquez sur Créer une règle de pare-feu pour créer la règle permettant de refuser le trafic sortant des VM clientes taguées à destination de l'adresse IP virtuelle d'un équilibreur de charge.

   • Nom : fr-deny-access
   • Réseau : lb-network
   • Priorité : 100
   • Sens du trafic : Sortie
   • Action en cas de correspondance : Refuser
   • Cibles : Tags cibles spécifiés
   • Tags cibles : TARGET_TAG
   • Filtre de destination : Plages d'adresses IP
   • Plages d'adresses IP de destination : 10.1.2.99
   • Protocoles et ports :
     • Choisissez Protocoles et ports spécifiés.
     • Cochez la case tcp, puis saisissez 80 pour le numéro de port.

3. Cliquez sur Créer.

Plusieurs règles de pare-feu de sortie

Une approche plus adaptable repose sur la définition de deux règles. Une règle par défaut et à faible priorité, qui empêche tous les clients d'accéder à l'adresse IP virtuelle de l'équilibreur de charge. Une seconde règle de priorité plus élevée, qui permet à un sous-ensemble de clients tagués d'accéder à l'adresse IP virtuelle de l'équilibreur de charge. Seules les VM taguées peuvent accéder à l'adresse IP virtuelle.

1. Dans Google Cloud Console, accédez à la page Règles de pare-feu.

   Accéder aux règles de pare-feu

2. Cliquez sur Créer une règle de pare-feu pour créer la règle de faible priorité servant à refuser l'accès par défaut :

   • Nom : fr-deny-all-access-low-priority
   • Réseau : lb-network
   • Priorité : 200
   • Sens du trafic : Sortie
   • Action en cas de correspondance : Refuser
   • Cibles : Tags cibles spécifiés
   • Tags cibles : TARGET_TAG
   • Filtre de destination : Plages d'adresses IP
   • Plages d'adresses IP de destination : 10.1.2.99
   • Protocoles et ports :
     • Choisissez Protocoles et ports spécifiés.
     • Cochez la case TCP, puis saisissez 80 pour le numéro de port.

3. Cliquez sur Créer.

4. Cliquez sur Créer une règle de pare-feu pour créer la règle de priorité supérieure servant à autoriser le trafic en provenance de certaines instances taguées.

   • Nom : fr-allow-some-access-high-priority
   • Réseau : lb-network
   • Priorité : 100
   • Sens du trafic : Sortie
   • Action en cas de correspondance : autoriser
   • Cibles : Tags cibles spécifiés
   • Tags cibles : TARGET_TAG
   • Filtre de destination : Plages d'adresses IP
   • Plages d'adresses IP de destination : 10.1.2.99
   • Protocoles et ports :
     • Choisissez Protocoles et ports spécifiés.
     • Cochez la case TCP, puis saisissez 80 pour le numéro de port.

5. Cliquez sur Créer.

gcloud

Pour identifier les VM clientes, ajoutez un tag aux VM spécifiques que vous souhaitez restreindre. Ensuite, ajoutez le tag au champ TARGET_TAG dans les étapes requises.

Pour cela, vous pouvez utiliser une seule règle de pare-feu ou plusieurs règles.

Une seule règle de pare-feu de sortie

Vous pouvez configurer une règle de pare-feu de sortie pour refuser tout le trafic sortant des VM clientes taguées à destination de l'adresse IP virtuelle d'un équilibreur de charge.

gcloud compute firewall-rules create fr-deny-access \
  --network=lb-network \
  --action=deny \
  --direction=egress \
  --rules=tcp \
  --priority=100 \
  --destination-ranges=10.1.2.99 \
  --target-tags=TARGET_TAG

Plusieurs règles de pare-feu de sortie

Une approche plus évolutive consiste à définir deux règles : une règle par défaut et à faible priorité qui empêche tous les clients d'accéder à l'adresse IP virtuelle de l'équilibreur de charge, et une seconde règle de priorité plus élevée qui permet à un sous-ensemble de clients tagués d'accéder à l'adresse IP virtuelle de l'équilibreur de charge. Seules les VM taguées peuvent accéder à l'adresse IP virtuelle.

1. Créez la règle de faible priorité :

   gcloud compute firewall-rules create fr-deny-all-access-low-priority \
     --network=lb-network \
     --action=deny \
     --direction=egress \
     --rules=tcp \
     --priority=200 \
     --destination-ranges=10.1.2.99
   

2. Créez la règle de priorité supérieure :

   gcloud compute firewall-rules create fr-allow-some-access-high-priority \
     --network=lb-network \
     --action=allow \
     --direction=egress \
     --rules=tcp \
     --priority=100 \
     --destination-ranges=10.1.2.99 \
     --target-tags=TARGET_TAG
   

Pour contrôler l'accès à l'aide de comptes de service au lieu de tags, utilisez l'option --target-service-accounts au lieu de l'option --target-tags lorsque vous créez les règles de pare-feu.

Adaptez l'accès restreint aux backends d'équilibreur de charge d'application internes en fonction des sous-réseaux.

Gérer des règles de pare-feu distinctes ou ajouter aux règles existantes de nouvelles adresses IP à équilibrage de charge, comme décrit dans la section précédente, devient peu pratique à mesure que le nombre de règles de transfert augmente. Un moyen d'éviter cela consiste à allouer des adresses IP de règle de transfert à partir d'un sous-réseau réservé. Le trafic provenant d'instances ou de comptes de service avec tag peut être autorisé ou bloqué en utilisant le sous-réseau réservé comme plage de destination pour les règles de pare-feu. Cela vous permet de contrôler efficacement l'accès à un groupe d'adresses IP virtuelles de règles de transfert sans avoir à maintenir des règles de sortie de pare-feu par adresse IP virtuelle.

Voici les principales étapes à suivre pour configurer cela, en supposant que vous créez séparément toutes les autres ressources d'équilibreur de charge requises.

gcloud

1. Créez un sous-réseau régional qui servira à allouer des adresses IP à équilibrage de charge pour les règles de transfert :

   gcloud compute networks subnets create l7-ilb-restricted-subnet \
     --network=lb-network \
     --region=us-west1 \
     --range=10.127.0.0/24
   

2. Créez une règle de transfert qui utilise une adresse provenant du sous-réseau. L'exemple suivant utilise l'adresse 10.127.0.1 du sous-réseau créé à l'étape précédente.

   gcloud compute forwarding-rules create l7-ilb-forwarding-rule-restricted \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network=lb-network \
     --subnet=l7-ilb-restricted-subnet \
     --address=10.127.0.1 \
     --ports=80 \
     --region=us-west1 \
     --target-http-proxy=l7-ilb-proxy \
     --target-http-proxy-region=us-west1
   

3. Créez une règle de pare-feu pour limiter le trafic destiné aux adresses IP des plages du sous-réseau de la règle de transfert (l7-ilb-restricted-subnet) :

   gcloud compute firewall-rules create restrict-traffic-to-subnet \
     --network=lb-network \
     --action=deny \
     --direction=egress \
     --rules=tcp:80 \
     --priority=100 \
     --destination-ranges=10.127.0.0/24 \
     --target-tags=TARGET_TAG
   

Configurer le sous-paramètre de backend

Preview

Ce produit ou cette fonctionnalité est soumis aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent bénéficier d'une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Le sous-paramètre de backend améliore les performances et l'évolutivité en attribuant un sous-ensemble de backends à chacune des instances de proxy. Lorsque cette option est activée dans un service de backend, elle ajuste le nombre de backends utilisés par chaque instance de proxy comme suit :

• À mesure que le nombre d'instances de proxy associées à l'équilibreur de charge augmente, la taille du sous-ensemble diminue.

• Lorsque le nombre total de backends dans un réseau dépasse la capacité d'une instance de proxy, la taille du sous-ensemble est automatiquement réduite pour chaque service sur lequel le sous-paramètre de backend est activé.

Remarque :Dans l'API REST, le paramètre subsetting.subsetSize n'est disponible que pour Cloud Service Mesh. Ce paramètre n'est pas disponible pour les équilibreurs de charge d'application internes régionaux.

Cet exemple présente comment créer les ressources de l'équilibreur de charge d'application interne régional et activer le sous-paramètre de backend :

1. Utilisez l'exemple de configuration pour créer un service de backend régional l7-ilb-backend-service.

2. Activez le sous-paramètre du backend en spécifiant l'option --subsetting-policy sur CONSISTENT_HASH_SUBSETTING. Définissez le schéma d'équilibrage de charge sur INTERNAL_MANAGED.

   gcloud

   Exécutez la commande gcloud suivante pour mettre à jour l7-ilb-backend-service avec le sous-paramètre de backend :

   gcloud beta compute backend-services update l7-ilb-backend-service \
      --region=us-west1 \
      --subsetting-policy=CONSISTENT_HASH_SUBSETTING
   

   API

   Envoyez une requête PATCH à la méthode regionBackendServices/patch.

   PATCH https://compute.googleapis.com/compute/beta/projects/PROJECT_ID/regions/us-west1/backendServices/l7-ilb-backend-service
   
   {
    "subsetting":
   {
    "policy": CONSISTENT_HASH_SUBSETTING
   }
   }
   

Vous pouvez également affiner l'équilibrage de charge du backend en définissant la règle localityLbPolicy. Pour en savoir plus, consultez la section Règles de trafic.

Utiliser la même adresse IP entre plusieurs règles de transfert internes

Pour que plusieurs règles de transfert internes partagent la même adresse IP interne, vous devez réserver l'adresse IP et définir son option --purpose sur SHARED_LOADBALANCER_VIP.

gcloud

gcloud compute addresses create SHARED_IP_ADDRESS_NAME \
    --region=REGION \
    --subnet=SUBNET_NAME \
    --purpose=SHARED_LOADBALANCER_VIP

Si vous devez rediriger le trafic HTTP vers HTTPS, vous pouvez créer deux règles de transfert avec une adresse IP commune. Pour en savoir plus, consultez la page Configurer la redirection HTTP vers HTTPS pour les équilibreurs de charge d'application internes.

Mettre à jour le délai d'expiration du message keepalive HTTP client

L'équilibreur de charge créé lors des étapes précédentes a été configuré avec une valeur par défaut pour le délai d'expiration du message keepalive HTTP du client.

Pour mettre à jour le délai d'expiration du message HTTP du client, suivez les instructions ci-dessous.

Console

1. Dans la console Google Cloud, accédez à la page Équilibrage de charge.

   Accédez à la page "Équilibrage de charge".

2. Cliquez sur le nom de l'équilibreur de charge que vous souhaitez modifier.
3. Cliquez sur Modifier ().
4. Cliquez sur Configuration de l'interface.
5. Développez Fonctionnalités avancées. Dans le champ Délai avant expiration du message keepalive HTTP, saisissez une valeur de délai avant expiration.
6. Cliquez sur Mettre à jour.
7. Pour vérifier vos modifications, cliquez sur Vérification et finalisation, puis sur Mettre à jour.

gcloud

Pour un équilibreur de charge HTTP, mettez à jour le proxy HTTP cible à l'aide de la commande gcloud compute target-http-proxies update.

      gcloud compute target-http-proxies update TARGET_HTTP_PROXY_NAME \
         --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
         --region=REGION
      

Pour un équilibreur de charge HTTPS, mettez à jour le proxy HTTPS cible à l'aide de la commande gcloud compute target-https-proxies update.

      gcloud compute target-https-proxies update TARGET_HTTP_PROXY_NAME \
         --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
         --region REGION
      

Remplacez les éléments suivants :

• TARGET_HTTP_PROXY_NAME: nom du proxy HTTP cible.
• TARGET_HTTPS_PROXY_NAME : nom du proxy HTTPS cible.
• HTTP_KEEP_ALIVE_TIMEOUT_SEC: valeur du délai avant expiration du message keepalive HTTP comprise entre 5 et 600 secondes.

Étape suivante

• Convertir l'équilibreur de charge d'application en IPv6
• Présentation de l'équilibreur de charge d'application interne régional
• Sous-réseaux proxy réservés aux équilibreurs de charge basés sur Envoy
• Utiliser des certificats SSL autogérés
• Nettoyez la configuration de l'équilibreur de charge.