Configurer l'équilibrage de charge HTTP(S) interne avec des backends de groupe d'instances de VM

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Ce document fournit des instructions de configuration de l'équilibrage de charge HTTP(S) interne pour les services s'exécutant sur des VM Compute Engine.

Pour configurer l'équilibrage de charge pour vos services exécutés dans des pods GKE, consultez la section Équilibrage de charge natif en conteneurs avec des NEG autonomes et la section Associer un équilibreur de charge HTTP(S) interne aux 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 de l'équilibrage de charge HTTP(S) interne se compose des deux parties suivantes :

  • 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 :

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 :

Vue d'ensemble de la configuration

Vous pouvez configurer l'équilibrage de charge HTTP(S) 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 de l'équilibrage de charge HTTP(S) interne (cliquez pour agrandir)
Composants de l'équilibrage de charge HTTP(S) interne (cliquez pour agrandir)

Comme le montre le schéma, cet exemple crée un équilibreur de charge HTTP(S) 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 groupes de points de terminaison du réseau) 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 du réseau VPC dans lequel vous utilisez des équilibreurs de charge HTTP(S) internes. Le sous-réseau proxy réservé de la région est partagé entre tous les équilibreurs de charge HTTP(S) internes de la région. Les adresses sources des paquets envoyés depuis l'équilibreur de charge HTTP(S) 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 backend. Ce schéma d'exemple illustre les déploiements de backend suivants :

    1. VM Compute Engine
    2. Backends Google Kubernetes Engine (GKE) ajoutés à des groupes de points de terminaison du réseau (NEG) autonomes

  4. Groupes d'instances et NEG :

    1. Groupes d'instances gérés ou non gérés pour les déploiements de VM Compute Engine
    2. NEG pour les déploiements GKE

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

  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.

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 HTTP(S) 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

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

Console

  1. Dans Google Cloud Console, 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 Create (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.

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 Google Cloud Console, 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 HTTP(S) 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 Google Cloud Console, accédez à la page Règles de pare-feu.

    Accéder aux règles 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 HTTP(S) 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"
}

Configurer l'équilibrage de charge HTTP(S) interne avec un service basé sur une VM

Cette section présente la configuration requise pour les services exécutés sur des VM Compute Engine. Les VM clientes se connectent à l'adresse IP et au port que vous configurez dans la règle de transfert. Lorsque vos applications clientes envoient du trafic vers cette adresse IP et ce port, leurs requêtes sont transférées vers vos VM de backend en fonction du mappage d'URL de l'équilibreur de charge HTTP(S) interne.

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, 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.

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.

Créer un groupe d'instances géré

Cette section explique comment créer un modèle 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 HTTP interne. 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 10 (Buster). 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
sudo apt-get update
sudo apt-get install apache2 -y
sudo a2ensite default-ssl
sudo a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://metadata.google.internal/computeMetadata/v1/instance/name)"
sudo echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
sudo 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 Create (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-10 \
--image-project=debian-cloud \
--metadata=startup-script='#! /bin/bash
  sudo apt-get update
  sudo apt-get install apache2 -y
  sudo a2ensite default-ssl
  sudo a2enmod ssl
  vm_hostname="$(curl -H "Metadata-Flavor:Google" \
  http://metadata.google.internal/computeMetadata/v1/instance/name)"
  sudo echo "Page served from: $vm_hostname" | \
  tee /var/www/html/index.html
  sudo 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\nsudo apt-get update\nsudo apt-get install
            apache2 -y\nsudo a2ensite default-ssl\nsudo a2enmod ssl\n
            vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\"
            \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\n
            sudo echo \"Page served from: $vm_hostname\" | \\\ntee
            /var/www/html/index.html\nsudo systemctl 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-10"
         },
         "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 HTTP(S) interne :

  • Une 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)
  • Un proxy cible
  • 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.

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

Sélectionner un type d'équilibreur de charge

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

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

  2. Dans la section Équilibrage de charge HTTP(S), cliquez sur Démarrer la configuration.

  3. Dans la section Web ou interne uniquement, sélectionnez Seulement entre les VM. Ce paramètre signifie que l'équilibreur de charge est interne.

  4. Cliquez sur Continuer.

Préparer l'équilibreur de charge

  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é

