Présentation de l'équilibrage de charge HTTP(S) interne

L'équilibrage de charge HTTP(S) interne de Google Cloud est un équilibreur de charge régional de couche 7 basé sur un proxy qui vous permet d'exécuter et de faire évoluer vos services derrière une adresse IP interne.

L'équilibrage de charge HTTP(S) interne répartit le trafic HTTP et HTTPS entre les backends hébergés sur Compute Engine et Google Kubernetes Engine (GKE). L'équilibreur de charge n'est accessible que dans la région choisie de votre réseau de cloud privé virtuel (VPC), sur une adresse IP interne.

L'équilibrage de charge HTTP(S) interne est un service géré basé sur le proxy Envoy Open Source, ce qui permet de bénéficier de fonctionnalités avancées de contrôle du trafic s'appuyant sur les paramètres HTTP(S). Une fois l'équilibreur de charge configuré, il alloue automatiquement des proxys Envoy pour satisfaire vos besoins en termes de trafic.

De manière générale, un équilibreur de charge HTTP(S) interne se compose des éléments suivants :

  • Une adresse IP interne vers laquelle les clients envoient du trafic. Seuls les clients situés dans la même région que l'équilibreur de charge peuvent accéder à cette adresse IP. Les requêtes de clients internes restent en interne dans votre réseau et dans votre région.
  • Un ou plusieurs services de backend vers lesquels l'équilibreur de charge transmet le trafic. Les backends peuvent être des VM Compute Engine, des groupes de VM Compute Engine (via des groupes d'instances) ou des nœuds GKE (via des groupes de points de terminaison du réseau [NEG]). Ces backends doivent être situés dans la même région que l'équilibreur de charge.
Services internes avec un équilibrage de charge basé sur la couche 7 (cliquez pour agrandir)
Services internes avec un équilibrage de charge basé sur la couche 7 (cliquez pour agrandir)

Pour connaître les limites spécifiques à l'équilibrage de charge HTTP(S) interne, consultez la section Limites.

Pour en savoir plus sur les différences entre les équilibreurs de charge Google Cloud, consultez les documents suivants :

Cas d'utilisation

L'équilibrage de charge HTTP(S) interne convient à de nombreux cas d'utilisation. Cette section fournit quelques exemples généraux. Pour découvrir d'autres exemples, consultez les cas d'utilisation de la gestion du trafic.

Services Web à trois niveaux

L'équilibrage de charge HTTP(S) interne vous permet d'assurer la compatibilité avec les services Web classiques à trois niveaux. L'exemple suivant décrit comment effectuer le scaling de trois niveaux à l'aide de trois types d'équilibreurs de charge Google Cloud. À chaque niveau, le type d'équilibreur de charge dépend de votre type de trafic :

Le schéma suivant illustre la façon dont le trafic transite par les différents niveaux :

  1. Un équilibreur de charge HTTP(S) externe répartit le trafic provenant d'Internet entre un ensemble de groupes d'instances frontend Web dans différentes régions.
  2. Ces interfaces envoient le trafic HTTP(S) vers un ensemble d'équilibreurs de charge HTTP(S) internes régionaux (sujet de cette présentation).
  3. Les équilibreurs de charge HTTP(S) internes répartissent le trafic entre les groupes d'instances middleware.
  4. Ces groupes d'instances middleware envoient le trafic aux équilibreurs de charge TCP/UDP internes qui équilibrent la charge du trafic entre les clusters de stockage de données.
Routage basé sur la couche 7 pour les niveaux internes d'une application à plusieurs niveaux (cliquez pour agrandir)
Routage basé sur la couche 7 pour les niveaux internes d'une application à plusieurs niveaux

Équilibrage de charge à l'aide du routage basé sur un chemin d'accès

Un cas d'utilisation courant consiste à équilibrer la charge du trafic entre les services. Dans cet exemple, un client interne peut demander des vidéos et des images en utilisant la même URL de base, mygcpservice.internal, avec les chemins /video et /images.

Le mappage d'URL de l'équilibreur de charge HTTP(S) interne spécifie que les requêtes vers le chemin /video doivent être envoyées au service de backend des vidéos, et que les requêtes vers le chemin /images doivent être envoyées au service de backend des images. Dans l'exemple suivant, les services de backend des vidéos et des images sont diffusés à l'aide de VM Compute Engine, mais ils peuvent également être diffusés à l'aide de pods GKE.

