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

Ce document présente les concepts que vous devez maîtriser pour configurer des équilibreurs de charge d'application internes.

Un équilibreur de charge d'application interne de Google Cloud 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 adresse IP interne. L'équilibreur de charge d'application interne répartit le trafic HTTP et HTTPS entre les backends hébergés sur diverses plates-formes Google Cloud, telles que Compute Engine, Google Kubernetes Engine (GKE) et Cloud Run. Pour en savoir plus, consultez la section Cas d'utilisation.

Modes de fonctionnement

Vous pouvez configurer un équilibreur de charge d'application interne dans les modes suivants :

  • Équilibreur de charge d'application interne interrégional. Il s'agit d'un équilibreur de charge multirégional mis en œuvre en tant que service géré basé sur le proxy Envoy Open Source. Le mode interrégional vous permet d'équilibrer la charge du trafic sur les services de backend distribués à l'échelle mondiale, y compris la gestion du trafic qui garantit que celui-ci est dirigé vers le backend le plus proche. Cet équilibreur de charge permet également la haute disponibilité. Le positionnement des backends dans plusieurs régions permet d'éviter les défaillances dans une seule région. Si les backends d'une région sont indisponibles, le trafic peut basculer vers une autre région.

  • Équilibreur de charge d'application interne régional Il s'agit d'un équilibreur de charge régional mis en œuvre en tant que service géré sur le proxy Envoy Open Source. Le mode régional garantit que tous les clients et backends proviennent d'une région spécifiée, ce qui s'avère utile lorsque vous avez besoin d'une conformité régionale. Cet équilibreur de charge est activé avec des 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.

    Le tableau suivant décrit les principales différences entre les modes régional et interrégional :

    Fonctionnalité Équilibreur de charge d'application interne interrégional Équilibreur de charge d'application interne régional
    Adresse IP virtuelle de l'équilibreur de charge. Allouée depuis un sous-réseau dans une région Google Cloud spécifique.

    Les adresses IP virtuelles de plusieurs régions peuvent partager le même service de backend global. Vous pouvez configurer l'équilibrage de charge global basé sur le DNS à l'aide de règles de routage DNS pour acheminer les requêtes des clients vers l'adresse IP virtuelle la plus proche.

    		 Allouée depuis un sous-réseau dans une région Google Cloud spécifique.
    Accès des clients Toujours accessible mondialement. Les clients de n'importe quelle région Google Cloud d'un VPC peuvent envoyer du trafic vers l'équilibreur de charge. Par défaut, non accessible mondialement.
    Vous pouvez éventuellement activer l'accès mondial.
    Backends à équilibrage de charge Backends globaux.
    L'équilibreur de charge peut envoyer du trafic vers des backends dans n'importe quelle région.    		 Backends régionaux.
    L'équilibreur de charge ne peut envoyer du trafic qu'aux backends situés dans la même région que le proxy de l'équilibreur de charge.
    Haute disponibilité et basculement Basculement automatique vers des backends opérationnels dans la même région ou dans des régions différentes. Basculement automatique vers des backends opérationnels dans la même région.

Identifier le mode

Cloud Console

  1. Dans Google Cloud Console, accédez à la page Équilibrage de charge.

    Accéder à la page "Équilibrage de charge"

  2. Dans l'onglet Équilibreurs de charge, vous pouvez voir le type, le protocole et la région de l'équilibreur de charge. Si la région est vide, l'équilibreur de charge est en mode interrégional. Le tableau suivant récapitule comment identifier le mode de l'équilibreur de charge.

    Mode d'équilibreur de charge Type d'équilibreur de charge Type d'accès Région
    Équilibreur de charge d'application interne régional Application Interne Spécifie une région
    Équilibreur de charge d'application interne interrégional Application Interne

