Présentation de l'équilibreur de charge d'application externe

Ce document présente les concepts que vous devez maîtriser pour configurer un équilibreur de charge d'application externe.

Un équilibreur de charge d'application externe est un équilibreur de charge de couche 7 basé sur un proxy qui vous permet d'exécuter et de faire évoluer vos services derrière une seule adresse IP externe. Un équilibreur de charge d'application externe répartit le trafic HTTP et HTTPS entre les backends hébergés sur diverses plates-formesTrusted Cloud (telles que Compute Engine, Google Kubernetes Engine (GKE) et Cloud Storage), ainsi que les backends externes connectés à Internet ou via une connectivité hybride. Pour en savoir plus, consultez la section Présentation de l'équilibreur de charge d'application : cas d'utilisation.

Modes de fonctionnement

Cet équilibreur de charge est disponible en mode régional et est désigné ci-après par le terme "équilibreur de charge d'application externe régional". L'équilibreur de charge est mis en œuvre en tant que service géré basé sur le proxy Envoy Open Source. Il comprend des fonctionnalités avancées de gestion du trafic telles que la mise en miroir du trafic, la répartition du trafic en fonction d'une pondération et les transformations d'en-tête basées sur les requêtes ou les réponses. 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 ressources suivantes sont requises pour déployer un équilibreur de charge d'application externe :

• Pour les équilibreurs de charge d'application externes régionaux, un sous-réseau proxy réservé est utilisé pour envoyer des connexions depuis l'équilibreur de charge vers les backends.

• Une règle de transfert externe spécifie une adresse IP externe, un port et un proxy HTTP(S) cible mondial. Les clients utilisent l'adresse IP et le port pour se connecter à l'équilibreur de charge.

• Un proxy HTTP(S) cible reçoit une requête du client. Le proxy HTTP(S) évalue la requête à l'aide du mappage d'URL pour prendre des décisions d'acheminement du trafic. Le proxy peut également authentifier les communications avec des certificats SSL.

  • Pour l'équilibrage de charge HTTPS, le proxy HTTPS cible prouve son identité aux clients à l'aide de certificats SSL. Un proxy HTTP(S) cible accepte un nombre limité de certificats SSL.

• Le proxy HTTP(S) exploite un mappage d'URL pour déterminer le routage en fonction d'attributs HTTP (chemin de requête, cookies ou en-têtes, par exemple). En s'appuyant sur le routage choisi, le proxy transmet les requêtes des clients à des services de backend ou des buckets backend spécifiques. Le mappage d'URL peut spécifier des actions supplémentaires, telles que l'envoi de redirections à des clients.

• Un service de backend répartit les requêtes entre les backends opérationnels.

• Une vérification d'état surveille régulièrement la disponibilité de vos backends. Cela réduit le risque que des requêtes soient envoyées à des backends ne pouvant pas les traiter.

• Règles de pare-feu pour que vos backends acceptent les vérifications d'état. Les équilibreurs de charge d'application externes régionaux nécessitent une règle de pare-feu supplémentaire pour autoriser le trafic provenant du sous-réseau proxy réservé à atteindre les backends.

Régional

Ce schéma montre les composants d'un déploiement d'équilibreur de charge d'application externe régional.

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 du réseau VPC dans lequel vous utilisez des équilibreurs de charge d'application externes régionaux. 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é. En outre :

• Les sous-réseaux proxy réservés ne sont utilisés que pour les proxys Envoy, et non pour vos backends.
• Les VM de backend ou les points de terminaison de tous les équilibreurs de charge d'application externes régionaux d'une région et d'un réseau VPC reçoivent les connexions du sous-réseau proxy réservé.
• L'adresse IP de l'équilibreur de charge d'application externe régional 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 et décrite ci-dessous.

Si vous avez déjà créé un sous-réseau proxy réservé avec --purpose=INTERNAL_HTTPS_LOAD_BALANCER, migrez l'objectif du sous-réseau vers REGIONAL_MANAGED_PROXY avant de pouvoir créer d'autres équilibreurs de charge basés sur Envoy dans la même région du réseau VPC.

Règles de transfert et adresses IP

Les règles de transfert permettent d'acheminer le trafic par adresse IP, port et protocole vers une configuration d'équilibrage de charge comprenant un proxy cible et un ou plusieurs services 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 relatifs à votre application. Aucun équilibrage de charge DNS n'est requis. Vous pouvez soit spécifier une adresse IP qui sera utilisée par le service, soit laisser Cloud Load Balancing en attribuer une.

Spécification du port Chaque règle de transfert d'un équilibreur de charge d'application peut référencer un port unique compris entre 1 et 65 535. Pour accepter plusieurs ports, vous devez configurer plusieurs règles de transfert. Vous pouvez configurer plusieurs règles de transfert pour utiliser la même adresse IP externe (VIP) et référencer le même proxy HTTP(S) cible tant que la combinaison globale de l'adresse IP, du port et du protocole sont uniques pour chaque règle de transfert. Vous pouvez ainsi utiliser un seul équilibreur de charge avec un mappage d'URL partagé en tant que proxy pour plusieurs applications.

Le type de règle de transfert, d'adresse IP et de schéma d'équilibrage de charge utilisé par les équilibreurs de charge d'application externes dépend du mode de l'équilibreur de charge et du niveau de service réseau de l'équilibreur de charge.

Pour obtenir la liste complète des protocoles compatibles avec les règles de transfert d'équilibreur de charge d'application externe dans chaque mode, consultez la page Fonctionnalités de 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.