Lorsqu'un client interne envoie une requête à l'adresse IP interne de l'équilibreur de charge, cet équilibreur évalue la requête selon cette logique avant de la transmettre au service de backend approprié.

Le schéma suivant illustre ce cas d'utilisation.

Services (microservices) internes avec un équilibrage de charge basé sur la couche 7 (cliquez pour agrandir)
Services (microservices) internes avec un équilibrage de charge basé sur la couche 7

Moderniser les anciens services

L'équilibrage de charge HTTP(S) interne peut constituer un outil efficace pour la modernisation des anciennes applications.

Votre ancienne application peut par exemple être une grande application monolithique difficile à mettre à jour. Dans ce cas, vous pouvez déployer un équilibreur de charge HTTP(S) interne devant votre ancienne application. Vous pouvez ensuite utiliser les fonctionnalités de contrôle du trafic de l'équilibreur de charge pour diriger un sous-ensemble du trafic vers de nouveaux microservices qui remplacent les fonctionnalités fournies par votre ancienne application.

Pour commencer, vous devez configurer le mappage d'URL de l'équilibreur de charge afin d'acheminer par défaut l'ensemble du trafic vers l'ancienne application. Cela permet de conserver le comportement existant. Au fil du développement des services de remplacement, vous devez mettre à jour le mappage d'URL pour acheminer des parties du trafic vers ces services de remplacement.

Imaginons que votre ancienne application comprend une fonctionnalité de traitement vidéo qui est diffusée lorsque des clients internes envoient des requêtes à /video. Vous pouvez séparer ce service vidéo dans un microservice distinct comme suit :

  1. Ajoutez l'équilibrage de charge HTTP(S) interne devant votre ancienne application.
  2. Créez un microservice de traitement vidéo de remplacement.
  3. Mettez à jour le mappage d'URL de l'équilibreur de charge pour que toutes les requêtes vers le chemin /video soient transmises au nouveau microservice plutôt qu'à l'ancienne application.

Lorsque vous développez des services de remplacement supplémentaires, vous devez continuer de mettre à jour le mappage d'URL. Au fil du temps, moins de requêtes seront acheminées vers l'ancienne application. À terme, vous disposerez de services de remplacement pour toutes les fonctionnalités fournies par l'ancienne application. À ce stade, vous pourrez supprimer l'ancienne application.

Équilibrage de charge avec une connectivité hybride

Cloud Load Balancing prend en charge le trafic d'équilibrage de charge vers des points de terminaison qui vont au-delà de Google Cloud, tels que des centres de données sur site et d'autres clouds publics que vous pouvez atteindre en utilisant la connectivité hybride.

Le schéma suivant illustre un déploiement hybride avec un équilibreur de charge HTTP(S) interne.

Connectivité hybride avec équilibrage de charge HTTP(S) interne (cliquez pour agrandir)
Connectivité hybride avec équilibrage de charge HTTP(S) interne (cliquez pour agrandir)

Private Service Connect

Vous pouvez utiliser l'équilibrage de charge HTTP(S) interne pour envoyer des requêtes aux API et services régionaux Google compatibles. Pour en savoir plus, consultez la page Utiliser Private Service Connect pour accéder aux API Google à l'aide des contrôles de service HTTP(S) client.

Équilibrage de charge pour les applications GKE

Si vous créez des applications dans GKE, nous vous recommandons d'utiliser le contrôleur GKE Ingress intégré, qui déploie des équilibreurs de charge Google Cloud pour le compte des utilisateurs de GKE. Cela est identique à l'architecture d'équilibrage de charge autonome décrite sur cette page, sauf que son cycle de vie est entièrement automatisé et contrôlé par GKE.

Documentation GKE associée :

Architecture et ressources

Le schéma suivant présente les ressources Google Cloud requises pour un équilibreur de charge HTTP(S) interne.

Composants de l'équilibrage de charge HTTP(S) interne (cliquez pour agrandir)
Composants de l'équilibrage de charge HTTP(S) interne

Chaque équilibreur de charge HTTP(S) interne utilise les ressources de configuration Google Cloud suivantes :

Sous-réseau proxy réservé