gcloud

  1. Pour déterminer le mode d'un équilibreur de charge, exécutez la commande suivante :

    gcloud compute forwarding-rules describe FORWARDING_RULE_NAME

    Dans le résultat de la commande, vérifiez le schéma d'équilibrage de charge, la région et le niveau de réseau. Le tableau suivant récapitule comment identifier le mode de l'équilibreur de charge.

    Mode d'équilibreur de charge Schéma d'équilibrage de charge Règle de transfert
    Équilibreur de charge d'application interne interrégional INTERNAL_MANAGED Mondial
    Équilibreur de charge d'application interne régional INTERNAL_MANAGED Régional

Architecture et ressources

Le schéma suivant présente les ressources Google Cloud requises pour les équilibreurs de charge d'application internes:

Interrégional

Ce schéma montre les composants d'un déploiement d'équilibreur de charge d'application interne interrégional de niveau Premium au sein du même réseau VPC. Chaque règle de transfert globale utilise une adresse IP régionale que les clients utilisent pour se connecter.

Composants de l'équilibreur de charge d'application interne interrégional
Composants de l'équilibreur de charge d'application interne interrégional (cliquez pour agrandir)

Régional

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

Composants de l'équilibreur de charge d'application interne
Composants de l'équilibreur de charge d'application interne régional (cliquez pour agrandir)

Les ressources suivantes sont requises pour déployer un équilibreur de charge d'application interne:

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 d'application internes.

Le tableau suivant décrit les différences entre les sous-réseaux proxy réservés en mode régional et interrégional :

Mode d'équilibreur de charge Valeur de l'option --purpose du sous-réseau proxy réservé
Équilibreur de charge d'application interne interrégional

GLOBAL_MANAGED_PROXY

Les équilibreurs de charge régionaux et interrégionaux ne peuvent pas partager les mêmes sous-réseaux

L'équilibreur de charge interrégional basé sur Envoy doit disposer d'un sous-réseau proxy réservé dans chaque région où il est configuré. Les proxys d'équilibreur de charge interrégionaux dans la même région et le même réseau partagent le même sous-réseau proxy réservé.
Équilibreur de charge d'application interne régional

REGIONAL_MANAGED_PROXY

Les équilibreurs de charge régionaux et interrégionaux ne peuvent pas partager les mêmes sous-réseaux

Tous les équilibreurs de charge régionaux basés sur Envoy d'une région et d'un réseau VPC partagent le 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 internes situés dans une région et sur un réseau VPC reçoivent les connexions du sous-réseau proxy réservé.
  • L'adresse IP virtuelle d'un équilibreur de charge d'application interne 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 interne et décrite ci-dessous.

Règle de transfert et adresse IP

Les règles de transfert permettent d'acheminer le trafic par adresse IP, par port et par protocole, vers une configuration d'équilibrage de charge comprenant un proxy cible et un service de backend.

Spécification de l'adresse IP. Chaque règle de transfert fournit une adresse IP unique que vous pouvez utiliser dans les enregistrements DNS de votre application. Vous pouvez soit réserver une adresse IP statique qui sera utilisée par le service, soit laisser Cloud Load Balancing en attribuer une pour votre compte. Nous vous recommandons de réserver une adresse IP statique. Si vous ne le faites pas, vous devez mettre à jour votre enregistrement DNS avec l'adresse IP éphémère nouvellement attribuée chaque fois que vous supprimez une règle de transfert et en créez une autre.

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

