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

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

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, Google Kubernetes Engine (GKE) et Cloud Run. 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), des applications Cloud Run 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.

Services Web à trois niveaux avec accès mondial

Si vous activez l'accès mondial, vos VM clientes de niveau Web peuvent se trouver dans une autre région.

Cet exemple d'application multiniveau présente les éléments suivants :

  • Un niveau Web disponible dans le monde entier qui gère l'équilibrage de charge du trafic via l'équilibrage de charge HTTP(S)
  • Un niveau de base de données backend soumis à l'équilibrage de charge interne dans la région us-east1 auquel accède le niveau Web mondial
  • Une VM cliente qui fait partie du niveau Web dans la région europe-west1 qui accède au niveau de base de données soumis à l'équilibrage de charge interne situé dans us-east1
Application Web à trois niveaux avec équilibrage de charge HTTP(S), accès mondial et équilibrage de charge HTTP(S) interne.
Application Web à trois niveaux avec équilibrage de charge HTTP(S), accès mondial et équilibrage de charge HTTP(S) interne (cliquez pour agrandir)

É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. Veuillez noter les conditions suivantes :

  • 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.
  • Si vous souhaitez partager une adresse IP interne avec plusieurs règles de transfert, définissez l'option --purpose de l'adresse IP sur SHARED_LOADBALANCER_VIP.

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.

Règles de transfert et accès mondial

Les règles de transfert d'un équilibreur de charge HTTP(S) interne sont régionales, même lorsque l'accès mondial est activé. Après avoir activé l'accès mondial, l'option allowGlobalAccess de la règle de transfert régionale interne est définie sur true.

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

Les équilibreurs de charge HTTP(S) internes utilisant des proxys HTTPS cibles nécessitent des clés privées et des certificats SSL dans la configuration de l'équilibreur de charge. Ces équilibreurs de charge utilisent des certificats SSL Compute Engine régionaux autogérés.

Pour en savoir plus sur les certificats SSL et les équilibreurs de charge proxy Google Cloud, consultez la section Présentation des certificats SSL.

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)
  • Network endpoint groups

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.

Vérification 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.

Règles de pare-feu

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

  • Une règle d'autorisation d'entrée qui autorise le trafic provenant des plages de vérifications d'état centrales de Google.
    • 35.191.0.0/16
    • 130.211.0.0/22
    Actuellement, les vérifications d'état pour les NEG hybrides proviennent du mécanisme de vérification d'état centralisé de Google. Si vous ne pouvez pas autoriser le trafic provenant des plages de vérification d'état de Google à atteindre vos points de terminaison hybrides, et si vous préférez que les vérifications d'état proviennent d'adresses IP privées, adressez-vous à votre responsable de compte Google pour que votre projet soit autorisé à effectuer les vérifications d'état Envoy distribuées.
  • Une règle d'autorisation d'entrée qui autorise le trafic provenant du sous-réseau proxy réservé

Accès des clients

Par défaut, les clients doivent se trouver dans la même région que l'équilibreur de charge. Les clients peuvent se trouver sur le même réseau ou sur un réseau VPC connecté à l'aide de l'appairage de réseaux VPC. Vous pouvez activer l'accès mondial pour permettre aux clients de n'importe quelle région d'accéder à votre équilibreur de charge.

Équilibreur de charge HTTP(S) interne avec accès mondial (cliquez pour agrandir)
Équilibreur de charge HTTP(S) interne avec accès mondial (cliquez pour agrandir)

Le tableau suivant récapitule l'accès des clients.

Accès mondial désactivé Accès mondial activé
Les clients doivent se trouver dans la même région que l'équilibreur de charge. Ils doivent également se trouver sur le même réseau VPC que l'équilibreur de charge ou sur un réseau VPC connecté au réseau VPC de l'équilibreur de charge via l'appairage de réseaux VPC. Les clients peuvent se trouver dans n'importe quelle région. Ils doivent toujours se trouver sur le même réseau VPC que l'équilibreur de charge ou sur un réseau VPC connecté au réseau VPC de l'équilibreur de charge via l'appairage de réseaux VPC.
Les clients sur site peuvent accéder à l'équilibreur de charge via des tunnels Cloud VPN ou des rattachements de VLAN. Ces tunnels ou rattachements doivent se trouver dans la même région que l'équilibreur de charge. Les clients sur site peuvent accéder à l'équilibreur de charge via des tunnels Cloud VPN ou des rattachements de VLAN. Ces tunnels ou rattachements peuvent se trouver dans n'importe quelle région.

Architectures de VPC partagé

L'équilibrage de charge HTTP(S) interne est compatible 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 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.

Sous-réseaux et adresse IP Composants d'interface Composants backend

Créez le réseau et les sous-réseaux (y compris le sous-réseau proxy réservé) requis dans le projet hôte de VPC partagé.