Dans le diagramme ci-dessus, 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 HTTP(S) internes. Tous les équilibreurs de charge HTTP(S) internes d'une région et d'un réseau VPC partagent le même sous-réseau proxy réservé, car tous les équilibreurs de charge HTTP(S) internes de la région et du réseau VPC partagent un pool de proxys Envoy. 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 HTTP(S) internes d'une région et d'un réseau VPC reçoivent les connexions du sous-réseau proxy réservé.
  • L'adresse IP d'un équilibreur de charge HTTP(S) interne n'est pas située dans le sous-réseau réservé au proxy. L'adresse IP de l'équilibreur de charge est définie par sa règle de transfert gérée en interne et décrite ci-dessous.

Règle de transfert et adresse IP

Une règle de transfert gérée interne spécifie une adresse IP interne, un port ainsi qu'un proxy HTTP(S) régional cible. Les clients utilisent l'adresse IP et le port pour se connecter aux proxys Envoy de l'équilibreur de charge. L'adresse IP de la règle de transfert correspond à l'adresse IP de l'équilibreur de charge (parfois appelée adresse IP virtuelle ou VIP).

Les clients se connectant à un équilibreur de charge HTTP(S) interne doivent utiliser HTTP version 1.1 ou ultérieure. Pour obtenir la liste complète des protocoles acceptés, consultez la page Fonctionnalités de l'équilibreur de charges.

L'adresse IP interne associée à la règle de transfert peut provenir de n'importe quel sous-réseau (du même réseau et de la même région) dont l'option --purpose est définie sur PRIVATE. Remarques :

  • L'adresse IP peut (mais ne doit pas nécessairement) provenir du même sous-réseau que les groupes d'instances backend.
  • L'adresse IP ne doit pas provenir du sous-réseau réservé au proxy dont l'option --purpose est définie sur REGIONAL_MANAGED_PROXY.

Chaque règle de transfert que vous utilisez dans un équilibreur de charge HTTP(S) interne peut faire référence à un seul port TCP. Pour les équilibreurs de charge HTTP, utilisez le port 80 ou 8080. Pour les équilibreurs de charge HTTPS, utilisez le port 443.

Proxy cible

Un proxy HTTP(S) régional cible met fin aux connexions HTTP(S) des clients. Le proxy HTTP(S) consulte le mappage d'URL pour déterminer comment acheminer le trafic vers les backends. Un proxy HTTPS cible utilise un certificat SSL pour s'authentifier auprès des clients.

L'équilibreur de charge conserve l'en-tête "Host" de la requête du client d'origine. L'équilibreur de charge ajoute également deux adresses IP à l'en-tête X-Forwarded-For :

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

Si aucun en-tête X-Forwarded-For n'est présent dans la requête entrante, ces deux adresses IP correspondent à l'intégralité de la valeur d'en-tête. Si la requête comporte un en-tête X-Forwarded-For, d'autres informations, telles que les adresses IP enregistrées par les proxys au route vers l'équilibreur de charge, sont conservées avant les deux adresses IP. L'équilibreur de charge ne vérifie aucune adresse IP antérieure aux deux dernières adresses IP de cet en-tête.

Si vous exécutez un proxy en guise de serveur backend, ce proxy ajoute généralement plus d'informations à l'en-tête X-Forwarded-For. Votre logiciel devra peut-être en tenir compte. Les requêtes proxy de l'équilibreur de charge proviennent d'une adresse IP du sous-réseau proxy réservé, et votre proxy sur l'instance backend peut enregistrer cette adresse, ainsi que l'adresse IP de l'instance backend.

Certificats SSL

Transport Layer Security (TLS) est un protocole de chiffrement utilisé dans les certificats SSL pour protéger les communications réseau.

Google Cloud utilise des certificats SSL pour assurer la confidentialité et la sécurité entre un client et un équilibreur de charge. Si vous utilisez l'équilibrage de charge HTTPS, vous devez installer un ou plusieurs certificats SSL sur le proxy HTTPS cible.

Pour en savoir plus sur les certificats SSL, consultez les articles suivants :

Mappage d'URL

Le proxy HTTP(S) exploite un mappage d'URL régional 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 régionaux spécifiques. Le mappage d'URL peut spécifier des actions supplémentaires à effectuer, telles que la réécriture d'en-têtes, l'envoi de redirections à des clients et la configuration de règles de délais avant expiration, entre autres.

Service backend

Un service de backend régional répartit les requêtes entre les backends opérationnels : groupes d'instances contenant des VM Compute Engine, NEG contenant des conteneurs GKE ou NEG Private Service Connect pointant vers des API et services Google compatibles.