L'adresse IP interne associée à la règle de transfert peut provenir d'un sous-réseau du même réseau et de la même région que vos backends.

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 interne (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 internes dépend du mode de l'équilibreur de charge.

Mode d'équilibreur de charge Règle de transfert, adresse IP et sous-réseau proxy réservé --purpose Routage depuis le client vers l'interface de l'équilibreur de charge
Équilibreur de charge d'application interne interrégional

Règle de transfert globale

Adresses IP régionales

Schéma d'équilibrage de charge :

INTERNAL_MANAGED

Sous-réseau proxy réservé --purpose :

GLOBAL_MANAGED_PROXY

Adresse IP --purpose :

SHARED_LOADBALANCER_VIP

L'accès global est activé par défaut pour permettre aux clients de n'importe quelle région d'un VPC d'accéder à votre équilibreur de charge. Les backends peuvent se trouver dans plusieurs régions.
Équilibreur de charge d'application interne régional

Règle de transfert régionale

Adresse IP régionale

Schéma d'équilibrage de charge :

INTERNAL_MANAGED

Sous-réseau proxy réservé --purpose :

REGIONAL_MANAGED_PROXY

Adresse IP --purpose :

SHARED_LOADBALANCER_VIP

Vous pouvez activer l'accès global pour autoriser les clients de n'importe quelle région d'un VPC à accéder à votre équilibreur de charge. Les backends doivent également se trouver dans la même région que l'équilibreur de charge.

Règles de transfert et réseaux VPC

Cette section décrit comment les règles de transfert utilisées par les équilibreurs de charge d'application externes sont associées aux réseaux VPC.

Mode d'équilibreur de charge Association de réseaux VPC
Équilibreur de charge d'application interne interrégional

Équilibreur de charge d'application interne régional

Les adresses IPv4 internes régionales existent toujours dans les réseaux VPC. Lorsque vous créez la règle de transfert, vous devez spécifier le sous-réseau à partir duquel l'adresse IP interne est extraite. Ce sous-réseau doit se trouver dans la même région et sur le même réseau VPC qu'un sous-réseau proxy réservé. Il existe donc une association réseau implicite.

Proxy cible

Un proxy HTTP(S) 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.

Selon le type de trafic que votre application doit gérer, vous pouvez configurer un équilibreur de charge avec un proxy HTTP cible ou HTTPS cible.

Le tableau suivant présente les API de proxy cibles requises par les équilibreurs de charge d'application internes:

Mode d'équilibreur de charge Proxy cible
Équilibreur de charge d'application interne interrégional
Équilibreur de charge d'application interne régional

Certificats SSL

Les équilibreurs de charge d'application 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.

Le tableau suivant spécifie le type de certificats SSL requis par les équilibreurs de charge d'application internes dans chaque mode :

Mode d'équilibreur de charge Type de certificat SSL
Équilibreur de charge d'application interne régional

Certificats SSL régionaux Compute Engine

Certificats autogérés régionaux et certificats gérés par Google du gestionnaire de certificats.

Les types de certificats gérés par Google suivants sont compatibles avec le gestionnaire de certificats :

Les certificats gérés par Google avec une autorisation d'équilibreur de charge ne sont pas acceptés.
Équilibreur de charge d'application interne interrégional

Certificats autogérés et certificats gérés par Google du gestionnaire de certificats.

Les types de certificats gérés par Google suivants sont compatibles avec le gestionnaire de certificats :

Les certificats gérés par Google avec une autorisation d'équilibreur de charge ne sont pas acceptés.

Les certificats SSL Compute Engine ne sont pas acceptés.

Mappages d'URL

Le proxy HTTP(S) cible utilise des mappages 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 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.

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

Mode d'équilibreur de charge Type de mappage d'URL
Équilibreur de charge d'application interne interrégional Mappages d'URL générales
Équilibreur de charge d'application interne régional Mappages d'URL régionaux

Service 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 de réseau (NEG)). Pour en savoir plus sur les services de backend, consultez la page Présentation des services de backend.

Champ d'application du service de backend

Le tableau suivant indique la ressource et la portée du service de backend utilisées par les équilibreurs de charge d'application internes:

Mode d'équilibreur de charge Ressources du service de backend
Équilibreur de charge d'application interne interrégional backendServices (global)
Équilibreur de charge d'application interne régional regionBackendServices (régional)

Protocole de communication avec les backends