Proxy cibles

Les proxys cibles interrompent les connexions HTTP(S) des clients. Une ou plusieurs règles de transfert dirigent le trafic vers le proxy cible, qui consulte le mappage d'URL pour déterminer comment acheminer le trafic vers les backends.

Ne vous attendez pas à ce que le proxy préserve la casse des noms dans les en-têtes de requête ou de réponse. Par exemple, un en-tête de réponse Server: Apache/1.0 peut se présenter sous la forme server: Apache/1.0 au niveau du client.

Le tableau suivant spécifie le type de proxy cible requis par les équilibreurs de charge d'application externes.

En plus des en-têtes ajoutés par le proxy cible, l'équilibreur de charge ajuste certains autres en-têtes HTTP comme suit :

• Certains en-têtes sont fusionnés. Lorsqu'il existe plusieurs instances de la même clé d'en-tête (par exemple, Via), l'équilibreur de charge combine leurs valeurs dans une même liste d'éléments séparés par des virgules correspondant à une clé d'en-tête unique. Seuls les en-têtes dont les valeurs peuvent être représentées sous la forme d'une liste d'éléments séparés par des virgules sont fusionnés. Les autres en-têtes, tels que Set-Cookie, ne sont jamais fusionnés.

En-tête d'hôte

Lorsque l'équilibreur de charge effectue la requête HTTP, il conserve l'en-tête d'hôte de la requête d'origine.

En-tête "X-Forwarded-For"

L'équilibreur de charge ajoute deux adresses IP à l'en-tête X-Forwarded-For, séparées par une seule virgule, dans l'ordre suivant :

1. Adresse IP du client qui se connecte à l'équilibreur de charge
2. Adresse IP de la règle de transfert de l'équilibreur de charge

Si la requête entrante n'inclut pas d'en-tête X-Forwarded-For, l'en-tête obtenu est le suivant :

X-Forwarded-For: <client-ip>,<load-balancer-ip>

Si la requête entrante inclut déjà un en-tête X-Forwarded-For, l'équilibreur de charge ajoute ses valeurs à l'en-tête existant :

X-Forwarded-For: <existing-value>,<client-ip>,<load-balancer-ip>

Supprimer les valeurs d'en-tête existantes à l'aide d'un en-tête de requête personnalisé

Il est possible de supprimer les valeurs d'en-tête existantes à l'aide d'en-têtes de requêtes personnalisés sur le service de backend. L'exemple suivant utilise l'indicateur --custom-request-header pour recréer l'en-tête X-Forwarded-For à l'aide des variables client_ip_address et server_ip_address. Cette configuration remplace l'en-tête X-Forwarded-For entrant par l'adresse IP du client et de l'équilibreur de charge uniquement.

--custom-request-header=x-forwarded-for:{client_ip_address},{server_ip_address}

Comment le logiciel de proxy inverse de backend peut modifier l'en-tête X-Forwarded-For

Si les backends de votre équilibreur de charge exécutent un logiciel de proxy inverse HTTP, le logiciel peut ajouter l'une des adresses IP suivantes (ou les deux) à la fin de l'en-tête X-Forwarded-For :

1. Adresse IP du GFE connecté au backend. Les adresses IP GFE se trouvent dans les plages 130.211.0.0/22 et 35.191.0.0/16.

2. L'adresse IP du système backend lui-même.

Par conséquent, un système en amont peut voir un en-tête X-Forwarded-For structuré comme suit :

<existing-value>,<client-ip>,<load-balancer-ip>,<GFE-ip>,<backend-ip>

Compatibilité avec Cloud Trace

Le traçage n'est pas compatible avec les équilibreurs de charge d'application. Les équilibreurs de charge d'application globaux et classiques ajoutent l'en-tête X-Cloud-Trace-Context s'il n'est pas présent. L'équilibreur de charge d'application externe régional n'ajoute pas cet en-tête. Si l'en-tête X-Cloud-Trace-Context est déjà présent, il passe par les équilibreurs de charge sans être modifié. Toutefois, aucune trace ni aucune étendue n'est exportée par l'équilibreur de charge.

Mappages d'URL

Les mappages d'URL définissent des correspondances de motifs pour l'acheminement de requêtes vers les services de backend adéquats en fonction de l'URL de la requête. Le mappage d'URL vous permet de répartir votre trafic en examinant les composants d'URL pour envoyer des requêtes à différents ensembles de backends. Un service par défaut est défini pour gérer toute requête qui ne correspond pas à une règle d'hôte ou à une règle de correspondance de chemin donnée.

Les mappages d'URL sont compatibles avec plusieurs fonctionnalités de gestion avancée du trafic, telles que l'orientation du trafic basée sur l'en-tête, la répartition du trafic en fonction d'une pondération et la mise en miroir des requêtes. Pour en savoir plus, consultez les ressources suivantes :

• Présentation de la gestion du trafic pour les équilibreurs de charge d'application externes régionaux

Le tableau suivant spécifie le type de mappage d'URL requis par les équilibreurs de charge d'application externes dans chaque mode.

Certificats SSL

Les équilibreurs de charge d'application externes utilisant des proxys HTTPS cibles nécessitent des clés privées et des certificats SSL dans la configuration de l'équilibreur de charge.

Les équilibreurs de charge d'application externes régionaux utilisant des proxys HTTPS cibles nécessitent des clés privées et des certificats SSL dans la configuration de l'équilibreur de charge.