Les services de backend sont compatibles avec les protocoles HTTP, HTTPS et HTTP/2. Le protocole HTTP/2 n'est compatible qu'avec TLS. Les clients et les backends n'ont pas besoin d'utiliser le même protocole de requête. Par exemple, les clients peuvent envoyer des requêtes à l'équilibreur de charge à l'aide du protocole HTTP/2, et l'équilibreur de charge peut transférer ces requêtes aux backends en utilisant le protocole HTTP/1.1.

Un ou plusieurs backends doivent être connectés au service de backend. Comme le champ d'application d'un équilibreur de charge HTTP(S) interne est régional et non global, les VM des clients et du backend, ou les points de terminaison, doivent tous se trouver dans la même région. Les backends peuvent être des groupes d'instances ou des groupes de points de terminaison du réseau ayant l'une des configurations suivantes :

  • Groupes d'instances gérés (zonaux ou régionaux)
  • Groupes d'instances non gérés (zonaux)
  • Groupes de points de terminaison du réseau (zonaux)

Vous ne pouvez pas utiliser à la fois des groupes d'instances et des groupes de points de terminaison du réseau sur le même service de backend.

Backends et réseaux VPC

Tous les backends doivent se trouver dans le même réseau VPC et dans la même région. Il n'est pas possible de placer des backends dans différents réseaux VPC, même ceux connectés à l'aide de l'appairage de réseaux VPC. Pour en savoir plus sur la manière dont les systèmes clients des réseaux VPC appairés peuvent accéder aux équilibreurs de charge, consultez la page Équilibrage de charge HTTP(S) interne et réseaux connectés.

Sous-paramètre du backend

Le sous-paramètre de backend est une fonctionnalité facultative qui améliore les performances et l'évolutivité en attribuant un sous-ensemble de backends à chacune des instances de proxy.

Le sous-paramètre de backend est désactivé par défaut. Pour en savoir plus sur l'activation de cette fonctionnalité, consultez la page Sous-paramètre de backend pour l'équilibreur de charge HTTP(S) interne.

Health check

Une vérification d'état régionale 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

Votre équilibreur de charge HTTP(S) interne nécessite les règles de pare-feu suivantes :

Délais d'expiration et nouvelles tentatives