Les services de backend des é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 pas de TLS
  • HTTPS, qui utilise HTTP/1.1 et TLS
  • HTTP/2, qui utilise HTTP/2 et TLS (HTTP/2 sans chiffrement n'est pas pris en charge).

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

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 de HTTP/2, mais l'équilibreur de charge peut communiquer avec les backends à l'aide de HTTP/1.1 (HTTP ou HTTPS).

Backends

Le tableau suivant spécifie les fonctionnalités de backend compatibles avec les équilibreurs de charge d'application internes dans chaque mode.


Mode d'équilibreur de charge 		Backends compatibles sur un service de backend* Compatible avec les buckets backend Compatible avec Google Cloud Armor Compatible avec Cloud CDN Compatible avec IAP Compatible avec les extensions de service
Groupes d'instances† NEG zonaux‡ NEG Internet NEG sans serveur NEG hybrides NEG Private Service Connect
Équilibreur de charge d'application interne interrégional
Cloud Run
Équilibreur de charge d'application interne régional
Cloud Run

* Les backends d'un service de backend doivent être du même type: tous des groupes d'instances ou tous du même type de NEG. Une exception à cette règle est que les NEG zonaux GCE_VM_IP_PORT et les NEG hybrides peuvent être utilisés sur le même service de backend pour prendre en charge une architecture hybride.

† Les combinaisons de groupes d'instances non gérés zonaux, gérés zonaux et gérés régionaux sont acceptées pour le même service de backend. Lorsque vous utilisez l'autoscaling pour un groupe d'instances géré qui est un backend pour deux services de backend ou plus, configurez la règle d'autoscaling du groupe d'instances de sorte qu'elle utilise plusieurs signaux.

‡ Les NEG zonaux doivent utiliser des points de terminaison GCE_VM_IP_PORT.

Backends et réseaux VPC

Les restrictions concernant l'emplacement des backends dépendent du type de backend.

  • Pour les groupes d'instances, les NEG zonaux et les NEG de connectivité hybride, tous les backends doivent se trouver dans le même projet et la même région que le service de backend. Toutefois, un équilibreur de charge peut faire référence à un backend qui utilise un réseau VPC différent dans le même projet que le service de backend (cette fonctionnalité est en version Preview). La connectivité entre le réseau VPC de l'équilibreur de charge et le réseau VPC backend peut être configurée à l'aide de l'appairage de réseaux VPC, de tunnels Cloud VPN, de rattachements VLAN Cloud Interconnect ou d'un framework Network Connectivity Center.

    Définition du réseau 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 réseau du backend

    Le réseau de votre backend doit répondre à l'une des exigences réseau suivantes :

    • Le réseau VPC du backend doit correspondre exactement au réseau VPC de la règle de transfert.

    • Le réseau VPC du backend doit être connecté au réseau VPC de la règle de transfert à l'aide de l'appairage de réseaux VPC. Vous devez configurer des échanges de routes de sous-réseau pour autoriser la communication entre le sous-réseau proxy réservé du réseau VPC de la règle de transfert et les sous-réseaux utilisés par les instances de backend ou les points de terminaison.

  • Le réseau VPC du backend et le réseau VPC de la règle de transfert doivent être des spokes VPC sur le même hub Network Connectivity Center. Les filtres d'importation et d'exportation doivent autoriser la communication entre le sous-réseau proxy réservé du réseau VPC de la règle de transfert et les sous-réseaux utilisés par les instances ou points de terminaison backend.

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

Backends et interfaces réseau

Si vous utilisez des backends de groupe d'instances, les paquets sont toujours envoyés à nic0. Si vous souhaitez envoyer des paquets à différentes cartes réseau, 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.

Sous-paramètre du backend

Le sous-paramètre de backend est une fonctionnalité facultative compatible avec l'équilibreur de charge d'application interne régional 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 d'application interne.

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. Toutefois, pour les NEG hybrides, les vérifications d'état proviennent du sous-réseau proxy réservé. Pour en savoir plus, consultez la section sur les vérifications d'état Envoy distribuées dans 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 internes 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 internes:

Mode d'équilibreur de charge Type de vérification d'état
Équilibreur de charge d'application interne interrégional Monde
Équilibreur de charge d'application interne régional Regional (Régional)

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

Règles de pare-feu

Un équilibreur de charge d'application interne nécessite les règles de pare-feu suivantes:

Il existe certaines exceptions aux exigences des règles de pare-feu pour ces plages :

  • L'ajout de plages de vérification de l'état à la liste d'autorisation de Google n'est pas nécessaire pour les NEG hybrides. Toutefois, si vous utilisez à la fois des NEG hybrides et zonaux dans un service de backend, vous devez ajouter les plages de vérification de l'état Google à la liste d'autorisation pour les NEG zonaux.
  • Pour les NEG Internet régionaux, les vérifications d'état sont facultatives. Le trafic provenant des équilibreurs de charge utilisant des NEG Internet régionaux provient du sous-réseau proxy réservé, puis est converti en NAT (à l'aide de Cloud NAT) en adresses IP NAT allouées manuellement ou automatiquement. Ce trafic inclut à la fois les vérifications d'état et les requêtes des utilisateurs depuis l'équilibreur de charge vers les backends. Pour en savoir plus, consultez la page NEG régionaux : utiliser Cloud NAT pour la sortie.