Pour l'équilibrage de charge HTTP(S) interne, réservez un sous-réseau proxy :

  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 Save (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 paramètre Sous-réseau sur backend-subnet.
  5. Définissez le paramètre Port sur 80.
  6. Dans le menu déroulant Adresse IP, sélectionnez Créer une adresse IP, puis saisissez les valeurs suivantes :
    1. Nom : l7-ilb-ip
    2. Adresse IP statique : Laissez-moi choisir
    3. Adresse IP personnalisée : 10.1.2.99
    4. Cliquez sur Réserver.
  7. Cliquez sur OK.

Pour HTTPS :

Si vous utilisez HTTPS entre le client et l'équilibreur de charge, vous devez disposer d'une ou de plusieurs ressources de certificat SSL pour configurer le proxy. Pour en savoir plus sur la création de ressources de certificat SSL, consultez la page Certificats SSL. À l'heure actuelle, les certificats gérés par Google ne sont pas compatibles avec les équilibreurs de charge HTTP(S) internes.

  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 le menu déroulant Adresse IP, sélectionnez Créer une adresse IP, puis saisissez les valeurs suivantes :
    1. Nom : l7-ilb-ip
    2. Adresse IP statique : Laissez-moi choisir
    3. Adresse IP personnalisée : 10.1.2.99
    4. Cliquez sur Réserver.
  7. Cliquez sur le menu déroulant 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 Create (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 ci-dessus.
  9. Sélectionnez une règle SSL dans la liste Règle SSL. Si vous n'avez pas créé de règles SSL, une règle SSL GCP par défaut est appliquée.
  10. Cliquez sur OK.

Vérifier la configuration

Examinez l'équilibreur de charge pour vous assurer qu'il est configuré comme vous le souhaitez, puis 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 :

    Pour en savoir plus sur la création de ressources de certificat SSL, consultez la page Certificats SSL. À l'heure actuelle, les certificats gérés par Google ne sont pas compatibles avec les équilibreurs de charge HTTP(S) internes.

    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

  6. 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=10.1.2.99 \
  --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=10.1.2.99 \
  --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": "10.1.2.99",
"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 :

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.

compute/load_balancing/create_regional_certificate.py 
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."
) -> None:
    """
    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.
    """
    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)

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": "10.1.2.99",
"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

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-10 \
    --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 HTTP(S) interne, 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

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

curl 10.1.2.99

Pour le test HTTPS, remplacez curl par :

curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99: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

Pour HTTP :

{
  RESULTS=
  for i in {1..100}
  do
      RESULTS="$RESULTS:$(curl --silent 10.1.2.99)"
  done
  echo "***"
  echo "*** Results of load-balancing to 10.1.2.99: "
  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:10.1.2.99:443)"
  done
  echo "***"
  echo "*** Results of load-balancing to 10.1.2.99: "
  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 votre équilibreur de charge afin de le rendre accessible aux clients situés dans toutes les régions. Les backends de votre exemple d'équilibreur de charge doivent toujours être situés dans une même région (us-west1).

Équilibreur de charge HTTP(S) interne avec accès mondial (cliquez pour agrandir)
Équilibreur de charge HTTP(S) interne avec accès mondial (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. En outre, une fois qu'une règle de transfert a été créée avec l'accès mondial activé, elle ne peut pas ê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

Vous ne pouvez pas utiliser la console Google Cloud pour activer l'accès mondial. Utilisez plutôt gcloud CLI ou l'API REST.

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-10 \
    --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 HTTP(S) interne 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 VM ou points de terminaison de backend. Pour les équilibreurs de charge HTTP(S) internes, ce 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 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 de backend, cliquez sur Configuration avancée.

  5. Sous Affinité de session, sélectionnez le type d'affinité de session souhaité dans le menu.

  6. Cliquez sur Mettre à jour.

gcloud

Utilisez les commandes gcloud suivantes pour mettre à jour le service de backend l7-ilb-backend-service 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 regionBackendServices/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

Vous pouvez empêcher les clients de communiquer avec l'adresse IP virtuelle de la règle de transfert d'un équilibreur de charge HTTP(S) 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 HTTP(S) 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 l'équilibreur de charge.

Console

Pour identifier les VM clientes, vous devez taguer les 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. 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.

  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 Create (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 pourront 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 Create (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 Create (Créer).

gcloud

Pour identifier les VM clientes, vous devez taguer les 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 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 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 pourront 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 simplement l'option --target-service-accounts au lieu de l'option --target-tags lorsque vous créez les règles de pare-feu.

Adapter l'accès restreint aux backends d'équilibreur de charge HTTP(S) 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 nouvellement alloué. Pour cet exemple, nous avons sélectionné 10.127.0.1 dans le 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

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é.

Cet exemple présente comment créer les ressources de l'équilibreur de charge HTTP(S) interne 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 --subsetting-policy en tant que CONSISTENT_HASH_SUBSETTING. Le schéma d'équilibrage de charge est 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 une adresse IP commune entre plusieurs règles de transfert internes

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

gcloud 

gcloud compute addresses create IP_ADDRESS_NAME \
    --region=us-west1 \
    --subnet=backend-subnet \
    --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 HTTP(S) internes.

Étape suivante