L'équilibrage de charge HTTP(S) interne présente trois types de délais d'expiration distincts :
  • Un délai avant expiration HTTP du service de backend configurable, qui représente la durée pendant laquelle l'équilibreur de charge attend une réponse HTTP complète de la part de votre backend. La valeur par défaut du délai avant expiration du service de backend est de 30 secondes. La plage complète des valeurs de délai avant expiration autorisées est comprise entre 1 et 2 147 483 647 secondes.

    Par exemple, si la valeur du délai avant expiration du service de backend est la valeur par défaut de 30 secondes, les backends ont 30 secondes pour répondre aux requêtes. L'équilibreur de charge réessaye la requête HTTP GET une fois si le backend ferme la connexion ou ne parvient pas à envoyer des en-têtes de réponse à l'équilibreur de charge avant expiration du délai. Si le backend envoie des en-têtes de réponse ou si la requête envoyée au backend n'est pas une requête HTTP GET, l'équilibreur de charge n'effectue pas de nouvelle tentative. Si le backend ne répond pas du tout, l'équilibreur de charge renvoie une requête HTTP 5xx au client. Pour ces équilibreurs de charge, modifiez la valeur du délai avant expiration si vous souhaitez accorder plus ou moins de temps aux backends pour répondre aux requêtes.

    Le délai avant expiration du service de backend doit être défini sur la durée maximale possible entre le premier octet de la requête et le dernier octet de la réponse, pour l'interaction entre Envoy et votre backend. Si vous utilisez WebSockets, le délai avant expiration du service de backend doit être défini sur la durée maximale d'un WebSocket, inactif ou actif.

    Vous pouvez envisager d'augmenter ce délai dans les cas suivants :

    • si vous pensez qu'un backend va mettre plus de temps à renvoyer des réponses HTTP ;
    • si la connexion est mise à niveau vers une connexion WebSocket.

    Le délai avant expiration du service de backend que vous définissez est l'objectif le plus optimal. Cela ne garantit pas que les connexions TCP sous-jacentes resteront ouvertes pendant ce délai.

    Vous pouvez définir le délai avant expiration du service de backend sur la valeur de votre choix. Toutefois, définir un délai d'expiration de plus d'un jour (86 400 secondes) ne signifie pas que l'équilibreur de charge conservera une connexion TCP exécutée aussi longtemps. C'est possible, mais sans garantie. Google redémarre régulièrement les proxys Envoy pour les mises à jour logicielles et la maintenance de routine, et votre délai avant expiration du service de backend ne peut contourner cela. Plus la durée avant expiration de votre service de backend est longue, plus il est probable que Google mette fin à une connexion TCP pour la maintenance d'Envoy. Nous vous recommandons de mettre en œuvre une logique de nouvelle tentative pour réduire l'impact de tels événements.

    Pour en savoir plus, consultez la section Paramètres du service de backend.

    Le délai avant expiration du service de backend n'est pas un délai d'inactivité HTTP (message keepalive). Il est possible que l'entrée et la sortie (E/S) du backend soient bloquées en raison de la lenteur d'un client (un navigateur avec une connexion lente, par exemple). Ce délai d'attente n'est pas comptabilisé dans le délai avant expiration du service de backend.

  • Un délai d'expiration HTTP keepalive, dont la valeur est fixée à 10 minutes (600 secondes). Cette valeur n'est pas configurable par la modification du service de backend. Pour empêcher la fermeture prématurée des connexions par le backend, vous devez configurer le logiciel de serveur Web utilisé par vos backends afin que son délai avant expiration "keepalive" soit supérieur à 600 secondes. Ce délai avant expiration ne s'applique pas aux connexions WebSocket. Le tableau suivant présente les modifications à effectuer pour modifier les délais avant expiration "keepalive" des logiciels de serveur Web courants :
    Logiciel de serveur Web Paramètre Réglage par défaut Réglage recommandé
    Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
    nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;
  • Délai d'inactivité du flux, dont la valeur est fixée à 5 minutes (300 secondes). Cette valeur n'est pas configurable. Les flux HTTP deviennent inactifs après 5 minutes sans activité.

Tentatives

Les nouvelles tentatives sont configurables à l'aide d'une stratégie de nouvelle tentative dans le mappage d'URL (numRetries). Sans stratégie de nouvelle tentative, les requêtes sont limitées à une tentative par défaut. La condition de nouvelle tentative par défaut est gateway-error.

Certaines circonstances d'échec de requêtes GET conduisent l'équilibreur de charge à effectuer de nouvelles tentatives, par exemple lorsque le délai avant expiration du service de backend est écoulé. L'équilibreur ne tente pas de relancer les requêtes POST ayant échoué. Les requêtes faisant l'objet d'une nouvelle tentative ne génèrent qu'une seule entrée de journal associée à la réponse finale.

Pour en savoir plus, consultez la page Journalisation et surveillance de l'équilibrage de charge HTTP(S) interne.

Accès aux réseaux connectés

Vous pouvez accéder à un équilibreur de charge HTTP(S) interne dans votre réseau VPC à partir d'un réseau connecté à l'aide des éléments suivants :

  • Appairage de réseaux VPC
  • Cloud VPN et Cloud Interconnect

Pour obtenir des exemples détaillés, consultez la page Équilibrage de charge HTTP(S) interne et réseaux connectés.

Basculement

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 affiche une réponse HTTP 503 Service Unavailable.

Assistance WebSocket

Les équilibreurs de charge HTTP(S) de Google Cloud sont compatibles en mode natif avec le protocole WebSocket lorsque vous utilisez HTTP ou HTTPS en tant que 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 en duplex intégral entre clients et serveurs. Une requête HTTP(S) initialise le canal. Pour en savoir plus sur le protocole, consultez la RFC 6455.

Lorsque l'équilibreur de charge reconnaît une requête WebSocket Upgrade d'un client HTTP(S) suivie d'une réponse Upgrade réussie de la part de l'instance backend, l'équilibreur de charge relaie le trafic bidirectionnel par proxy pendant la durée de la connexion en cours. Si l'instance backend ne renvoie pas de réponse Upgrade réussie, l'équilibreur de charge ferme la connexion.

Le délai avant expiration d'une connexion WebSocket dépend du délai avant expiration du service backend configurable de l'équilibreur de charge, qui est de 30 secondes par défaut. Ce délai s'applique aux connexions WebSocket, qu'elles soient utilisées ou non.