Accès des clients

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.

Pour les équilibreurs de charge d'application internes interrégionaux, l'accès mondial est activé par défaut. Les clients de n'importe quelle région d'un VPC peuvent accéder à votre équilibreur de charge.

Pour les équilibreurs de charge d'application internes régionaux, les clients doivent se trouver dans la même région que l'équilibreur de charge par défaut. Vous pouvez activer l'accès global pour autoriser les clients de n'importe quelle région d'un VPC à accéder à votre équilibreur de charge.

Le tableau suivant récapitule l'accès des clients pour les équilibreurs de charge d'application internes régionaux :

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.

Assistance GKE

GKE utilise les équilibreurs de charge d'application internes de la manière suivante:

  • Les passerelles internes créées à l'aide du contrôleur GKE Gateway peuvent utiliser n'importe quel mode d'un équilibreur de charge d'application interne. 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.

  • Les entrées internes créées à l'aide du contrôleur GKE Ingress sont toujours des équilibreurs de charge d'application internes régionaux. Le contrôleur GKE Ingress utilise toujours des backends NEG zonaux GCE_VM_IP_PORT.

Architectures de VPC partagé

Les équilibreurs de charge d'application internes 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 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 interne 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 un 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 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.

L'équilibreur de charge utilise les adresses IP et les sous-réseaux du projet hôte. Les clients peuvent accéder à un équilibreur de charge d'application interne 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é.

Équilibreur de charge d'application interne sur un réseau VPC partagé
Équilibreur de charge d'application interne sur un réseau VPC partagé

Backends sans serveur dans un environnement VPC partagé

Pour un équilibreur de charge d'application 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

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

Pour les équilibreurs de charge d'application internes, le référencement de services inter-projets n'est compatible qu'avec les environnements VPC partagés.

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

Limites connues liées au référencement des services inter-projets

  • Vous ne pouvez pas référencer de service de backend multiprojet si le service de backend comporte des backends NEG Internet régionaux. Tous les autres types de backends sont acceptés.
  • Google 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.

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

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 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 (cliquez pour agrandir).

Délais d'expiration et nouvelles tentatives

Les équilibreurs de charge d'application internes sont compatibles avec les types de délais d'expiration suivants:

Type de délai d'expiration et description Valeurs par défaut Valeurs personnalisées acceptées
Interrégional Régional
Délai avant expiration du service de backend

