Configurer l'équilibrage de charge HTTP(S) interne

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.

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 :

• Présentation de l'équilibrage de charge HTTP(S) 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 réseau
Ajouter et supprimer des règles de pare-feu	Administrateur de sécurité
Créer des instances	Administrateur d'instances

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 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)

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 page Sous-réseaux proxy réservés aux équilibreurs de charge HTTP(S) internes.

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) dont l'option --purpose est définie sur PRIVATE. Remarques :

   • 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 INTERNAL_HTTPS_LOAD_BALANCER.

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.

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 du réseau, de la région et du sous-réseau comme indiqué ci-dessus.

Configurer le réseau et le sous-réseau pour les backends

Console

1. Accédez à la page "Réseaux VPC" dans Google Cloud Console.
   Accéder à la page "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 Mode de création du sous-réseau sur Personnalisé.
   • 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
   • Cliquez sur OK.
5. 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
   

API

Envoyez une requête POST à la méthode networks.insert, en remplaçant PROJECT_ID par votre ID de 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, en remplaçant PROJECT_ID par votre ID de 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",
}

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

Le sous-réseau proxy réservé est destiné à tous les équilibreurs de charge HTTP(S) internes de la région us-west1.

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

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=INTERNAL_HTTPS_LOAD_BALANCER \
  --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": "INTERNAL_HTTPS_LOAD_BALANCER",
  "role": "ACTIVE"
}

Configurer les 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.

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

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

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. Accédez à la page "Règles de pare-feu" de Google Cloud Console.
   Accéder à la page "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 d'adresses IP
   • Plages d'adresses IP 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 d'adresses IP
   • Plages d'adresses IP 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 d'adresses IP
   • Plages d'adresses IP 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}/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. Le trafic des clients fait l'objet d'un équilibrage de charge par rapport à ces serveurs de backend. À des fins de démonstration, les backends diffusent leurs propres noms d'hôte.

Cloud Console

1. Accédez à la page Groupes d'instances de Cloud Console.

   Accéder à la page Groupes d'instances

2. Cliquez sur Créer un groupe d'instances.
3. Choisissez Nouveau groupe d'instances géré sur la gauche.
4. Dans le champ Nom, saisissez l7-ilb-backend-example.
5. Pour l'emplacement, sélectionnez Zone unique.
6. Pour la région, sélectionnez us-west1.
7. Pour la zone, sélectionnez us-west1-a.

8. Dans la section Modèle d'instance, sélectionnez Créer un modèle d'instance.

   1. Dans le champ Nom, saisissez l7-ilb-backend-template.
   2. Assurez-vous que le disque de démarrage est défini sur une image Debian, telle que Debian GNU/Linux 9 (Stretch). Ces instructions utilisent des commandes uniquement disponibles dans Debian, comme apt-get.

   3. Sous Gestion, sécurité, disques, mise en réseau et location unique, dans l'onglet Gestion, insérez 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://169.254.169.254/computeMetadata/v1/instance/name)"
      echo "Page served from: $vm_hostname" | \
      tee /var/www/html/index.html
      systemctl restart apache2'
      

   4. Sous Mise en réseau, sélectionnez lb-network en tant que réseau et backend-subnet en tant que sous-réseau.

   5. Ajoutez les tags réseau suivants : allow-ssh et load-balanced-backend.

   6. Cliquez sur Enregistrer et continuer.

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

   Dans cet exemple, vous pouvez sélectionner les éléments suivants dans la section Mode autoscaling :

   • Ne pas configurer l'autoscaling
   • Sous Nombre 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.

10. Cliquez sur Créer pour créer le groupe.

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-9 \
   --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://169.254.169.254/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\nvm_hostname=\"$(curl -H \"Metadata-Flavor:Google\" \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\necho \"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-9"
           },
           "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 HTTP(S) interne. Dans ce cas, Cloud Console 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.

Cloud Console

Sélectionner un type d'équilibreur de charge

1. Accédez à la page Équilibrage de charge dans Google Cloud Console.
   Accéder à la page "Équilibrage de charge"
2. Dans la section Équilibrage de charge HTTP(S), cliquez sur Démarrer la configuration.
3. 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 la région, sélectionnez us-west1.
3. Pour le réseau, sélectionnez lb-network.
4. Laissez la fenêtre ouverte pour continuer.

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.

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. Pour la 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 le type de backend sur groupes d'instances.
5. Dans la section Nouveau backend :
   1. Définissez le groupe d'instances sur l7-ilb-backend-example.
   2. Définissez les numéros de port sur 80.
   3. Définissez le mode d'équilibrage sur Utilisation.
   4. Cliquez sur OK.
6. Dans la section Vérification d'état, sélectionnez 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 et continuer.
7. Cliquez sur Créer.

Configurez le mappage d'URL

Cliquez sur Host and path rules (Règles d'hôte et de chemin d'accès). Assurez-vous que le service 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 du frontend.
2. Cliquez sur Ajouter une adresse IP et un port frontend.
3. Définissez le nom sur l7-ilb-forwarding-rule.
4. Définissez le protocole sur HTTP.
5. Définissez le sous-réseau sur backend-subnet.
6. Sous Adresse IP interne, sélectionnez Réserver une adresse IP statique interne.
7. Dans le panneau qui s'affiche, renseignez les informations suivantes :
   1. Nom : l7-ilb-ip
   2. Dans la section Adresse IP statique, sélectionnez Laissez-moi choisir.
   3. Dans la section Adresse IP personnalisée, saisissez 10.1.2.99.
   4. Cliquez sur Réserver.
8. Définissez le paramètre Port sur 80.
9. 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 du frontend.
2. Cliquez sur Ajouter une adresse IP et un port frontend.
3. Dans le champ Nom, saisissez l7-ilb-forwarding-rule.
4. Dans le champ Protocole, sélectionnez HTTPS (includes HTTP/2).
5. Définissez le sous-réseau sur backend-subnet.
6. Sous Adresse IP interne, sélectionnez Réserver une adresse IP statique interne.
7. Dans le panneau qui s'affiche, fournissez les informations suivantes :
   1. Nom : l7-ilb-ip
   2. Dans la section Adresse IP statique, sélectionnez Laissez-moi choisir.
   3. Dans la section Adresse IP personnalisée, saisissez 10.1.2.99.
   4. Cliquez sur Réserver.
8. Assurez-vous que le port est défini sur la valeur 443 pour autoriser le trafic HTTPS.
9. 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 le menu déroulant.
   2. Sinon, sélectionnez Créer un certificat.
      1. Pour le nom, indiquez 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.
10. 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.
11. Cliquez sur OK.

Terminer la configuration

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"
}

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",
}

Test

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

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

Tester 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 via SSH à chaque instance de client

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 confirmer leur équilibrage de charge

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

Cloud Console

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

1. Accédez à la page Équilibrage de charge dans Google Cloud Console.
   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" ]
}

Étape suivante

• Pour en savoir plus sur le fonctionnement de l'équilibrage de charge HTTP(S) interne, consultez la page Présentation de l'équilibrage de charge HTTP(S) interne.

• Pour gérer la ressource de sous-réseau proxy réservé requise par l'équilibrage de charge HTTP(S) interne, consultez la section Sous-réseau proxy réservé aux équilibreurs de charge HTTP(S) internes.

• Pour savoir comment mettre à jour le certificat SSL de votre équilibreur de charge HTTP(S) interne, consultez la page Utiliser des certificats SSL autogérés.

• Nettoyez la configuration de l'équilibreur de charge.