L'affinité de session pour WebSockets fonctionne de la même manière que pour toute autre requête. Pour en savoir plus, 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 Google Cloud, vous devez relayer les requêtes par proxy de bout en bout via HTTP/2. Procédez comme suit :

  1. Configurez un équilibreur de charge HTTPS.
  2. Activez HTTP/2 comme protocole à utiliser entre l'équilibreur de charge et les backends.

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.

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.

Vous devez activer le protocole TLS sur vos backends. Pour en savoir plus, consultez la section Chiffrement entre l'équilibreur de charge et les backends.

Architectures de VPC partagé

L'équilibrage de charge HTTP(S) interne est compatible avec les réseaux qui utilisent un VPC partagé. Si vous n'êtes pas familiarisé avec le VPC partagé, consultez la présentation du VPC partagé.

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. De plus, vos administrateurs réseau peuvent gérer les adresses IP internes de manière sécurisée et efficace.

Il existe plusieurs façons de configurer l'équilibrage de charge HTTP(S) interne 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.

Commencez par créer le réseau, les sous-réseaux et les adresses IP requis dans le projet hôte. Pour les composants de l'équilibreur de charge, vous pouvez ensuite effectuer l'une des opérations suivantes:

Dans tous ces modèles de déploiement, les clients peuvent accéder à l'équilibreur de charge s'ils se trouvent dans le même réseau VPC partagé et la même région que l'équilibreur de charge. Les clients peuvent se situer dans le projet hôte, dans un projet de service associé ou dans n'importe quel réseau connecté.

Référence de services inter-projets

Dans ce modèle, le mappage d'URL et l'interface de l'équilibreur de charge se trouve 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 de l'environnement VPC partagé. Les services de backend inter-projets peuvent être référencés dans un seul mappage d'URL. C'est ce que l'on appelle la référence du service inter-projets.

Le référencement de services inter-projets permet aux développeurs de services et aux administrateurs de disposer d'une autonomie sur l'exposition de leurs services via l'équilibreur de charge géré de manière centralisée. Les administrateurs de projet de service utilisent le rôle IAM compute.loadBalancerServiceUser pour accorder l'accès aux services de backend dans leurs projets.

Exemple 1 : Interface de l'équilibreur de charge dans un projet de service

Voici un exemple de déploiement 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.

Interface et mappage d'URL de l'équilibreur de charge dans le projet de service
Interface et backend de l'équilibreur de charge dans différents projets de service

Effectuez les étapes de configuration suivantes pour configurer ce déploiement.

Dans le projet hôte :

  • Un administrateur de VPC partagé active le projet hôte et connecte les projets de service au projet hôte.
  • Le propriétaire, l'éditeur ou un rôle plus précis sur le projet hôte (par exemple, un administrateur réseau) crée des réseaux et des sous-réseaux, y compris des sous-réseaux proxy réservés, dans le projet hôte.
  • Le propriétaire, l'éditeur ou un rôle plus précis sur le projet hôte (par exemple, un administrateur de sécurité) configure les règles de pare-feu dans le projet hôte.
  • Un administrateur de VPC partagé configure les stratégies IAM qui déterminent quels sous-réseaux peuvent être utilisés par les administrateurs de projet de service.

Dans le projet de service B :

  • Le propriétaire, l'éditeur ou un rôle plus précis (par exemple, Administrateur Compute) du projet de service B crée le service de backend et les backends (groupes d'instances ou NEG).
  • L'éditeur de propriétaire du projet de service B ou un rôle plus précis (par exemple, Administrateur Compute) attribue le rôle compute.loadBalancerServiceUser aux administrateurs de l'équilibreur de charge dans le projet de service A qui souhaitent référencer le service de backend dans le projet B. Le rôle compute.loadBalancerServiceUser peut être attribué au niveau du service de backend ou au niveau du projet.
  • Ces ressources d'équilibrage de charge référencent un réseau VPC partagé et des sous-réseaux dans le projet hôte.

