Ce document présente les concepts que vous devez maîtriser pour configurer un équilibreur de charge réseau proxy externe Google Cloud .
L'équilibreur de charge réseau proxy externe est un équilibreur de charge de proxy inverse qui distribue le trafic TCP provenant d'Internet aux instances de machines virtuelles (VM) de votre réseau cloud privé virtuel (VPC)Google Cloud . Lorsque vous utilisez un équilibreur de charge réseau proxy externe, le trafic TCPentrant est interrompu au niveau de l'équilibreur de charge. Une nouvelle connexion transfère ensuite le trafic vers le backend disponible le plus proche.
Les équilibreurs de charge réseau proxy externes vous permettent d'utiliser une adresse IP unique pour vos utilisateurs du monde entier. L'équilibreur de charge achemine automatiquement le trafic vers les backends les plus proches de l'utilisateur.
Cet équilibreur de charge est disponible en mode régional et est appelé ci-après "équilibreur de charge réseau proxy externe régional". L'équilibreur de charge est mis en œuvre en tant que service géré basé sur le proxy Envoy Open Source. Le mode régional garantit que tous les clients et backends se trouvent dans une région spécifiée. Utilisez cet équilibreur de charge si vous souhaitez diffuser du contenu à partir d'une seule géolocalisation (par exemple, pour respecter les réglementations de conformité).
Architecture
Les schémas suivants montrent les composants des équilibreurs de charge réseau proxy externes.
Régional
Ce schéma montre les composants d'un déploiement d'équilibreur de charge réseau proxy externe régional.
Les éléments présentés ci-dessous sont les composants des équilibreurs de charge réseau proxy externes.
Sous-réseau proxy réservé
Le sous-réseau proxy réservé fournit un ensemble d'adresses IP utilisées par Google pour exécuter des proxys Envoy en votre nom. Vous devez créer un sous-réseau proxy réservé dans chaque région d'un réseau VPC dans laquelle vous utilisez des équilibreurs de charge. L'option --purpose pour ce sous-réseau proxy réservé est définie sur REGIONAL_MANAGED_PROXY. Tous les équilibreurs de charge régionaux basés sur Envoy situés dans la même région et sur le même réseau VPC partagent un pool de proxys Envoy du même sous-réseau proxy réservé.
Les VM de backend ou les points de terminaison de tous les équilibreurs de charge situés dans une région et sur un réseau VPC reçoivent les connexions du sous-réseau proxy réservé.
Points à retenir :
- Les sous-réseaux proxy réservés ne sont utilisés que pour les proxys Envoy, et non pour vos backends.
- L'adresse IP de l'équilibreur de charge n'est pas située dans le sous-réseau proxy réservé. L'adresse IP de l'équilibreur de charge est définie par sa règle de transfert gérée en externe.
- Les sous-réseaux proxy réservés doivent être configurés avec un type de pile
IPV4_IPV6pour mettre fin au trafic IPv6 entrant etIPV4_ONLYouIPV4_IPV6pour mettre fin au trafic IPv4 entrant.
Règles de transfert et adresses IP
Les règles de transfert permettent d'acheminer le trafic par adresse IP, par port et par protocole, vers une configuration d'équilibrage de charge comprenant un proxy cible et un service de backend.
Spécification de l'adresse IP. Chaque règle de transfert fournit une adresse IP unique que vous pouvez utiliser dans les enregistrements DNS de votre application. Vous pouvez soit réserver une adresse IP statique que vous pouvez utiliser, soit laisser Cloud Load Balancing en attribuer une pour vous. Nous vous recommandons de réserver une adresse IP statique. Si vous ne le faites pas, vous devez mettre à jour votre enregistrement DNS avec l'adresse IP éphémère nouvellement attribuée chaque fois que vous supprimez une règle de transfert et en créez une autre.
Spécification du port. Les règles de transfert externes utilisées dans la définition de cet équilibreur de charge peuvent faire référence à un seul port de la plage 1-65535. Si vous souhaitez accepter plusieurs ports consécutifs, vous devez configurer plusieurs règles de transfert. Plusieurs règles de transfert peuvent être configurées avec la même adresse IP virtuelle et différents ports. Par conséquent, vous pouvez relayer plusieurs applications par proxy avec des ports personnalisés distincts vers la même adresse IP virtuelle du proxy TCP. Pour plus d'informations, consultez la section Spécifications de ports pour les règles de transfert.
Pour accepter plusieurs ports consécutifs, vous devez configurer plusieurs règles de transfert. Plusieurs règles de transfert peuvent être configurées avec la même adresse IP virtuelle et des ports différents. Par conséquent, vous pouvez relayer plusieurs applications par proxy avec des ports personnalisés distincts vers la même adresse IP virtuelle du proxy TCP.
Le tableau suivant présente les exigences des règles de transfert pour les équilibreurs de charge réseau proxy externes.
| Mode d'équilibreur de charge | Niveau de service réseau | Règle de transfert, adresse IP et schéma d'équilibrage de charge | Routage depuis Internet vers l'interface de l'équilibreur de charge |
|---|---|---|---|
| Équilibreur de charge réseau proxy externe régional | Niveau Premium | Règle de transfert externe régionale Schéma d'équilibrage de charge : |
Requêtes acheminées vers les proxys Envoy situés dans la même région que l'équilibreur de charge. |
Règles de transfert et réseaux VPC
Cette section décrit comment les règles de transfert utilisées par les équilibreurs de charge d'application externes sont associées aux réseaux VPC.
| Mode d'équilibreur de charge | Association de réseau VPC |
|---|---|
| Équilibreur de charge réseau proxy externe régional | Le réseau VPC de la règle de transfert est le réseau dans lequel le sous-réseau proxy réservé a été créé. Vous spécifiez le réseau lorsque vous créez la règle de transfert. Selon que vous utilisez une adresse IPv4 ou une plage d'adresses IPv6, il existe toujours un réseau VPC explicite ou implicite associé à la règle de transfert.
|
Proxys cibles
Les équilibreurs de charge réseau proxy externes mettent fin aux connexions du client et créent de nouvelles connexions vers les backends. Le proxy cible achemine ces nouvelles connexions vers le service de backend.
Par défaut, le proxy cible ne conserve pas l'adresse IP client d'origine et les informations de port. Vous pouvez conserver ces informations en activant le protocole de PROXY sur le proxy cible.
Le tableau suivant présente les exigences de proxy cible pour les équilibreurs de charge réseau proxy externes.
| Mode d'équilibreur de charge | Niveau de service réseau | Proxy cible | Référence |
|---|---|---|---|
| Équilibreur de charge réseau proxy externe régional | Niveau Premium et Standard | regionTargetTcpProxies |
Le proxy cible fait référence à un seul service de backend ou à une ou plusieurs routes TLS. |
Routes TLS
Une ressource de route TLS vous permet de définir la façon dont le trafic est acheminé vers les services de backend en fonction des noms d'hôte SNI.
Si le proxy TCP cible de l'équilibreur de charge n'est pas référencé par une route TLS, seul le service de backend par défaut est utilisé, et la valeur du nom d'hôte SNI envoyé par le client ou son absence n'est pas pertinente.
Les routes TLS ne sont disponibles que pour les équilibreurs de charge réseau proxy externes régionaux. Ils ne sont pas compatibles avec les équilibreurs de charge réseau proxy classiques ni avec les équilibreurs de charge réseau proxy externes globaux.Vous pouvez associer une configuration de route TLS au proxy cible d'un équilibreur de charge à l'aide des commandes gcloud network-services tls-routes.
Le tableau suivant présente les API de routes TLS requises par les équilibreurs de charge réseau proxy externes :
| Mode d'équilibreur de charge | Route TLS | Référence |
|---|---|---|
| Équilibreur de charge réseau proxy externe régional | Régional tlsRoutes |
Chaque route TLS peut référencer un ou plusieurs services de backend. |
Services de backend
Les services de backend dirigent le trafic entrant vers un ou plusieurs backends associés. Chaque backend est composé d'un groupe d'instances ou d'un groupe de points de terminaison du réseau, ainsi que d'informations sur la capacité de diffusion du backend. La capacité de diffusion du backend peut être basée sur l'utilisation du processeur ou sur le nombre de requêtes par seconde (RPS).
Chaque équilibreur de charge possède au moins une ressource de service de backend. Si vous utilisez des routes TLS (preview) pour configurer le routage, vous pouvez configurer plusieurs services de backend pour votre équilibreur de charge. Sans routes TLS, vous êtes limité à un seul service de backend par équilibreur de charge.
Le service de backend spécifie la vérification d'état à effectuer pour les backends disponibles.
Les modifications apportées au service de backend ne sont pas instantanées. La propagation des modifications sur les GFE peut prendre plusieurs minutes. Vous pouvez activer le drainage de connexion sur les services de backend afin de garantir à vos utilisateurs un temps d'interruption minimal. De telles interruptions peuvent se produire lorsqu'un backend est arrêté, supprimé manuellement ou supprimé par un autoscaler. Pour en savoir plus sur la manière dont vous pouvez utiliser le drainage de connexion pour minimiser les interruptions de service, consultez la page Activer le drainage de connexion.
Pour plus d'informations sur la ressource du service de backend, voir Présentation des services de backend.
Le tableau suivant spécifie les différents backends compatibles avec le service de backend des équilibreurs de charge réseau proxy externes.
| Mode d'équilibreur de charge | Backends compatibles sur un service de backend | ||||||
|---|---|---|---|---|---|---|---|
| Groupes d'instances | NEG zonaux | NEG Internet | NEG sans serveur | NEG hybrides | GKE | ||
| Équilibreur de charge réseau proxy externe régional | Points de terminaison de type GCE_VM_IP_PORT |
NEG régionaux uniquement | |||||
Backends et réseaux VPC
Pour les backends d'équilibreur de charge réseau proxy externe régional, les conditions suivantes s'appliquent :
Pour les groupes d'instances, les NEG zonaux et les NEG de connectivité hybride, tous les backends doivent se trouver dans le même projet et la même région que le service de backend. Toutefois, un équilibreur de charge peut référencer un backend qui utilise un réseau VPC différent dans le même projet que le service de backend. La connectivité entre le réseau VPC de l'équilibreur de charge et le réseau VPC du backend peut être configurée à l'aide de l'appairage de réseaux VPC, de tunnels Cloud VPN ou de rattachements de VLAN Cloud Interconnect.
Définition du réseau de backend
- Pour les NEG zonaux et les NEG hybrides, vous spécifiez explicitement le réseau VPC lorsque vous créez le NEG.
- Pour les groupes d'instances gérés, le réseau VPC est défini dans le modèle d'instance.
- Pour les groupes d'instances non gérés, le réseau VPC du groupe d'instances est défini de manière à correspondre au réseau VPC de l'interface
nic0de la première VM ajoutée au groupe d'instances.
Configuration réseau requise pour le backend
Le réseau de votre backend doit répondre à l'une des exigences réseau suivantes :
Le réseau VPC du backend doit correspondre exactement au réseau VPC de la règle de transfert.
Le réseau VPC du backend doit être connecté au réseau VPC de la règle de transfert à l'aide de l'appairage de réseaux VPC. Vous devez configurer des échanges de routes de sous-réseau pour permettre la communication entre le sous-réseau proxy réservé dans le réseau VPC de la règle de transfert et les sous-réseaux utilisés par les instances backend ou les points de terminaison.
Exigences concernant les sous-réseaux IPv6 de backend
La version IP utilisée pour la connexion d'interface est indépendante de la connexion de backend. Étant donné que le sous-réseau proxy réservé est à double pile (IPV4_IPV6), il peut communiquer avec les backends à l'aide d'IPv4 ou d'IPv6.
Si vos instances backend gèrent le trafic IPv6, le sous-réseau de backend peut être configuré avec un type de pile
IPV4_ONLYouIPV4_IPV6(double pile). Si le type de pile du sous-réseau de backend inclut IPv6, vous devez définir explicitement le type d'accès IPv6 du sous-réseau surEXTERNAL.
Pour tous les autres types de backends, tous les backends doivent être situés dans le même réseau VPC et dans la même région.
Backends et interfaces réseau
Si vous utilisez des backends de groupe d'instances, les paquets sont toujours envoyés à nic0. Si vous souhaitez envoyer des paquets à des interfaces non-nic0 (vNIC ou interfaces réseau dynamiques), utilisez plutôt des backends NEG.
Si vous utilisez des backends de NEG zonaux, les paquets sont envoyés à l'interface réseau représentée par le point de terminaison dans le NEG. Les points de terminaison du NEG doivent se trouver dans le même réseau VPC que le réseau VPC défini explicitement pour le NEG.
Protocole de communication avec les backends
Lorsque vous configurez un service de backend pour un équilibreur de charge réseau proxy externe, vous définissez le protocole utilisé par le service de backend pour communiquer avec les backends. L'équilibreur de charge n'utilise que le protocole spécifié et n'essaie pas de négocier une connexion à l'aide de l'autre protocole. Les équilibreurs de charge réseau proxy externes n'acceptent que TCP pour la communication avec les backends.
Règles de pare-feu
Les règles de pare-feu suivantes sont requises :
Pour les équilibreurs de charge réseau proxy externes régionaux, une règle de pare-feu d'entrée pour autoriser le trafic provenant du sous-réseau proxy réservé à accéder à vos backends.
Une règle de pare-feu qui autorise le trafic entrant (
allow), pour permettre au trafic provenant des plages de vérification d'état d'atteindre vos backends. Pour plus d'informations sur les vérifications d'état et découvrir pourquoi il est nécessaire d'autoriser le trafic qui en provient, consultez Plages d'adresses IP de vérification et règles de pare-feu.
Les règles de pare-feu sont mises en œuvre au niveau de l'instance de VM, et non au niveau des proxys GFE. Vous ne pouvez pas utiliser les règles de pare-feu pour empêcher le trafic d'atteindre l'équilibreur de charge.
Les ports de ces règles de pare-feu doivent être configurés comme suit :
- Autorisez le trafic vers le port de destination pour la vérification d'état de chaque service de backend.
- Pour les backends de groupe d'instances : déterminez les ports à configurer par le mappage entre le port nommé du service de backend et les numéros de port associés à ce port nommé sur chaque groupe d'instances. Les numéros de port peuvent varier entre les groupes d'instances attribués au même service de backend.
- Pour les backends de NEG zonaux
GCE_VM_IP_PORT NEG: autorisez le trafic vers les numéros de port des points de terminaison.
Adresses IP sources
Les adresses IP sources des paquets, telles qu'elles sont perçues par les backends, ne correspondent pas à l'adresse IP externe de l'équilibreur de chargeGoogle Cloud . En d'autres termes, il existe deux connexions TCP :
Pour les équilibreurs de charge réseau proxy externes régionaux :Connexion 1, du client d'origine vers l'équilibreur de charge (sous-réseau proxy réservé) :
- Adresse IP source : le client d'origine (ou l'adresse IP externe si le client est protégé par une passerelle NAT ou un proxy de transfert).
- Adresse IP de destination : adresse IP de votre équilibreur de charge.
Connexion 2, de l'équilibreur de charge (sous-réseau proxy réservé) vers la VM de backend ou le point de terminaison :
Adresse IP source : une adresse IP du sous-réseau proxy réservé partagée entre tous les équilibreurs de charge basés sur Envoy déployés dans la même région en tant qu'équilibreur de charge.
Adresse IP de destination : une adresse IP interne de la VM de backend ou du conteneur dans le réseau VPC.
Ports ouverts
Les équilibreurs de charge réseau proxy externes sont des équilibreurs de charge de type "proxy inverse". L'équilibreur de charge interrompt les connexions entrantes, puis ouvre de nouvelles connexions entre lui-même et les backends. Ces équilibreurs de charge sont mis en œuvre à l'aide de proxys Google Front End (GFE) dans le monde entier.
Les GFE offrent plusieurs ports ouverts pour les autres services Google exécutés sur la même architecture. Lorsque vous exécutez une analyse de port, d'autres ports ouverts peuvent s'afficher pour d'autres services Google s'exécutant sur des GFE.
L'exécution d'une analyse de port sur l'adresse IP d'un équilibreur de charge basé sur GFE n'est pas utile du point de vue de l'audit pour les raisons suivantes :
Une analyse de port (par exemple, avec
nmap) n'attend généralement pas de paquet de réponse ni de paquet TCP RST lors de l'exécution de la vérification TCP SYN. Les GFE n'envoient des paquets SYN-ACK en réponse aux vérifications SYN que pour les ports sur lesquels vous avez configuré une règle de transfert. Les GFE n'envoient des paquets à vos backends qu'en réponse aux paquets envoyés à l'adresse IP de votre équilibreur de charge et au port de destination configuré sur sa règle de transfert. Les paquets envoyés à une adresse IP ou à un port différents ne sont pas envoyés à vos backends.Les paquets envoyés à l'adresse IP de votre équilibreur de charge peuvent recevoir une réponse de n'importe quel GFE du parc de Google. Cependant, l'analyse d'une combinaison d'adresse IP et de port de destination d'un équilibreur de charge n'interroge qu'un seul GFE par connexion TCP. L'adresse IP de votre équilibreur de charge n'est pas attribuée à un seul appareil ou système. Par conséquent, l'analyse de l'adresse IP d'un équilibreur de charge basé sur GFE n'analyse pas tous les GFE du parc de Google.
En gardant cela à l'esprit, voici quelques moyens plus efficaces d'auditer la sécurité de vos instances backend :
Un auditeur de sécurité doit inspecter la configuration des règles de transfert pour la configuration de l'équilibreur de charge. Les règles de transfert définissent le port de destination pour lequel votre équilibreur de charge accepte les paquets et les transfère aux backends. Pour les équilibreurs de charge basés sur GFE, chaque règle de transfert externe ne peut référencer qu'un seul port TCP de destination.
Un auditeur de sécurité doit inspecter la configuration des règles de pare-feu applicable aux VM de backend. Les règles de pare-feu que vous définissez bloquent le trafic entre les GFE et les VM de backend, mais elles ne bloquent pas le trafic entrant vers les GFE. Pour connaître les bonnes pratiques, consultez la section Règles de pare-feu.
Architecture du VPC partagé
Les équilibreurs de charge réseau proxy externes régionaux sont compatibles avec les déploiements qui utilisent des réseaux VPC partagés. Les réseaux VPC partagés vous permettent de séparer clairement les responsabilités entre les administrateurs réseau et les développeurs de services. Vos équipes de développement peuvent se concentrer sur la création de services dans des projets de service, tandis que les équipes d'infrastructure réseau peuvent provisionner et administrer l'équilibrage de charge. Si vous n'êtes pas familiarisé avec le VPC partagé, consultez la présentation du VPC partagé.
| Adresse IP | Règle de transfert | Proxy cible | Composants backend |
|---|---|---|---|
| Une adresse IP externe doit être définie dans le même projet que l'équilibreur de charge. | La règle de transfert externe doit être définie dans le même projet que les instances backend (le projet de service). | Le proxy TCP cible doit être défini dans le même projet que les instances backend. |
Pour les équilibreurs de charge réseau externes proxy régionaux, les VM de backend sont généralement situées dans un projet de service. Un service de backend interne régional et une vérification d'état doivent être définis dans ce projet de service. |
Répartition du trafic
Lorsque vous ajoutez un groupe d'instances backend ou un NEG à un service de backend, vous spécifiez un mode d'équilibrage de charge, qui définit une méthode permettant de mesurer la charge du backend et la capacité cible.
Pour les équilibreurs de charge réseau proxy externes, le mode d'équilibrage peut être CONNECTION ou UTILIZATION:
- Si le mode d'équilibrage de charge est
CONNECTION, la charge est répartie en fonction du nombre total de connexions que le backend peut gérer. - Si le mode d'équilibrage de charge est
UTILIZATION, la charge est répartie en fonction de l'utilisation des instances dans un groupe d'instances. Ce mode d'équilibrage ne s'applique qu'aux backends de groupes d'instances de VM.
La répartition du trafic entre les backends est déterminée par le mode d'équilibrage de l'équilibreur de charge.
Équilibreur de charge réseau proxy externe régional
Pour les équilibreurs de charge réseau proxy externes régionaux, la répartition du trafic est basée sur le mode d'équilibrage de charge et sur la règle d'équilibrage de charge de la localité.
Le mode d'équilibrage détermine la pondération et la fraction de trafic à envoyer à chaque backend (groupe d'instances ou NEG). La règle de localité d'équilibrage de charge (LocalityLbPolicy) détermine la manière dont les backends du groupe sont équilibrés.
Lorsqu'un service de backend reçoit du trafic, il le dirige d'abord vers un backend (groupe d'instances ou NEG) en fonction de son mode d'équilibrage. Ensuite, une fois le backend sélectionné, le trafic est réparti entre les instances ou les points de terminaison de ce groupe de backend conformément à la règle de localité d'équilibrage de charge.
Pour en savoir plus, consultez les ressources suivantes :
- Modes d'équilibrage
- Règle d'équilibrage de charge de la localité (documentation de l'API sur le service de backend régional)
Routage basé sur SNI avec des routes TLS
Le routage basé sur l'indication du nom du serveur (SNI) permet à vos équilibreurs de charge réseau proxy TCP d'acheminer le trafic vers des services de backend spécifiques en fonction du nom d'hôte SNI fourni lors du handshake TLS. La SNI est une extension TLS qui permet à un client de spécifier le nom de domaine qu'il souhaite atteindre avant l'établissement du tunnel chiffré.
Le nom d'hôte SNI est transmis dans un format non chiffré dans le message ClientHello afin que l'équilibreur de charge puisse inspecter cette valeur et acheminer le trafic vers le service de backend approprié.
Vous pouvez utiliser une ressource de configuration de route TLS pour mapper des noms d'hôte SNI spécifiques à des services de backend. Lorsque le routage basé sur SNI est configuré, l'équilibreur de charge active le passthrough TLS, où le flux d'octets chiffré est transmis directement au backend sans être déchiffré par l'équilibreur de charge.
Cette fonctionnalité permet de débloquer certains cas d'utilisation clés, tels que :
- Utilisez une seule adresse IP anycast globale et un seul port pour diffuser plusieurs applications, ce qui réduit l'utilisation d'adresses IPv4.
- Prend en charge les déploiements chiffrés de bout en bout, où les certificats peuvent rester sur les backends, ce qui garantit que le trafic n'est jamais déchiffré en transit.
- Permet aux administrateurs de la plate-forme de gérer l'infrastructure de base, tandis que les propriétaires de services gèrent indépendamment leurs routes et backends spécifiques.
- Permet le routage vers des segments spécifiques pour les applications non HTTP avec état (telles que MongoDB) en fonction du SNI fourni par le client.
Répartition du trafic lorsque des routes TLS sont utilisées
Lorsque le routage basé sur SNI est configuré, le trafic est acheminé vers les services de backend comme suit :
- L'équilibreur de charge écoute l'adresse IP et le port définis dans la règle de transfert.
- Lorsqu'un client lance une connexion TLS, l'équilibreur de charge intercepte le message
ClientHelloet extrait le nom d'hôte SNI. L'extension SNI extraite est comparée aux noms d'hôte définis dans les routes TLS configurées. L'équilibreur de charge utilise la logique suivante pour déterminer quel service de backend doit recevoir le trafic :
- Si le client n'utilise pas le protocole TLS, l'équilibreur de charge ferme la connexion.
- Si le client n'envoie aucun nom d'hôte SNI dans son message
ClientHello, l'équilibreur de charge ferme la connexion. - Si le client envoie un nom d'hôte SNI qui n'est pas un nom DNS valide, l'équilibreur de charge ferme la connexion.
- Si le client envoie un nom d'hôte SNI qui ne correspond à aucun nom d'hôte SNI associé à une route TLS, l'équilibreur de charge ferme la connexion.
Dans toutes les autres situations : l'équilibreur de charge sélectionne un service de backend à l'aide du processus de correspondance suivant :
La correspondance est effectuée par le suffixe le plus long (le plus long en termes de nombre de sous-domaines). Pour illustrer la méthode de mise en correspondance, considérons une route TLS dont l'extension SNI est
*.foo.com, une autre route TLS dont l'extension SNI est*.bar.foo.comet une troisième route TLS dont l'extension SNI estbaz.bar.foo.com.- Si le nom d'hôte SNI du client est
baz.bar.foo.com, l'équilibreur de charge sélectionne un service de backend référencé par la route TLS dont le SNI estbaz.bar.foo.com. - Si le nom d'hôte SNI du client est
qux.bar.foo.com, l'équilibreur de charge sélectionne un service de backend référencé par la route TLS dont le SNI est*.bar.foo.com. - Si le nom d'hôte SNI du client est
qux.qux.foo.com, l'équilibreur de charge sélectionne un service de backend référencé par la route TLS dont le SNI est*.foo.com.
- Si le nom d'hôte SNI du client est
Une fois qu'une correspondance est trouvée, le flux d'octets chiffré est directement transmis au service de backend attribué sans mettre fin à la connexion TLS (pour le passthrough TLS).
Limites
Les limites suivantes s'appliquent lorsque vous utilisez des routes TLS pour configurer le routage basé sur SNI :
- Un proxy TCP cible peut référencer un seul service de backend ou une ou plusieurs routes TLS. Vous ne pouvez pas configurer les deux.
Les équilibreurs de charge réseau proxy ne peuvent pas détecter la coalescence des connexions HTTP, ce qui peut entraîner un routage incorrect des requêtes HTTP.
Par défaut, les navigateurs fusionnent déjà les connexions HTTP. Par exemple, lorsqu'un navigateur ouvre une connexion à
www.example.comet que le serveur présente un certificat pour*.example.comlors du handshake TLS, le navigateur réutilise cette connexion pour toutes les requêtes adressées à*.example.com, tant que le nom d'hôte correspond à la même adresse IP. Cela est conforme à la norme RFC 7540.Avec le routage basé sur SNI, une fois qu'une connexion est établie, elle est ensuite liée de manière permanente à son backend de destination. Prenons l'exemple d'un déploiement où
*.example.comest diffusé par un backend HTTPS avec un certificat TLS*.example.com, etmy.example.comest diffusé par un autre backend HTTPS. Si une connexion à*.example.comest établie en premier, les requêtes HTTP ultérieures versmy.example.comsont regroupées sur la même connexion, à l'aide du backend HTTPS*.example.com.
Affinité de session
L'affinité de session vous permet de configurer le service de backend de l'équilibreur de charge pour envoyer toutes les requêtes d'un même client au même backend, à condition que le backend soit opérationnel et dispose de la capacité requise.
Les équilibreurs de charge réseau proxy externes offrent les types d'affinité de session suivants :None
Un paramètre d'affinité de session défini sur
NONEne signifie pas qu'il n'y a pas d'affinité de session. Cela signifie qu'aucune option d'affinité de session n'est explicitement configurée.Le hachage est toujours effectué pour sélectionner un backend. Un paramètre d'affinité de session défini sur
NONEsignifie que l'équilibreur de charge utilise un hachage à cinq tuples pour sélectionner un backend. Le hachage à cinq tuples est constitué de l'adresse IP source, du port source, du protocole, de l'adresse IP de destination et du port de destination.La valeur par défaut de l'affinité de session est
NONE.Affinité basée sur les adresses IP client
L'affinité de session Adresse IP client (
CLIENT_IP) est un hachage à deux tuples créé à partir des adresses IP source et de destination du paquet. L'affinité basée sur les adresses IP client transfère toutes les requêtes provenant d'une même adresse IP client vers le même backend, à condition que ce backend dispose d'une capacité suffisante et reste opérationnel.Lorsque vous utilisez l'affinité basée sur les adresses IP client, gardez à l'esprit les points suivants :
- L'adresse IP de destination du paquet n'est identique à l'adresse IP de la règle de transfert de l'équilibreur de charge que si le paquet est envoyé directement à l'équilibreur de charge.
- L'adresse IP source du paquet peut ne pas correspondre à une adresse IP associée au client d'origine si le paquet est traité par un système NAT ou proxy intermédiaire avant d'être distribué à un équilibreur de charge Google Cloud . Lorsque de nombreux clients partagent la même adresse IP source effective, certaines VM de backend peuvent recevoir plus de connexions ou de requêtes que d'autres.
Gardez à l'esprit les éléments suivants lors de la configuration de l'affinité de session :
Ne comptez pas sur l'affinité de session pour l'authentification ou la sécurité. L'affinité de session peut se rompre chaque fois que le nombre de backends actifs et opérationnels change. Pour en savoir plus, consultez Perte d'affinité de session.
Les valeurs par défaut des options
--session-affinityet--subsetting-policysontNONE, et une seule d'entre elles peut être définie sur une valeur différente.
Perdre l'affinité de session
Toutes les options d'affinité de session nécessitent les éléments suivants :
- L'instance backend ou le point de terminaison sélectionné doit rester configuré en tant que backend. L'affinité de session peut être rompue lorsque l'un des événements suivants se produit :
- Vous supprimez l'instance sélectionnée de son groupe d'instances.
- L'autoscaling ou l'autoréparation du groupe d'instances géré supprime l'instance sélectionnée de son groupe d'instances géré.
- Vous supprimez le point de terminaison sélectionné de son NEG.
- Vous supprimez du service de backend le groupe d'instances ou le NEG contenant l'instance ou le point de terminaison sélectionné.
- L'instance backend ou le point de terminaison sélectionné doit rester opérationnel. L'affinité de session peut être rompue lorsque l'instance ou le point de terminaison sélectionné échoue aux vérifications d'état.
- Pour les équilibreurs de charge réseau proxy externes globaux et les équilibreurs de charge réseau proxy classiques, l'affinité de session peut être interrompue si un autre Google Front End (GFE) de première couche est utilisé pour les requêtes ou connexions ultérieures après le changement de chemin de routage. Un autre GFE de première couche peut être sélectionné si le chemin de routage d'un client sur Internet vers Google change entre les requêtes ou les connexions.
Le groupe d'instances ou le NEG contenant l'instance ou le point de terminaison sélectionné ne doit pas être plein, comme défini par sa capacité cible. (Pour les groupes d'instances gérés régionaux, le composant zonal du groupe d'instances qui contient l'instance sélectionnée ne doit pas être plein.) L'affinité de session peut être interrompue lorsque le groupe d'instances ou le NEG est plein, mais que d'autres groupes d'instances ou NEG ne le sont pas. Étant donné que la capacité peut changer de manière imprévisible lorsque vous utilisez le mode d'équilibrage
UTILIZATION, vous devez utiliser le mode d'équilibrageRATEouCONNECTIONpour minimiser les situations dans lesquelles l'affinité de session peut être interrompue.Le nombre total d'instances backend ou de points de terminaison configurés doit rester constant. Lorsqu'au moins l'un des événements suivants se produit, le nombre d'instances backend ou de points de terminaison configurés change, et l'affinité de session peut être rompue :
Ajouter des instances ou des points de terminaison :
- Vous ajoutez des instances à un groupe d'instances existant sur le service de backend.
- L'autoscaling du groupe d'instances géré ajoute des instances à un groupe d'instances géré sur le service de backend.
- Vous ajoutez des points de terminaison à un NEG existant sur le service de backend.
- Vous ajoutez des groupes d'instances ou des NEG non vides au service de backend.
Suppression d'une instance ou d'un point de terminaison, et pas seulement de l'instance ou du point de terminaison sélectionné :
- Vous supprimez une instance d'un backend de groupe d'instances.
- L'autoscaling ou l'autoréparation d'un groupe d'instances géré supprime une instance d'un backend de groupe d'instances géré.
- Vous supprimez un point de terminaison d'un backend NEG.
- Vous supprimez tout groupe d'instances backend ou NEG existant et non vide du service de backend.
Le nombre total d'instances backend ou de points de terminaison opérationnels doit rester constant. Lorsqu'au moins l'un des événements suivants se produit, le nombre d'instances backend ou de points de terminaison opérationnels change, et l'affinité de session peut être rompue :
- Une instance ou un point de terminaison réussit sa vérification de l'état, passant de l'état non opérationnel à l'état opérationnel.
- Une instance ou un point de terminaison échoue à la vérification de l'état d'état, passant de l'état "opérationnel" à l'état "non opérationnel" ou "délai avant expiration".
Basculement
Le basculement pour les équilibreurs de charge réseau proxy externes fonctionne comme suit :
- Si un backend n'est plus opérationnel, le trafic est automatiquement redirigé vers des backends opérationnels dans la même région.
- Si aucun des backends n'est opérationnel, l'équilibreur de charge abandonne le trafic.
Équilibrage de charge pour les applications GKE
Si vous créez des applications dans Google Kubernetes Engine, vous pouvez utiliser des NEG autonomes pour équilibrer la charge du trafic directement vers les conteneurs. Avec les NEG autonomes, vous devez créer l'objet Service qui crée le NEG, puis associer le NEG au service de backend afin que l'équilibreur de charge puisse se connecter aux pods.
Pour en savoir plus, consultez la section Équilibrage de charge natif en conteneurs via des NEG zonaux autonomes.
Limites
Vous ne pouvez pas créer d'équilibreur de charge réseau proxy externe régional au niveau Premium à l'aide de la consoleGoogle Cloud . Utilisez plutôt la gcloud CLI ou l'API.
Google Cloud ne garantit pas la durée de vie des connexions TCP lorsque vous utilisez des équilibreurs de charge réseau proxy externes. Les clients doivent être résilients aux pertes de connexion, qu'elles soient dues à des problèmes Internet plus généraux ou à des redémarrages réguliers des proxys gérant les connexions. Si un proxy est redémarré, le champ
proxyStatus statusdes journaux de l'équilibreur de charge réseau proxy affiche un message d'état associé.