Un délai avant expiration de la requête et de la réponse Représente la durée maximale autorisée entre le moment où l'équilibreur de charge envoie le premier octet d'une requête au backend et le moment où le backend renvoie le dernier octet de la réponse HTTP à l'équilibreur de charge. Si le backend n'a pas renvoyé la réponse HTTP entière à l'équilibreur de charge dans ce délai, les données de réponse restantes sont supprimées.
  • Pour les NEG sans serveur sur un service de backend : 60 minutes
  • Pour tous les autres types de backends sur un service de backend: 30 secondes
Délai d'expiration du message keepalive HTTP client

Durée maximale d'inactivité de la connexion TCP entre un client et le proxy Envoy géré de l'équilibreur de charge. (La même connexion TCP peut être utilisée pour plusieurs requêtes HTTP.)

 10 minutes (600 secondes)
Délai avant expiration du message keepalive HTTP du backend

Durée maximale d'inactivité de la connexion TCP entre le proxy Envoy géré de l'équilibreur de charge et un backend. (La même connexion TCP peut être utilisée pour plusieurs requêtes HTTP.)

 10 minutes (600 secondes)

Délai avant expiration du service de backend

Le délai avant expiration du service backend configurable représente la durée maximale pendant laquelle l'équilibreur de charges attend que de votre backend traite une requête HTTP et renvoie la réponse HTTP correspondante. À l'exception des NEG sans serveur, la valeur par défaut du délai avant expiration du service de backend est de 30 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 de 90 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 90 secondes. Le délai avant expiration du service de backend peut être configuré de sorte qu'il soit insuffisant pour envoyer une 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 du backend, 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.

Vous devez définir le délai avant expiration du service de backend sur la durée la plus longue attendue par votre backend pour traiter une réponse HTTP. Vous devez augmenter le délai avant expiration du service de backend si le logiciel exécuté sur votre backend a besoin de plus de temps pour traiter une requête HTTP et renvoyer sa réponse complète.

Le délai avant expiration du service de backend accepte des valeurs comprises entre 1 et 2,147,483,647 secondes. Cependant, les valeurs plus élevées ne sont pas des options pratiques de configuration. Google 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.

Pour les connexions WebSocket utilisées avec les équilibreurs de charge d'application internes, les connexions WebSocket actives ne suivent pas le délai avant expiration du service de backend. Les connexions WebSocket inactives sont fermées au terme du délai avant expiration du service de backend.

Google Cloud redémarre ou modifie périodiquement le nombre de tâches logicielles Envoy servies. Plus la valeur du délai avant expiration du service de backend est longue, plus il est probable que les tâches de redémarrage ou de remplacement d'Envoy interrompent les connexions TCP.

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

Console

Modifiez le champ Délai avant expiration du service de backend de l'équilibreur de charge.

gcloud

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

Délai d'expiration du message keepalive HTTP client

Le délai avant expiration du message keepalive HTTP du client représente la durée maximale pendant laquelle une connexion TCP peut être inactive entre le client (en aval) et un proxy Envoy. La valeur par défaut du délai avant expiration du message keepalive HTTP client est de 600 secondes. Vous pouvez configurer le délai avant expiration avec une valeur comprise entre 5 et 600 secondes.

Un délai avant expiration du message keepalive HTTP est également appelé délai d'inactivité TCP.

Le délai d'expiration du message keepalive HTTP client de l'équilibreur de charge doit être supérieur au délai d'expiration du message keepalive HTTP (TCP inactif) utilisé par les clients ou les proxys en aval. Si un client en aval possède un délai avant expiration du message keepalive HTTP (TCP inactif) supérieur à celui de l'équilibreur de charge, il est possible qu'une condition de concurrence se produise. Du point de vue d'un client en aval, une connexion TCP établie est autorisée à être inactive plus longtemps que l'équilibreur de charge ne le permet. Cela signifie que le client en aval peut envoyer des paquets après que l'équilibreur de charge considère la connexion TCP comme fermée. Dans ce cas, l'équilibreur de charge répond par un paquet de réinitialisation TCP (RST).