Dans le projet de service A :

  • Le propriétaire, l'éditeur ou un rôle plus précis (par exemple, Administrateur réseau ou Administrateur de l'équilibreur de charge) du projet de service A crée les composants d'interface de l'équilibreur de charge (règle de transfert, proxy HTTP(S) cible et mappage d'URL).
  • Ces ressources d'équilibrage de charge référencent un réseau et un sous-réseau VPC partagé dans le projet hôte.

Pour apprendre à configurer un équilibreur de charge HTTP(S) interne avec des références de service inter-projets, consultez la page Configurer l'équilibrage de charge HTTP(S) interne avec un VPC partagé.

Exemple 2 : Interface de l'équilibreur de charge dans le projet hôte

Dans ce type de déploiement, 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 les projets de service.

Interface et mappage d'URL de l'équilibreur de charge dans le projet hôte
Interface et mappage d'URL de l'équilibreur de charge dans le projet hôte

Pour apprendre à configurer un équilibreur de charge HTTP(S) interne avec des références de service inter-projets, consultez la page Configurer l'équilibrage de charge HTTP(S) interne avec un VPC partagé.

Équilibreur de charge et backends dans un projet de service

Dans ce modèle, tous les composants et les backends de l'équilibreur de charge se trouvent dans un projet de service. L'équilibreur de charge utilise les adresses IP et les sous-réseaux du projet hôte.

Équilibrage de charge HTTP(S) interne sur un réseau VPC partagé
Équilibrage de charge HTTP(S) interne sur un réseau VPC partagé

Projet hôte

Dans le projet hôte :

  • Un administrateur de VPC partagé active le projet hôte et connecte les projets de service au projet hôte.
  • Le propriétaire, l'éditeur ou un rôle plus précis sur le projet hôte (par exemple, un administrateur réseau) crée des réseaux et des sous-réseaux, y compris des sous-réseaux proxy réservés, dans le projet hôte.
  • Le propriétaire, l'éditeur ou un rôle plus précis sur le projet hôte (par exemple, un administrateur de sécurité) configure les règles de pare-feu dans le projet hôte.
  • Un administrateur de VPC partagé configure les stratégies IAM qui déterminent quels sous-réseaux peuvent être utilisés par les administrateurs de projet de service.

Projet de service

  • Le propriétaire, l'éditeur ou un rôle plus précis sur le projet de service (par exemple, un administrateur Compute) crée des instances backend.
  • Le propriétaire, l'éditeur ou un rôle plus précis sur le projet de service (par exemple, administrateur réseau ou administrateur d'équilibreur de charge) crée les composants de l'équilibreur de charge (règle de transfert, proxy HTTP(S) cible, mappage d'URL, services de backend et vérifications d'état).
  • Ces ressources d'équilibrage de charge et instances backend font référence à un réseau VPC partagé et à des sous-réseaux du projet hôte.

Pour apprendre à configurer un équilibreur de charge HTTP(S) interne pour un réseau VPC partagé, consultez la page Configurer l'équilibrage de charge HTTP(S) interne avec un VPC partagé.

Équilibreur de charge et backends dans un projet hôte

Dans ce modèle, le réseau VPC partagé, les composants de l'équilibreur de charge et les backends sont tous dans le projet hôte. Ce modèle ne sépare pas les responsabilités d'administration réseau et de développement de services.

La configuration de ce modèle est identique à celle de l'équilibreur de charge dans un réseau VPC autonome. Suivez les étapes de la section Configurer l'équilibrage de charge HTTP(S) interne.

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 HTTP(S) interne utilise HTTPS comme protocole de service de backend, il peut négocier les protocoles TLS 1.0, 1.1 ou 1.2 vers le backend.

Limites

  • Rien ne garantit qu'une requête d'un client situé dans une zone de la région est envoyée à un backend situé dans la même zone que le client. L'affinité de session ne limite pas la communication entre les zones.

  • L'équilibrage de charge HTTP(S) interne n'est pas compatible avec les fonctionnalités suivantes :

  • Les équilibreurs de charge HTTP(S) internes ne sont compatibles avec le protocole HTTP/2 que via TLS.

  • Les clients se connectant à un équilibreur de charge HTTP(S) interne doivent utiliser HTTP version 1.1 ou ultérieure. Le protocole HTTP 1.0 n'est pas compatible.

  • Google Cloud ne vous avertit pas si votre sous-réseau proxy réservé manque d'adresses IP.

  • La règle de transfert interne utilisée par votre équilibreur de charge HTTP(S) interne ne doit disposer que d'un port.

  • L'équilibrage de charge HTTP(S) interne n'est pas compatible avec Cloud Trace.

Étape suivante