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 :
- 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.
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 :
Un réseau VPC avec deux sous-réseaux :
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
.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 principale10.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.
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
et8080
à partir de10.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.Instances backend. Ce schéma d'exemple illustre les déploiements de backend suivants :
- VM Compute Engine
- Backends Google Kubernetes Engine (GKE) ajoutés à des groupes de points de terminaison du réseau (NEG) autonomes
Groupes d'instances et NEG :
- Groupes d'instances gérés ou non gérés pour les déploiements de VM Compute Engine
- 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.
Une vérification d'état régionale indiquant la disponibilité de vos backends.
Un service de backend régional surveillant l'utilisation et l'état des backends.
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.
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.
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 surPRIVATE
. 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 surREGIONAL_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égionus-west1
utilise10.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égionus-west1
utilise10.129.0.0/23
pour sa plage d'adresses IP principale.
Configurer le réseau et le sous-réseau pour les backends
Console
- Accédez à la page "Réseaux VPC" dans Google Cloud Console.
Accéder à la page Réseaux VPC - Cliquez sur Créer un réseau VPC.
- Dans le champ Nom, saisissez
lb-network
. - 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
- Nom :
- Cliquez sur OK.
- Cliquez sur Créer.
gcloud
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
Créez un sous-réseau dans le réseau
lb-network
de la régionus-west1
à l'aide de la commandegcloud 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 :
- Dans Cloud Console, accédez à la page Réseaux VPC.
Accéder à la page Réseaux VPC - Cliquez sur le nom du réseau VPC partagé :
lb-network
. - Cliquez sur Ajouter un sous-réseau.
- Dans le champ Nom, saisissez
proxy-only-subnet
. - Pour la région, sélectionnez
us-west1
. - Définissez le champ Objectif sur Proxy géré régional.
- Pour la plage d'adresses IP, saisissez
10.129.0.0/23
. - 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 TCP22
à 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 cibleallow-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 (dans130.211.0.0/22
et35.191.0.0/16
). Cet exemple utilise le tag cibleload-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 ports80
,443
et8080
à partir des proxys gérés de l'équilibreur de charge HTTP(S) interne. Cet exemple utilise le tag cibleload-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
- Accédez à la page "Règles de pare-feu" de Google Cloud Console.
Accéder à la page "Règles de pare-feu" - 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.
- Nom :
- Cliquez sur Créer.
- 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
et35.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 utiliseztcp:80
pour le protocole et le port, Google Cloud peut contacter vos VM via HTTP sur le port80
, mais pas via HTTPS sur le port443
.
- Nom :
- Cliquez sur Créer.
- 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.
- Nom :
- Cliquez sur Créer.
gcloud
Créez la règle de pare-feu
fw-allow-ssh
pour autoriser la connectivité SSH aux VM avec le tag réseauallow-ssh
. Lorsque vous omettezsource-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
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
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éfinissezsource-ranges
sur les plages allouées de votre sous-réseau proxy réservé, par exemple10.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
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
- Cliquez sur Create instance template (Créer un modèle d'instance).
- Dans le champ Nom, saisissez
l7-ilb-backend-template
. - 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
. 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
Sous Mise en réseau, sélectionnez
lb-network
en tant que réseau etbackend-subnet
en tant que sous-réseau.Ajoutez les tags réseau suivants :
allow-ssh
etload-balanced-backend
.Cliquez sur Create (Créer).
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"
- Cliquez sur Créer un groupe d'instances.
- 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.
- Dans le champ Nom, saisissez
l7-ilb-backend-example
. - Pour l'emplacement, sélectionnez Zone unique.
- Pour la région, sélectionnez
us-west1
. - Pour la zone, sélectionnez
us-west1-a
. - Pour le paramètre Modèle d'instance, sélectionnez
l7-ilb-backend-template
. 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.
- Dans le champ Mode autoscaling, sélectionnez
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é.
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'
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
- Accédez à la page "Équilibrage de charge" dans Google Cloud Console.
Accéder à la page Équilibrage de charge - Dans la section Équilibrage de charge HTTP(S), cliquez sur Démarrer la configuration.
- Sous Web ou interne uniquement, sélectionnez Seulement entre les VM. Ce paramètre signifie que l'équilibreur de charge est interne.
- Cliquez sur Continuer.
Préparer l'équilibreur de charge
- Pour le nom de l'équilibreur de charge, saisissez
l7-ilb-map
. - Pour la région, sélectionnez
us-west1
. - Pour le réseau, sélectionnez
lb-network
. - 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 :
- Cliquez sur Réserver un sous-réseau.
- Dans le champ Nom, saisissez
proxy-only-subnet
. - Pour la plage d'adresses IP, saisissez
10.129.0.0/23
. - Cliquez sur Ajouter.
Configurer le service de backend
- Cliquez sur Configuration du backend.
- Dans le menu Créer ou sélectionner des services de backend, sélectionnez Créer un service backend.
- Définissez le nom du service de backend sur l7-ilb-backend-service.
- Définissez le type de backend sur groupes d'instances.
- Dans la section Nouveau backend :
- Définissez le groupe d'instances sur l7-ilb-backend-example.
- Définissez les numéros de port sur
80
. - Définissez le mode d'équilibrage sur Utilisation.
- Cliquez sur OK.
- Dans la section Vérification d'état, sélectionnez Créer une vérification d'état avec les paramètres suivants :
- Nom : l7-ilb-basic-check
- Protocole : HTTP
- Port :
80
- Cliquez sur Enregistrer et continuer.
- 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 :
- Cliquez sur Configuration du frontend.
- Cliquez sur Ajouter une adresse IP et un port frontend.
- Définissez le nom sur l7-ilb-forwarding-rule.
- Définissez le protocole sur HTTP.
- Définissez le sous-réseau sur backend-subnet.
- Sous Adresse IP interne, sélectionnez Réserver une adresse IP statique interne.
- Dans le panneau qui s'affiche, renseignez les informations suivantes :
- Nom : l7-ilb-ip
- Dans la section Adresse IP statique, sélectionnez Laissez-moi choisir.
- Dans la section Adresse IP personnalisée, saisissez
10.1.2.99
. - Cliquez sur Réserver.
- Définissez le paramètre Port sur
80
. - 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.
- Cliquez sur Configuration du frontend.
- Cliquez sur Ajouter une adresse IP et un port frontend.
- Dans le champ Nom, saisissez
l7-ilb-forwarding-rule
. - Dans le champ Protocole, sélectionnez
HTTPS (includes HTTP/2)
. - Définissez le sous-réseau sur backend-subnet.
- Sous Adresse IP interne, sélectionnez Réserver une adresse IP statique interne.
- Dans le panneau qui s'affiche, fournissez les informations suivantes :
- Nom : l7-ilb-ip
- Dans la section Adresse IP statique, sélectionnez Laissez-moi choisir.
- Dans la section Adresse IP personnalisée, saisissez
10.1.2.99
. - Cliquez sur Réserver.
- Assurez-vous que le port est défini sur la valeur
443
pour autoriser le trafic HTTPS. - Cliquez sur la liste déroulante Certificat.
- 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.
- Sinon, sélectionnez Créer un certificat.
- Pour le nom, indiquez
l7-ilb-cert
. - Dans les champs appropriés, importez vos fichiers au format PEM :
- Certificat de clé publique
- Chaîne de certificats
- Clé privée
- Cliquez sur Créer.
- Pour le nom, indiquez
- Pour ajouter des ressources de certificat en plus de la ressource de certificat SSL principale, procédez comme suit :
- Cliquez sur Ajouter un certificat.
- Sélectionnez un certificat dans la liste Certificats ou cliquez sur Créer un certificat, puis suivez les instructions ci-dessus.
- Cliquez sur OK.
Terminer la configuration
Cliquez sur Créer.
gcloud
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
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
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
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
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
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.
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 :
- Accédez à la page "Équilibrage de charge" dans Google Cloud Console.
Accéder à la page Équilibrage de charge - Cliquez sur Backends.
- Cliquez sur l7-ilb-backend-service (le nom du service de backend que vous avez créé pour cet exemple) et cliquez sur Modifier.
- Sur la page Détails du service de backend, cliquez sur Configuration avancée.
- Sous Affinité de session, sélectionnez le type d'affinité de session souhaité dans le menu.
- 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.
- Accédez à la page "Règles de pare-feu" de Google Cloud Console.
Accéder à la page "Règles de pare-feu" - 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.
- Nom :
- 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.
- Accédez à la page "Règles de pare-feu" de Google Cloud Console.
Accéder à la page "Règles de pare-feu" - 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.
- Nom :
- Cliquez sur Create (Créer).
- 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.
- Nom :
- 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.
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
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
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
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
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 :
- Utilisez l'exemple de configuration pour créer un service de backend régional
l7-ilb-backend-service
. Activez le sous-paramètre du backend en spécifiant
--subsetting-policy
en tant queCONSISTENT_HASH_SUBSETTING
. Le schéma d'équilibrage de charge estINTERNAL_MANAGED
.gcloud
Exécutez la commande
gcloud
suivante pour mettre à jourl7-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éthoderegionBackendServices/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
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.