Délai avant expiration du message keepalive HTTP du backend

Les équilibreurs de charge d'application internes sont des proxys qui utilisent une première connexion TCP entre le client (en aval) et un proxy Envoy, et une deuxième connexion TCP entre le proxy Envoy et vos backends.

les connexions TCP secondaires de l'équilibreur de charge peuvent ne pas être fermées après chaque requête ; elles peuvent rester ouvertes pour gérer plusieurs requêtes et réponses HTTP. Le délai avant expiration du message keepalive HTTP du backend définit le délai d'inactivité TCP entre l'équilibreur de charge et vos backends. Le délai avant expiration du message keepalive HTTP du backend ne s'applique pas aux WebSocket.

Le délai avant expiration du message keepalive du backend est fixé à 10 minutes (600 secondes) et ne peut pas être modifié. Le délai d'expiration du message keepalive du backend de l'équilibreur de charge doit être inférieur au délai d'expiration du message keepalive utilisé par les logiciels exécutés sur vos backends. Cela évite une condition de concurrence où le système d'exploitation de vos backends peut fermer les connexions TCP avec une réinitialisation TCP (RST). Étant donné que le délai avant expiration du message keepalive du backend pour l'équilibreur de charge n'est pas configurable, vous devez configurer votre logiciel backend de sorte que sa valeur de délai d'expiration de message keepalive HTTP (TCP inactive) soit supérieure à 600 secondes.

Le tableau suivant répertorie les modifications à effectuer pour modifier les valeurs du délai d'expiration du message keepalive pour les logiciels de serveur Web courants.

Logiciel de serveur Web Paramètre Paramètre par défaut Réglage recommandé
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

Tentatives

Pour configurer les nouvelles tentatives, vous pouvez utiliser une stratégie de nouvelle tentative dans le mappage d'URL. Le nombre de tentatives par défaut (numRetries) est de 1. La valeur perTryTimeout maximale configurable est de 24 heures.

Sans stratégie de nouvelle tentative, les requêtes infructueuses sans corps HTTP (par exemple, des requêtes GET) qui aboutissent à des réponses HTTP 502, 503 ou 504 sont relancées. une 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'équilibreur de charge d'application interne.

Accès aux réseaux connectés

Vos clients peuvent accéder à un équilibreur de charge d'application 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 Équilibreurs de charge d'application internes et réseaux connectés.

Basculement

Si un backend n'est plus opérationnel, le trafic est automatiquement redirigé vers des backends opérationnels.

Le tableau suivant décrit le comportement de basculement dans chaque mode :

Mode d'équilibreur de charge Comportement de basculement Comportement lorsque tous les backends ne sont pas opérationnels
Équilibreur de charge d'application interne interrégional

Basculement automatique vers des backends opérationnels dans la même région ou dans d'autres régions

Le trafic est réparti entre les backends opérationnels dans plusieurs régions en fonction de la répartition du trafic configurée.

 Renvoie HTTP 503
Équilibreur de charge d'application interne régional

Basculement automatique vers des backends opérationnels dans la même région.

Le proxy Envoy envoie le trafic aux backends opérationnels dans une région en fonction de la répartition du trafic configurée.

 Renvoie HTTP 503

Haute disponibilité et basculement interrégional

Pour les équilibreurs de charge d'application internes régionaux :

Pour assurer une haute disponibilité, déployez plusieurs équilibreurs de charge d'application internes régionaux dans les régions qui prennent le mieux en charge le trafic de votre application. Vous utilisez ensuite une règle de routage de géolocalisation Cloud DNS pour détecter si un équilibreur de charge répond lors d'une panne régionale. Une règle de géolocalisation achemine le trafic vers la région disponible la plus proche en fonction de l'origine de la requête client. La vérification de l'état est disponible par défaut pour les équilibreurs de charge d'application internes.