L'adresse IP interne de l'équilibreur de charge peut être définie dans le projet hôte ou dans un projet de service, mais elle doit utiliser un sous-réseau dans le réseau VPC partagé souhaité dans le projet hôte. L'adresse elle-même provient de la plage d'adresses IP principale du sous-réseau référencé.

 L'adresse IP externe régionale, la règle de transfert, le proxy HTTP(S) cible et le mappage d'URL associé doivent être définis dans le même projet. Ce projet peut être le projet hôte ou un projet de service. Vous pouvez effectuer l'une des actions suivantes :
  • Créer des services de backend et des backends (groupes d'instances, NEG sans serveur ou autres types de backends compatibles) dans le même projet de service que les composants d'interface.
  • Créer des services de backend et des backends (groupes d'instances, NEG sans serveur ou autres types de backends compatibles) dans autant de projets de service que nécessaire. Un seul mappage d'URL peut référencer des services de backend sur différents projets. Ce type de déploiement est appelé référence de services inter-projets.

Chaque service de backend doit être défini dans le même projet que les backends auxquels il fait référence. Les vérifications de l'état associées aux services de backend doivent également être définies dans le même projet que le service de backend.

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 modèle ne distingue pas les responsabilités des administrateurs réseau et des développeurs de services.

Les clients peuvent accéder à un équilibreur de charge HTTP(S) interne s'ils se trouvent dans le même réseau VPC 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é.

Backends sans serveur dans un environnement VPC partagé

Pour un équilibreur de charge HTTP(S) interne qui utilise un backend de NEG sans serveur, le service de sauvegarde Cloud Run doit se trouver dans le même projet de service que le service de backend et le NEG sans serveur. Les composants d'interface de l'équilibreur de charge (règle de transfert, proxy cible, mappage d'URL) peuvent être créés dans le projet hôte, dans le même projet de service que les composants backend ou dans tout autre projet de service du même environnement VPC partagé.

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

Pour apprendre à configurer un VPC partagé pour un équilibreur de charge HTTP(S) interne (avec et sans référence de services inter-projets, consultez la page Configurer un équilibreur de charge HTTP(S) interne avec un VPC partagé.

Le référencement des services inter-projets peut être utilisé avec des groupes d'instances, des NEG sans serveur ou tout autre type de backend compatible. Si vous utilisez des NEG sans serveur, vous devez créer une VM dans le réseau VPC sur lequel vous souhaitez créer l'interface de l'équilibreur de charge. Pour apprendre à créer la VM, consultez la page Configurer un équilibreur de charge HTTP(S) interne avec Cloud Run.

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

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.

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 IAM 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.

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

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

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. Les administrateurs de projets de service accordent le rôle IAM 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.

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

Tous les composants et les backends de l'équilibreur de charge 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. Ce modèle de déploiement est compatible avec tous les équilibreurs de charge HTTP(S).

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é
Équilibreur de charge HTTP(S) interne sur un réseau VPC partagé

Délais d'expiration et nouvelles tentatives

L'équilibrage de charge HTTP(S) interne présente les délais avant expiration suivants :

  • 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 vous souhaitez télécharger un fichier de 500 Mo et que la valeur du délai avant expiration du service de backend est la valeur par défaut de 30 secondes, l'équilibreur de charge s'attend à ce que le backend fournisse l'intégralité du fichier de 500 Mo dans un délai de 30 secondes. Le délai avant expiration du service de backend peut être configuré de sorte qu'il ne soit pas assez long pour que le backend envoie sa réponse HTTP complète. Dans ce cas, si l'équilibreur de charge a au moins reçu des en-têtes de réponse HTTP, il renvoie les en-têtes de réponse complets et tout ce qu'il a pu tirer du corps de réponse dans le délai avant expiration du service de backend.

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

    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.

    Pour configurer le délai avant expiration du service de backend, utilisez l'une des méthodes suivantes :

    • Console Google Cloud : modifiez le champ Délai avant expiration du service de backend de l'équilibreur de charge.
    • Google Cloud CLI : utilisez la commande gcloud compute backend-services update pour modifier le paramètre --timeout de la ressource du service de backend.
    • API : modifiez le paramètre timeoutSec pour la ressource globale ou régionale 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. Le nombre de tentatives par défaut (numRetries) est de 1. Le délai avant expiration par défaut pour chaque tentative (perTryTimeout) est de 30 secondes avec une valeur de perTryTimeout configurable maximale de 24 heures.

Sans stratégie de nouvelle tentative, les requêtes infructueuses sans corps HTTP (par exemple, des requêtes GET) aboutissant à des réponses HTTP 502, 503 ou 504 sont relancées une seule fois. Les requêtes HTTP POST ne font pas l'objet d'une nouvelle tentative.

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.

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.

  • Lorsque vous utilisez l'équilibrage de charge HTTP(S) interne avec Cloud Run dans un environnement VPC partagé, les réseaux VPC autonomes dans les projets de service peuvent envoyer du trafic vers d'autres services Cloud Run déployés dans tout autre projet de service au sein d'un même environnement VPC partagé. Il s'agit d'un problème connu. Ce type d'accès sera bloqué à l'avenir.

Étape suivante