Les équilibreurs de charge d'application externes régionaux sont compatibles avec les certificats SSL Compute Engine autogérés.

Règles SSL

Les règles SSL spécifient l'ensemble des fonctionnalités SSL utilisées par les équilibreurs de charge Trusted Cloud lors de la négociation SSL avec les clients.

Par défaut, l'équilibrage de charge HTTPS utilise un ensemble de fonctionnalités SSL offrant une bonne sécurité et une compatibilité étendue. Certaines applications requièrent davantage de contrôle sur les versions SSL et les algorithmes de chiffrement utilisés pour les connexions HTTPS ou SSL. Vous pouvez définir une règle SSL pour spécifier l'ensemble des fonctionnalités SSL utilisées par votre équilibreur de charge lors de la négociation SSL avec les clients. En outre, vous pouvez appliquer cette règle SSL à votre proxy HTTPS cible.

Le tableau suivant spécifie la compatibilité des règles SSL avec les équilibreurs de charge dans chaque mode.

Services de backend

Un service de backend fournit des informations de configuration à l'équilibreur de charge afin qu'il puisse diriger les requêtes vers ses backends (par exemple, des groupes d'instances Compute Engine ou des groupes de points de terminaison du réseau (NEG)). Pour en savoir plus sur les services de backend, consultez la présentation des services de backend.

Champ d'application du service de backend

Le tableau suivant indique la ressource et le champ d'application du service de backend utilisés par les équilibreurs de charge d'application externes :

Protocole de communication avec les backends

Les services de backend pour les équilibreurs de charge d'application doivent utiliser l'un des protocoles suivants pour envoyer des requêtes aux backends :

• HTTP, qui utilise HTTP/1.1 et aucun protocole TLS
• HTTPS, qui utilise HTTP/1.1 et TLS
• HTTP/2, qui utilise HTTP/2 et TLS (HTTP/2 sans chiffrement n'est pas accepté)
• H2C, qui utilise HTTP/2 sur TCP. Le protocole TLS n'est pas requis. H2C n'est pas compatible avec les équilibreurs de charge d'application classiques.

L'équilibreur de charge n'utilise que le protocole de service de backend que vous spécifiez pour communiquer avec ses backends. S'il ne parvient pas à communiquer avec les backends à l'aide du protocole de service de backend spécifié, l'équilibreur de charge ne recourt pas à un autre protocole.

Le protocole du service de backend ne doit pas nécessairement correspondre au protocole utilisé par les clients pour communiquer avec l'équilibreur de charge. Par exemple, les clients peuvent envoyer des requêtes à l'équilibreur de charge à l'aide du protocole HTTP/2, mais l'équilibreur de charge peut communiquer avec les backends à l'aide du protocole HTTP/1.1 (HTTP ou HTTPS).

Backends

Un équilibreur de charge d'application externe régional est compatible avec les types de backends suivants :

• Groupes d'instances
• NEG zonaux
• NEG Internet

Backends et réseaux VPC

Pour les backends d'équilibreur de charge d'application externes régionaux :

• Pour les groupes d'instances, les NEG zonaux et les NEG de connectivité hybride, tous les backends doivent être situés 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 autre réseau VPC 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 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 pour correspondre au réseau VPC de l'interface nic0 de la première VM ajoutée au groupe d'instances.

  Exigences du réseau de 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 à celui de la règle de transfert.

  • Le réseau VPC du backend doit être connecté à celui de la règle de transfert à l'aide de l'appairage de réseaux VPC. Vous devez configurer les é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 ou les points de terminaison de backend.

• Pour tous les autres types de backend, tous les backends doivent se trouver dans le même réseau VPC et dans la même région.

  Les équilibreurs de charge d'application externes régionaux sont également compatibles avec les environnements VPC partagés, qui vous permettent de partager des réseaux VPC et leurs ressources associées entre plusieurs projets. Si vous souhaitez que le service de backend et les backends de l'équilibreur de charge d'application externe régional se trouvent dans un projet différent de la règle de transfert, vous devez configurer l'équilibreur de charge dans un environnement VPC partagé avec référencement de services inter-projets.

Backends et interfaces réseau

Si vous utilisez des backends de groupe d'instances, les paquets sont toujours distribués à nic0. Si vous souhaitez envoyer des paquets à des interfaces non nic0 (vNIC ou interfaces réseau dynamiques), utilisez plutôt des backends de 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.

Vérifications d'état

Chaque service de backend spécifie une vérification d'état qui vérifie régulièrement que les backends sont disponibles et aptes à recevoir une connexion de l'équilibreur de charge. Cela réduit le risque que des requêtes soient envoyées à des backends ne pouvant pas les traiter. Les vérifications d'état ne vérifient pas si l'application elle-même fonctionne.

Pour les vérifications d'état, vous devez créer une règle de pare-feu autorisant le trafic entrant qui permet aux vérifications d'état d'atteindre vos instances backend. En règle générale, les vérifications d'état proviennent du mécanisme de vérification d'état centralisé de Google.

Les équilibreurs de charge d'application externes régionaux qui utilisent des backends NEG hybrides font exception à cette règle car leurs vérifications d'état proviennent du sous-réseau proxy réservé. Pour plus d'informations, consultez la présentation des NEG hybrides.

Protocole de vérification d'état

Bien que ce ne soit pas obligatoire et pas toujours possible, il est recommandé d'utiliser une vérification d'état dont le protocole correspond à celui du service de backend. Par exemple, une vérification d'état HTTP/2 permet de tester plus précisément la connectivité HTTP/2 aux backends. En revanche, les équilibreurs de charge d'application externes régionaux qui utilisent des backends NEG hybrides ne sont pas compatibles avec les vérifications d'état gRPC. Pour obtenir la liste des protocoles de vérification d'état compatibles, consultez la section Fonctionnalités d'équilibrage de charge.

Le tableau suivant spécifie le champ d'application des vérifications d'état compatibles avec les équilibreurs de charge d'application externes dans chaque mode.

Pour en savoir plus sur les vérifications d'état, consultez les pages suivantes :

• Présentation des vérifications d'état
• Créer des vérifications d'état

Règles de pare-feu

L'équilibreur de charge nécessite les règles de pare-feu suivantes :

• Pour l'équilibreur de charge d'application externe régional, une règle d'entrée autorisant le trafic provenant du sous-réseau proxy réservé vers vos backends.
• Une règle d'autorisation d'entrée pour autoriser le trafic provenant des plages de vérification de l'état. Pour plus d'informations sur les vérifications de l'é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 sur les proxys GFE. Vous ne pouvez pas utiliser les règles de pare-feu Trusted Cloud 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 GCE_VM_IP_PORT : autorisez le trafic vers les numéros de port des points de terminaison.

Assistance GKE

GKE utilise des équilibreurs de charge d'application externes de différentes manières :

• Les passerelles externes créées à l'aide du contrôleur GKE Gateway peuvent utiliser n'importe quel mode d'équilibreur de charge d'application externe. Vous contrôlez le mode de l'équilibreur de charge en choisissant une GatewayClass. Le contrôleur GKE Gateway utilise toujours des backends NEG zonaux GCE_VM_IP_PORT.

• Vous pouvez utiliser des NEG zonaux GCE_VM_IP_PORT créés et gérés par les services GKE comme backends pour n'importe quel équilibreur de charge d'application ou équilibreur de charge réseau proxy. Pour en savoir plus, consultez Équilibrage de charge natif en conteneurs via des NEG zonaux autonomes.

Architecture du VPC partagé

Les équilibreurs de charge d'application externes sont compatibles avec les réseaux qui utilisent un VPC partagé. Un VPC partagé permet à des organisations de connecter des ressources provenant de différents projets à un réseau VPC commun, afin de pouvoir communiquer entre elles de manière sécurisée et efficace à l'aide d'adresses IP internes de ce réseau. Si vous n'êtes pas familiarisé avec le VPC partagé, consultez la présentation du VPC partagé.

Il existe plusieurs façons de configurer un équilibreur de charge d'application externe dans un réseau VPC partagé. Quel que soit le type de déploiement, tous les composants de l'équilibreur de charge doivent appartenir à la même organisation.

Bien que vous puissiez créer tous les composants et les backends d'équilibrage de charge dans le projet hôte de VPC partagé, ce type de déploiement ne sépare pas les responsabilités d'administration réseau et de développement de services.

Tous les composants et les backends de l'équilibreur de charge dans un projet de service

Le schéma d'architecture suivant illustre un déploiement de VPC partagé standard dans lequel tous les composants et les backends de l'équilibreur de charge se trouvent dans un projet de service. Ce type de déploiement est compatible avec tous les équilibreurs de charge d'application.

Les composants et les backends de l'équilibreur de charge doivent utiliser le même réseau VPC.

Référence de services inter-projets

La référence de services inter-projets est un modèle de déploiement dans lequel l'interface et le mappage d'URL de l'équilibreur de charge se trouvent dans un projet, tandis que le service de backend et les backends de l'équilibreur de charge se trouvent dans un autre projet.

Le référencement de services inter-projets permet aux organisations de configurer un équilibreur de charge central et d'acheminer le trafic vers des centaines de services répartis sur plusieurs projets différents. Vous pouvez gérer toutes les règles et stratégies de routage du trafic de manière centralisée dans un mappage d'URL. Vous pouvez également associer l'équilibreur de charge à un seul ensemble de noms d'hôte et de certificats SSL. Par conséquent, vous pouvez optimiser le nombre d'équilibreurs de charge nécessaires au déploiement de votre application et réduire les coûts de gestion, d'exploitation et de quota.

En disposant de projets différents pour chacune de vos équipes fonctionnelles, vous pouvez également assurer la séparation des rôles au sein de votre organisation. Les propriétaires de service peuvent se concentrer sur la création de services dans des projets de service, tandis que les équipes réseau peuvent provisionner et gérer des équilibreurs de charge dans un autre projet, et les deux peuvent être connectées à l'aide du référencement de services inter-projets.

Les propriétaires de services peuvent conserver leur autonomie quant à l'exposition de leurs services et contrôler quels utilisateurs peuvent y accéder à l'aide de l'équilibreur de charge. Ce procédé fait appel à un rôle IAM spécial appelé Rôle "Utilisateur des services d'équilibreur de charge Compute" (roles/compute.loadBalancerServiceUser).

La compatibilité du référencement des services inter-projets varie selon le type d'équilibreur de charge :

• Pour les équilibreurs de charge d'application externes globaux : l'interface et le mappage d'URL de votre équilibreur de charge peuvent référencer des services de backend ou des buckets backend de n'importe quel projet de la même organisation. Aucune restriction ne s'applique aux réseaux VPC. Bien que vous puissiez utiliser un environnement VPC partagé pour configurer un déploiement inter-projets, comme indiqué dans cet exemple, cela n'est pas obligatoire.

• Pour les équilibreurs de charge d'application externes régionaux : vous devez créer l'équilibreur de charge dans un environnement VPC partagé. L'interface et le mappage d'URL de l'équilibreur de charge doivent se trouver dans un projet hôte ou de service. Les services de backend et les backends de l'équilibreur de charge peuvent être répartis entre les projets hôtes ou de service du même environnement VPC partagé.

Pour apprendre à configurer un VPC partagé pour un équilibreur de charge d'application externe régional, avec et sans référencement de services inter-projets, consultez la page Configurer un équilibreur de charge d'application externe régional avec un VPC partagé.

Remarques sur l'utilisation du référencement des services inter-projets

• Trusted Cloud ne fait pas de distinction entre les ressources (par exemple, les services de backend) utilisant le même nom sur plusieurs projets. Par conséquent, lorsque vous utilisez le référencement de services multiprojet, nous vous recommandons d'utiliser des noms de service de backend uniques pour tous les projets de votre organisation.
• Si vous voyez une erreur telle que "Les références inter-projets pour cette ressource ne sont pas autorisées", assurez-vous d'avoir l'autorisation d'utiliser la ressource. Un administrateur du projet propriétaire de la ressource doit vous attribuer le rôle Utilisateur des services d'équilibreur de charge Compute (roles/compute.loadBalancerServiceUser). Ce rôle peut être attribué au niveau du projet ou de la ressource. Pour obtenir un exemple, consultez Accorder des autorisations à l'administrateur de l'équilibreur de charge Compute pour utiliser le service de backend ou le bucket de backend.

Exemple 1 : interface et backend de l'équilibreur de charge dans des projets de service différents

Voici un exemple de déploiement de VPC partagé dans lequel l'interface et le mappage d'URL de l'équilibreur de charge sont créés dans le projet de service A, et le mappage d'URL référence un service de backend dans le projet de service B.

Dans ce cas, les administrateurs réseau ou les administrateurs d'équilibrage de charge du projet de service A nécessitent un accès aux services de backend du projet de service B. Les administrateurs du projet de service B attribuent le rôle Utilisateur des services de l'équilibreur de charge Compute (roles/compute.loadBalancerServiceUser) aux administrateurs de l'équilibreur de charge du projet de service A qui souhaitent référencer le service de backend dans le projet de service B.

Exemple 2 : interface de l'équilibreur de charge dans le projet hôte et backends dans les projets de service

Voici un exemple de déploiement de VPC partagé dans lequel l'interface et le mappage d'URL de l'équilibreur de charge sont créés dans le projet hôte, et les services de backend (et les backends) sont créés dans les projets de service.

Dans ce cas, les administrateurs réseau ou les administrateurs d'équilibreur de charge du projet hôte requièrent un accès aux services de backend dans le projet de service. Les administrateurs de projets de service accordent le rôle Utilisateur des services de l'équilibreur de charge Compute (roles/compute.loadBalancerServiceUser) aux administrateurs de l'équilibreur de charge du projet hôte A qui souhaitent référencer le service de backend dans le projet de service.

Exemple 3 : Interface et backends de l'équilibreur de charge dans différents projets

Voici un exemple de déploiement dans lequel l'interface et le mappage d'URL de l'équilibreur de charge d'application externe global sont créés dans un projet différent du service de backend et des backends de l'équilibreur de charge. Ce type de déploiement n'utilise pas de VPC partagé et n'est compatible qu'avec les équilibreurs de charge d'application externes globaux.

Pour en savoir plus sur cette configuration, consultez Configurer le référencement de services multiprojets avec un service de backend et un bucket de backend.

Haute disponibilité et basculement

La haute disponibilité et le basculement dans les équilibreurs de charge d'application externes peuvent être configurés au niveau de l'équilibreur de charge. Pour ce faire, créez des équilibreurs de charge d'application externes régionaux de sauvegarde dans n'importe quelle région où vous en avez besoin.

Le tableau suivant décrit le comportement de basculement.

Compatibilité HTTP/2

HTTP/2 est une révision majeure du protocole HTTP/1. Il existe deux modes de compatibilité HTTP/2 :

• HTTP/2 sur TLS
• HTTP/2 en texte clair sur TCP

HTTP/2 sur TLS

Le protocole HTTP/2 sur TLS est accepté pour les connexions entre les clients et l'équilibreur de charge d'application externe, ainsi que pour les connexions entre l'équilibreur de charge et ses backends.

L'équilibreur de charge négocie automatiquement le protocole HTTP/2 avec les clients dans le cadre du handshake TLS à l'aide de l'extension TLS ALPN. Même si un équilibreur de charge est configuré pour utiliser HTTPS, les clients modernes utilisent par défaut HTTP/2. Ce fonctionnement est contrôlé au niveau du client et non au niveau de l'équilibreur de charge.

Si un client n'est pas compatible avec le protocole HTTP/2 et que l'équilibreur de charge est configuré pour utiliser HTTP/2 entre l'équilibreur de charge et les instances backend, l'équilibreur de charge peut toujours négocier une connexion HTTPS ou accepter des requêtes HTTP non sécurisées. Ces requêtes HTTPS ou HTTP sont ensuite transformées par l'équilibreur de charge pour relayer les requêtes par proxy via HTTP/2 vers les instances backend.

Pour utiliser HTTP/2 sur TLS, vous devez activer TLS sur vos backends et définir le protocole du service de backend sur HTTP2. Pour en savoir plus, consultez Chiffrement entre l'équilibreur de charge et les backends.

Nombre maximal de flux simultanés HTTP/2

Le paramètre SETTINGS_MAX_CONCURRENT_STREAMS HTTP/2 décrit le nombre maximal de flux accepté par le point de terminaison (flux lancés par le point de terminaison pair). La valeur annoncée par un client HTTP/2 à un équilibreur de chargeTrusted Cloud est sans importance, car l'équilibreur de charge ne lance pas de flux vers le client.

Dans le cas où l'équilibreur de charge utilise HTTP/2 pour communiquer avec un serveur qui s'exécute sur une VM, l'équilibreur de charge respecte la valeur SETTINGS_MAX_CONCURRENT_STREAMS annoncée par le serveur. Si une valeur "zéro" est annoncée, l'équilibreur de charge ne peut pas transférer les requêtes vers le serveur, et cela peut générer des erreurs.

Limites liées à HTTP/2

• Le protocole HTTP/2 entre l'équilibreur de charge et l'instance peut nécessiter beaucoup plus de connexions TCP à l'instance que HTTP ou HTTPS. Le regroupement de connexions, une optimisation qui réduit le nombre de ces connexions avec HTTP ou HTTPS, n'est pas disponible avec HTTP/2. Vous risquez par conséquent de constater des latences de backend élevées, car les connexions backend sont établies plus fréquemment.
• Le protocole HTTP/2 entre l'équilibreur de charge et le backend n'est pas compatible avec l'exécution du protocole WebSocket sur un seul flux d'une connexion HTTP/2 (RFC 8441).
• Le protocole HTTP/2 entre l'équilibreur de charge et le backend n'est pas compatible avec le serveur push.
• Le taux d'erreur gRPC et le volume de requêtes ne sont pas visibles dans l'APITrusted Cloud ni dans la console Trusted Cloud . Si le point de terminaison gRPC renvoie une erreur, les journaux de l'équilibreur de charge et les données de surveillance signalent le code d'état HTTP 200 OK.

HTTP/2 en texte clair sur TCP (H2C)

HTTP/2 en texte clair sur TCP, également appelé H2C, vous permet d'utiliser HTTP/2 sans TLS. H2C est compatible avec les deux types de connexions suivants :

• Connexions entre les clients et l'équilibreur de charge. Aucune configuration spéciale n'est requise.

• Connexions entre l'équilibreur de charge et ses backends.

  Pour configurer H2C pour les connexions entre l'équilibreur de charge et ses backends, définissez le protocole du service de backend sur H2C.

La compatibilité avec H2C est également disponible pour les équilibreurs de charge créés à l'aide du contrôleur GKE Gateway et de Cloud Service Mesh.

H2C n'est pas compatible avec les équilibreurs de charge d'application classiques.

Assistance WebSocket

Trusted Cloud Les équilibreurs de charge HTTP(S) sont compatibles avec le protocole WebSocket lorsque vous utilisez HTTP ou HTTPS comme protocole avec le backend. L'équilibreur de charge ne nécessite aucune configuration pour relayer les connexions WebSocket par proxy.

Le protocole WebSocket fournit un canal de communication full-duplex entre les clients et l'équilibreur de charge. Pour plus d'informations, consultez la norme RFC 6455.

Le protocole WebSocket fonctionne comme suit :

1. L'équilibreur de charge reconnaît une requête WebSocket Upgrade d'un client HTTP ou HTTPS. La requête contient les en-têtes Connection: Upgrade et Upgrade: websocket, suivis d'autres en-têtes de requête pertinents liés à WebSocket.
2. Le backend envoie une réponse WebSocket Upgrade. L'instance de backend envoie une réponse 101 switching protocol avec les en-têtes Connection: Upgrade et Upgrade: websocket, ainsi que d'autres en-têtes de réponse liés à WebSocket.
3. L'équilibreur de charge établit un trafic bidirectionnel par proxy pendant la durée de la connexion actuelle.

Si l'instance de backend renvoie un code d'état 426 ou 502, l'équilibreur de charge ferme la connexion.

L'affinité de session pour WebSockets fonctionne de la même manière que pour toute autre requête. Pour plus d'informations, consultez la section Affinité de session.

Compatibilité avec gRPC

gRPC est un framework Open Source pour les appels de procédure à distance. Il est basé sur le standard HTTP/2. Voici quelques exemples d'utilisation de gRPC :

• Systèmes distribués à faible latence et hautement évolutifs
• Développement de clients mobiles communiquant avec un serveur cloud
• Conception de nouveaux protocoles devant être précis, efficaces et indépendants du langage
• Conception à plusieurs couches pour permettre l'extension, l'authentification et la journalisation

Pour utiliser gRPC avec vos applications Trusted Cloud , vous devez relayer les requêtes par proxy de bout en bout via HTTP/2. Pour ce faire, créez un équilibreur de charge d'application avec l'une des configurations suivantes :

• Pour un trafic non chiffré de bout en bout (sans TLS) : créez un équilibreur de charge HTTP (configuré avec un proxy HTTP cible). Vous pouvez également configurer l'équilibreur de charge pour qu'il utilise HTTP/2 pour les connexions non chiffrées entre l'équilibreur de charge et ses backends en définissant le protocole du service de backend sur H2C.

• Pour le trafic chiffré de bout en bout (avec TLS) : créez un équilibreur de charge HTTPS (configuré avec un proxy HTTPS cible et un certificat SSL). L'équilibreur de charge négocie le protocole HTTP/2 avec les clients dans le cadre du handshake SSL à l'aide de l'extension TLS ALPN.

  De plus, vous devez vous assurer que les backends peuvent gérer le trafic TLS et configurer l'équilibreur de charge pour qu'il utilise HTTP/2 pour les connexions chiffrées entre l'équilibreur de charge et ses backends en définissant le protocole du service de backend sur HTTP2.

  L'équilibreur de charge peut toujours négocier le protocole HTTPS avec certains clients ou accepter des requêtes HTTP non sécurisées sur un équilibreur de charge configuré pour utiliser HTTP/2 entre l'équilibreur de charge et les instances backend. Ces requêtes HTTP ou HTTPS sont transformées par l'équilibreur de charge pour relayer les requêtes par proxy via HTTP/2 vers les instances backend.

Si vous souhaitez configurer un équilibreur de charge d'application en utilisant HTTP/2 avec un objet Ingress Google Kubernetes Engine, ou en associant gRPC et HTTP/2 avec un objet Ingress, consultez la page HTTP/2 pour l'équilibrage de charge avec Ingress.

Si vous souhaitez configurer un équilibreur de charge d'application externe en utilisant HTTP/2 avec Cloud Run, consultez Utiliser HTTP/2 derrière un équilibreur de charge.

Pour en savoir plus sur la résolution des problèmes liés à HTTP/2, consultez la section Résoudre les problèmes liés à l'utilisation du protocole HTTP/2 avec les backends.

Pour plus d'informations sur les limites du protocole HTTP/2, consultez la section Limites liées à HTTP/2.

Compatibilité avec TLS

Par défaut, lorsqu'il interrompt les requêtes SSL des clients, un proxy HTTPS cible n'accepte que les protocoles TLS 1.0, 1.1, 1.2 et 1.3.

Lorsque l'équilibreur de charge d'application classique utilise HTTPS comme protocole de service de backend, il peut négocier les protocoles TLS 1.0, 1.1, 1.2 ou 1.3 vers le backend.

Compatibilité avec le protocole TLS mutuel

Le protocole TLS mutuel (mTLS) est un protocole standard du secteur pour l'authentification mutuelle entre un client et un serveur. Il permet de s'assurer que le client et le serveur s'authentifient mutuellement en vérifiant que chacun détient un certificat valide émis par une autorité de certification (CA) de confiance. Contrairement au protocole TLS standard, où seul le serveur est authentifié, mTLS exige que le client et le serveur présentent des certificats, confirmant l'identité des deux parties avant l'établissement de la communication.

Tous les équilibreurs de charge d'application sont compatibles avec mTLS. Avec l'authentification mTLS, l'équilibreur de charge demande au client d'envoyer un certificat pour s'authentifier lors du handshake TLS avec l'équilibreur de charge. Vous pouvez configurer un magasin de confiance Certificate Manager que l'équilibreur de charge utilise ensuite pour valider la chaîne de confiance du certificat client.

Pour en savoir plus sur mTLS, consultez la page Authentification TLS mutuelle.

Compatibilité avec TLS 1.3 Early Data

Les données anticipées TLS 1.3 sont compatibles avec le proxy HTTPS cible des équilibreurs de charge d'application externes suivants pour HTTPS sur TCP (HTTP/1.1, HTTP/2) et HTTP/3 sur QUIC :

• Équilibreurs de charge d'application externes globaux
• Équilibreurs de charge d'application classiques

TLS 1.3 a été défini dans la RFC 8446 et introduit le concept de données anticipées, également appelées données à temps de trajet aller-retour nul (0-DAR), qui peuvent améliorer les performances des applications pour les connexions reprises de 30 à 50 %.

Avec TLS 1.2, deux allers-retours sont nécessaires avant que les données puissent être transmises de manière sécurisée. TLS 1.3 réduit ce délai à un aller-retour (1-DAR) pour les nouvelles connexions, ce qui permet aux clients d'envoyer des données d'application immédiatement après la première réponse du serveur. De plus, TLS 1.3 introduit le concept de données anticipées pour les sessions reprises, ce qui permet aux clients d'envoyer des données d'application avec le ClientHello initial, réduisant ainsi le temps d'aller-retour effectif à zéro (0-DAR). Les données anticipées TLS 1.3 permettent au serveur backend de commencer à traiter les données client avant la fin du processus de handshake avec le client, ce qui réduit la latence. Toutefois, il convient de prendre des précautions pour limiter les risques de relecture.

Étant donné que les données anticipées sont envoyées avant la fin du handshake, un pirate informatique peut tenter de capturer et de rejouer les requêtes. Pour atténuer ce problème, le serveur de backend doit contrôler soigneusement l'utilisation des données précoces, en la limitant aux requêtes idempotentes. Les méthodes HTTP qui sont censées être idempotentes, mais qui peuvent déclencher des modifications non idempotentes (par exemple, une requête GET modifiant une base de données), ne doivent pas accepter les données précoces. Dans ce cas, le serveur de backend doit rejeter les requêtes avec l'en-tête HTTP Early-Data: 1 en renvoyant un code d'état HTTP 425 Too Early.

Les requêtes avec données précoces ont l'en-tête HTTP Early-Data défini sur la valeur 1, ce qui indique au serveur de backend que la requête a été transmise dans les données précoces TLS. Il indique également que le client comprend le code d'état HTTP 425 Too Early.

Modes de données précoces TLS (0-DAR)

Vous pouvez configurer les données précoces TLS à l'aide de l'un des modes suivants sur la ressource de proxy HTTPS cible de l'équilibreur de charge.

• STRICT. Cela permet d'activer les données anticipées TLS 1.3 pour les requêtes avec des méthodes HTTP sécurisées (GET, HEAD, OPTIONS, TRACE) et les requêtes HTTP qui n'ont pas de paramètres de requête. Les requêtes qui envoient des données précoces contenant des méthodes HTTP non idempotentes (telles que POST ou PUT) ou avec des paramètres de requête sont rejetées avec un code d'état HTTP 425.

• PERMISSIVE. Cela permet d'activer les données précoces TLS 1.3 pour les requêtes avec des méthodes HTTP sécurisées (GET, HEAD, OPTIONS, TRACE). Ce mode ne refuse pas les requêtes qui incluent des paramètres de requête. Le propriétaire de l'application doit s'assurer que les données anticipées peuvent être utilisées pour chaque chemin de requête, en particulier pour les points de terminaison où la relecture des requêtes peut entraîner des effets secondaires indésirables, tels que la journalisation ou les mises à jour de la base de données déclenchées par les requêtes GET.

• DISABLED. Les données précoces TLS 1.3 ne sont pas annoncées, et toute tentative (non valide) d'envoi de données précoces est rejetée. Si vos applications ne sont pas équipées pour gérer les demandes de données anticipées de manière sécurisée, vous devez désactiver les données anticipées. TLS 1.3 Early Data est désactivé par défaut.

• UNRESTRICTED (non recommandé pour la plupart des charges de travail). Cela permet d'activer les données précoces TLS 1.3 pour les requêtes utilisant n'importe quelle méthode HTTP, y compris les méthodes non idempotentes telles que POST. Ce mode n'applique aucune autre limitation. Ce mode peut être utile pour les cas d'utilisation gRPC. Toutefois, nous ne recommandons pas cette méthode, sauf si vous avez évalué votre stratégie de sécurité et atténué le risque d'attaques par relecture à l'aide d'autres mécanismes.

Configurer les données précoces TLS

Pour activer ou désactiver explicitement TLS Early Data, procédez comme suit :

PATCH https://compute.googleapis.com/compute/v1/projects/{project}/global/targetHttpsProxies/TARGET_HTTPS_PROXY
{
    "tlsEarlyData":"TLS_EARLY_DATA_MODE",
    "fingerprint": "FINGERPRINT"
}

Une fois que vous avez configuré les données précoces TLS, vous pouvez envoyer des requêtes à partir d'un client HTTP compatible avec les données précoces TLS. Vous pouvez observer une latence plus faible pour les requêtes reprises.

Si un client non conforme à la norme RFC envoie une requête avec une méthode non idempotente ou avec des paramètres de requête, la requête est refusée. Un code d'état HTTP 425 Early s'affiche dans les journaux de l'équilibreur de charge, ainsi que la réponse HTTP suivante :

  HTTP/1.1 425 Too Early
  Content-Type: text/html; charset=UTF-8
  Referrer-Policy: no-referrer
  Content-Length: 1558
  Date: Thu, 03 Aug 2024 02:45:14 GMT
  Connection: close
  <!DOCTYPE html>
  <html lang=en>
  <title>Error 425 (Too Early)</title>
  <p>The request was sent to the server too early, please retry. That's
  all we know.</p>
  </html>
  

Limites

• Les équilibreurs de charge HTTPS n'envoient pas d'alerte de fermeture close_notify lorsqu'ils mettent fin aux connexions SSL. En d'autres termes, l'équilibreur de charge ferme la connexion TCP au lieu de procéder à l'arrêt d'une connexion SSL.

• Les équilibreurs de charge HTTPS n'acceptent que les minuscules dans les domaines d'un attribut de nom commun (CN) ou d'un autre nom d'objet (SAN) du certificat. Les certificats dont les domaines contiennent des majuscules ne sont renvoyés que lorsqu'ils sont définis comme certificat principal dans le proxy cible.

• Les équilibreurs de charge HTTPS n'utilisent pas l'extension SNI (Server Name Indication) lors de la connexion au backend, à l'exception des équilibreurs de charge avec des backends NEG Internet. Pour en savoir plus, consultez la section Chiffrement entre l'équilibreur de charge et les backends.

• Trusted Cloud ne garantit pas qu'une connexion TCP sous-jacente peut rester ouverte pendant toute la durée du délai avant expiration du service de backend. Les systèmes clients doivent mettre en œuvre une logique de nouvelle tentative au lieu de compter sur une connexion TCP pour être ouverte pendant de longues périodes.

• Lorsque vous créez un équilibreur de charge d'application externe régional au niveau Premium à l'aide de la consoleTrusted Cloud , seules les régions compatibles avec le niveau Standard sont disponibles dans la console Trusted Cloud . Pour accéder à d'autres régions, utilisez gcloud CLI ou l'API.

Étapes suivantes

• Pour savoir comment déployer un équilibreur de charge d'application externe régional, consultez la page Configurer un équilibreur de charge d'application externe régional avec un backend Compute Engine.

• Pour apprendre à configurer des fonctionnalités avancées de gestion du trafic avec l'équilibreur de charge d'application externe régional, consultez la page Présentation de la gestion du trafic pour les équilibreurs de charge d'application externes régionaux.