Pour les équilibreurs de charge d'application internes interrégionaux

Vous pouvez configurer un équilibreur de charge d'application interne interrégional dans plusieurs régions pour bénéficier des avantages suivants :

  1. Si l'équilibreur de charge d'application interne interrégional d'une région échoue, les règles de routage DNS acheminent le trafic vers un équilibreur de charge d'application interne interrégional d'une autre région.

    L'exemple de déploiement haute disponibilité présente les éléments suivants :

    • Un équilibreur de charge d'application interne interrégional avec une adresse IP virtuelle (VIP) d'interface dans les régions RegionA et RegionB de votre réseau VPC. Vos clients sont situés dans la région RegionA.
    • Vous pouvez rendre l'équilibreur de charge accessible en utilisant des adresses IP virtuelles d'interface dans deux régions et utiliser des règles de routage DNS pour renvoyer l'adresse IP virtuelle optimale à vos clients. Utilisez les règles de routage de géolocalisation si vous souhaitez que vos clients utilisent l'adresse IP virtuelle la plus proche géographiquement.
    • Les règles de routage DNS peuvent détecter si une adresse IP virtuelle ne répond pas en cas de panne régionale et renvoyer à vos clients l'adresse IP virtuelle optimale, garantissant ainsi que votre application reste opérationnelle même en cas de panne régionale.
    Déploiement haute disponibilité de l'équilibreur de charge d'application interne interrégional
    Équilibreur de charge d'application interne interrégional avec un déploiement haute disponibilité (cliquez pour agrandir)

  2. Si les backends d'une région spécifique sont indisponibles, le trafic de l'équilibreur de charge d'application interne interrégional bascule vers les backends d'une autre région sans heurt.

    L'exemple de déploiement de basculement interrégional présente les éléments suivants :

    • Un équilibreur de charge d'application interne interrégional avec une adresse IP virtuelle d'interface dans la région RegionA de votre réseau VPC. Vos clients sont également situés dans la région RegionA.
    • Un service de backend global faisant référence aux backends des régions Google Cloud RegionA et RegionB.
    • Lorsque les backends de la région RegionA sont indisponibles, le trafic bascule vers la région RegionB.
    Équilibreur de charge d'application interne interrégional avec un déploiement de basculement interrégional
    Équilibreur de charge d'application interne interrégional avec un déploiement de basculement interrégional (cliquez pour agrandir).

Assistance WebSocket

Les équilibreurs de charge HTTP(S) de Google Cloud sont compatibles 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 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(S). 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 backend envoie une réponse 101 switching protocol avec des en-têtes Connection: Upgrade, Upgrade: websocket et d'autres en-têtes de réponse liés aux websockets.
  3. L'équilibreur de charge établit un trafic bidirectionnel par proxy pendant la durée de la connexion actuelle.

Si l'instance backend renvoie une réponse d'erreur avec le code de réponse 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 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 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 TLS mutuel, ou mTLS, est un protocole standard du secteur pour l'authentification mutuelle entre un client et un serveur. Il garantit 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 que la communication ne soit établie.

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 du gestionnaire de certificats 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.

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.

  • Les équilibreurs de charge d'application internes ne sont pas compatibles avec les fonctionnalités suivantes:

  • Un équilibreur de charge d'application interne n'accepte le protocole HTTP/2 que via TLS.

  • Les clients se connectant à un équilibreur de charge d'application 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 d'application interne doit avoir exactement un port.

  • Les équilibreurs de charge d'application internes ne sont pas compatibles avec Cloud Trace.

  • Lorsque vous utilisez un équilibreur de charge d'application interne avec Cloud Run dans un environnement VPC partagé, les réseaux VPC autonomes dans les projets de service peuvent envoyer du trafic vers tout autre service 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.

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

Étapes suivantes