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.

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

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

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.

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.

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 Cloud Console, accédez à la page Réseaux VPC.
    Accéder à la page 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 la région, sélectionnez us-west1.
  6. Définissez le champ Objectif sur Proxy géré régional.
  7. Pour la 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 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 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 d'équilibrage 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 à ces serveurs backend. À des fins de démonstration, les backends diffusent leurs propres noms d'hôte.

Cloud Console

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

    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 9 (Stretch). Ces instructions utilisent des commandes uniquement disponibles dans Debian, comme apt-get.

    4. 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
sudo apt-get update
sudo apt-get install apache2 -y
sudo a2ensite default-ssl
sudo a2enmod ssl
sudo vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
sudo echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html

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

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

    7. Cliquez sur Create (Créer).

  2. Créez un groupe d'instances géré. Accédez à la page Groupes d'instances de Cloud Console.

    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 des informations plus détaillées, 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 l'emplacement, sélectionnez Zone unique.
    5. Pour la région, sélectionnez us-west1.
    6. Pour la zone, sélectionnez us-west1-a.
    7. Pour le paramètre 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-9 \
--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
  sudo vm_hostname="$(curl -H "Metadata-Flavor:Google" \
  http://169.254.169.254/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\nsudo
            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-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. 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. Sous 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 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é

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

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

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

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. Accédez à la page "Règles de pare-feu" de Google Cloud Console.
    Accéder à la page "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. Accédez à la page "Règles de pare-feu" de Google Cloud Console.
    Accéder à la page "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.

Étape suivante