L'équilibreur de charge réseau proxy interne de Google Cloud est basé sur un proxy et fourni par un logiciel proxy Envoy Open Source et par la pile de virtualisation de réseau Andromeda.
L'équilibreur de charge réseau proxy interne est un équilibreur de charge de couche 4 qui vous permet d'exécuter et d'effectuer le scaling de votre trafic de service TCP derrière une adresse IP interne régionale accessible uniquement aux clients situés dans le même réseau VPC ou aux clients connectés à votre réseau VPC. L'équilibreur de charge interrompt d'abord la connexion TCP entre le client et l'équilibreur de charge au niveau d'un proxy Envoy. Le proxy ouvre une deuxième connexion TCP aux backends hébergés dans Google Cloud, sur site ou dans d'autres environnements cloud. Pour plus de cas d'utilisation, consultez la page Présentation de l'équilibreur de charge réseau proxy.
Modes de fonctionnement
Vous pouvez configurer un équilibreur de charge réseau proxy interne dans les modes suivants :
Équilibreur de charge réseau proxy 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.
Équilibreur de charge réseau proxy 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.
Le tableau suivant décrit les principales différences entre les modes régional et interrégional :
Caractéristique Équilibreur de charge réseau proxy interne régional Équilibreur de charge réseau proxy interne interrégional Adresse IP virtuelle de l'équilibreur de charge. Allouée depuis un sous-réseau dans une région Google Cloud spécifique. 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.
Accès des clients Par défaut, non accessible mondialement.
Vous pouvez éventuellement activer l'accès mondial.Toujours accessible mondialement. Les clients de n'importe quelle région Google Cloud peuvent envoyer du trafic vers l'équilibreur de charge. Backends à équilibrage de charge 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.Backends globaux.
L'équilibreur de charge peut envoyer du trafic vers des backends dans n'importe quelle région.Haute disponibilité et basculement Basculement automatique vers des backends opérationnels dans la même région. Basculement automatique vers des backends opérationnels dans la même région ou dans des régions différentes.
Identifier le mode
Cloud Console
Dans Google Cloud Console, accédez à la page Équilibrage de charge.
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 réseau proxy interne régional Réseau (proxy) Interne Spécifie une région Équilibreur de charge réseau proxy interne interrégional Réseau (proxy) Interne
gcloud
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 réseau proxy interne régional INTERNAL_MANAGED Régional Équilibreur de charge réseau proxy interne interrégional INTERNAL_MANAGED Mondial
Architecture
Le schéma suivant présente les ressources Google Cloud requises pour les équilibreurs de charge réseau proxy internes.
Régional
Ce schéma montre les composants d'un déploiement d'équilibreur de charge réseau proxy interne régional au niveau Premium.
Interrégional
Ce schéma montre les composants d'un déploiement d'équilibreur de charge réseau proxy 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.
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 un équilibreur de charge réseau proxy interne basé sur Envoy.
Le tableau suivant décrit les exigences de sous-réseau proxy réservé pour les équilibreurs de charge réseau proxy internes:
Mode d'équilibreur de charge | Valeur de l'option --purpose du sous-réseau proxy réservé |
---|---|
Équilibreur de charge réseau proxy interne régional |
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é. |
Équilibreur de charge réseau proxy interne interrégional |
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é. |
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 instances de machine virtuelle (VM) de backend ou les points de terminaison de tous les équilibreurs de charge réseau proxy 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 réseau proxy 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.
Règles de transfert et adresses IP
Les règles de transfert permettent d'acheminer le trafic par adresse IP, port et protocole vers une configuration d'équilibrage de charge comprenant un proxy cible et un 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 TCP. Pour obtenir la liste complète des protocoles acceptés, consultez la page Comparaison des 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 que vous utilisez dans un équilibreur de charge réseau proxy interne 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.
Le tableau suivant présente les exigences concernant les règles de transfert pour les équilibreurs de charge réseau proxy internes:
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 réseau proxy interne régional |
Schéma d'équilibrage de charge :
Sous-réseau proxy réservé
Adresse IP
|
Vous pouvez activer l'accès mondial pour autoriser les clients de n'importe quelle région à accéder à votre équilibreur de charge. Les backends doivent également se trouver dans la même région que l'équilibreur de charge. |
Équilibreur de charge réseau proxy interne interrégional |
Schéma d'équilibrage de charge :
Sous-réseau proxy réservé
Adresse IP
|
L'accès mondial est activé par défaut pour permettre aux clients de n'importe quelle région d'accéder à votre équilibreur de charge. Les backends peuvent se trouver dans plusieurs régions. |
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 réseau proxy interne interrégional Équilibreur de charge réseau proxy 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 cibles
L'équilibreur de charge réseau proxy interne met fin aux connexions TCP du client et crée des connexions vers les backends. Par défaut, l'adresse IP et les informations de port d'origine du client ne sont pas conservées. Vous pouvez conserver ces informations à l'aide du protocole de PROXY. Le proxy cible achemine les requêtes entrantes directement vers le service de backend de l'équilibreur de charge.
Le tableau suivant présente les API de proxy cibles requises par les équilibreurs de charge réseau proxy internes:
Mode d'équilibreur de charge | Proxy cible |
---|---|
Équilibreur de charge réseau proxy interne régional | Régional regionTargetTcpProxies |
Équilibreur de charge réseau proxy interne interrégional | Global targetTcpProxies |
Service de backend
Un service de backend dirige le trafic entrant vers un ou plusieurs backends associés. Un backend est soit un groupe d'instances, soit un groupe de points de terminaison du réseau. Le backend contient des informations sur le mode d'équilibrage permettant de définir l'utilisation maximale en fonction des connexions (ou, pour les backends de groupe d'instances uniquement, de l'utilisation).
Chaque équilibreur de charge réseau proxy interne possède une seule ressource de service de backend.
Le tableau suivant spécifie les exigences de service de backend pour les équilibreurs de charge réseau proxy internes:
Mode d'équilibreur de charge | Type de service de backend |
---|---|
Équilibreur de charge réseau proxy interne régional | Régional regionBackendServices |
Équilibreur de charge réseau proxy interne interrégional | Global backendServices |
Backends compatibles
Le service de backend accepte les types de backends suivants :
Mode d'équilibreur de charge | Backends compatibles sur un service de backend | ||||||
---|---|---|---|---|---|---|---|
Groupes d'instances | NEG zonaux | NEG Internet | NEG sans serveur | NEG hybrides | NEG Private Service Connect | GKE | |
Équilibreur de charge réseau proxy interne régional |
Points de terminaison pour le type GCE_VM_IP_PORT |
NEG régionaux uniquement | Ajouter un NEG Private Service Connect | ||||
Équilibreur de charge réseau proxy interne interrégional |
Points de terminaison pour le type GCE_VM_IP_PORT |
Ajouter un NEG Private Service Connect |
Tous les backends doivent être du même type (groupes d'instances ou NEG). Vous pouvez utiliser simultanément différents types de backends de groupe d'instances ou utiliser différents types de backends NEG, mais vous ne pouvez pas utiliser des backends de groupe d'instances et de NEG ensemble sur le même service de backend.
Vous pouvez combiner des NEG zonaux et des NEG hybrides au sein du même service de backend.
Vous pouvez activer le drainage de connexion sur les services de backend afin de garantir à vos utilisateurs un temps d'interruption minimal. De telles interruptions peuvent se produire lorsqu'un backend est arrêté, supprimé manuellement ou supprimé par un autoscaler. Pour en savoir plus sur la manière dont vous pouvez utiliser le drainage de connexion pour minimiser les interruptions de service, consultez la page Activer le drainage de connexion.
Backends et réseaux VPC
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.
Protocole de communication avec les backends
Lorsque vous configurez un service de backend pour un équilibreur de charge réseau proxy interne, vous définissez le protocole utilisé par le service de backend pour communiquer avec les backends. L'équilibreur de charge n'utilise que le protocole spécifié et n'essaie pas de négocier une connexion à l'aide de l'autre protocole. Les équilibreurs de charge réseau proxy internes n'acceptent que TCP pour la communication avec les backends.
Vérification de l'é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.
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 TCP teste plus précisément la connectivité TCP aux backends. 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 réseau proxy internes dans chaque mode :
Mode d'équilibreur de charge | Type de vérification d'état |
---|---|
Équilibreur de charge réseau proxy interne régional | Régional regionHealthChecks |
Équilibreur de charge réseau proxy interne interrégional | Global healthChecks |
Pour en savoir plus sur les vérifications d'état, consultez les pages suivantes :
Règles de pare-feu
Les équilibreurs de charge réseau proxy internes nécessitent les règles de pare-feu suivantes :
- Une règle d'autorisation d'entrée qui autorise le trafic provenant des vérifications d'état de Google.
35.191.0.0/16
130.211.0.0/22
2600:2d00:1:b029::/64
- Une règle d'autorisation d'entrée qui autorise le trafic provenant du sous-réseau proxy réservé
Les ports de ces règles de pare-feu doivent être configurés comme suit :
Autorisez le trafic vers le port de destination pour la vérification d'état de chaque service de backend.
Pour les backends de groupe d'instances : déterminez les ports à configurer par le mappage entre le port nommé du service de backend et les numéros de port associés à ce port nommé sur chaque groupe d'instances. Les numéros de port peuvent varier entre les groupes d'instances attribués au même service de backend.
Pour les backends de NEG
GCE_VM_IP_PORT
: autorisez le trafic vers les numéros de port des points de terminaison.
Il existe certaines exceptions aux exigences des règles de pare-feu pour ces équilibreurs de charge :
- 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 réseau proxy 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 mondial pour autoriser les clients de n'importe quelle région à accéder à votre équilibreur de charge.
Pour les équilibreurs de charge réseau proxy internes interrégionaux, l'accès mondial est activé par défaut. Les clients de n'importe quelle région peuvent accéder à votre équilibreur de charge.
Le tableau suivant récapitule l'accès client pour les équilibreurs de charge réseau proxy 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. |
Architecture du VPC partagé
L'équilibreur de charge réseau proxy interne est compatible avec les réseaux qui utilisent un VPC partagé. Les réseaux VPC partagés vous permettent de séparer clairement les responsabilités entre les administrateurs réseau et les développeurs de services. Vos équipes de développement peuvent se concentrer sur la création de services dans des projets de service, tandis que les équipes d'infrastructure réseau peuvent provisionner et administrer l'équilibrage de charge. Si vous n'êtes pas familiarisé avec le VPC partagé, consultez la présentation du VPC partagé.
Adresse IP | Règle de transfert | Proxy cible | Composants backend |
---|---|---|---|
Une adresse IP interne doit être définie dans le même projet que les backends. Pour que l'équilibreur de charge soit disponible dans un réseau VPC partagé, l'adresse IP interne doit être définie dans le même projet de service que les VM de backend et doit faire référence à un sous-réseau du 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é. |
Une règle de transfert interne doit être définie dans le même projet que les backends. Pour que l'équilibreur de charge soit disponible dans un réseau VPC partagé, la règle de transfert interne doit être définie dans le même projet de service que les VM de backend et doit faire référence au même sous-réseau (dans le réseau VPC partagé) que celui auquel l'adresse IP interne associée fait référence. |
Le proxy cible doit être défini dans le même projet que les backends. | Dans un scénario de VPC partagé, les VM de backend sont généralement situées dans un projet de service. Un service de backend interne régional et une vérification d'état doivent être définis dans ce projet de service. |
Distribution du trafic
Un équilibreur de charge réseau proxy interne distribue le trafic vers ses backends comme suit :
- Les connexions provenant d'un seul client sont envoyées à la même zone tant que des backends (groupes d'instances ou NEG) opérationnels dans cette zone sont disponibles et ont une capacité déterminée par le mode d'équilibrage.
Pour les équilibreurs de charge réseau proxy internes régionaux, le mode d'équilibrage peut être
CONNECTION
(backends de groupes d'instances ou de NEG) ouUTILIZATION
(backends de groupes d'instances seulement). - Les connexions d'un client sont envoyées au même backend si vous avez configuré l'affinité de session.
- Une fois le backend sélectionné, le trafic est réparti entre des instances (dans un groupe d'instances) ou des points de terminaison (dans un NEG), en fonction d'une règle d'équilibrage de charge. Pour en savoir plus sur les algorithmes de règle d'équilibrage de charge compatibles, consultez le paramètre
localityLbPolicy
dans la documentation de l'API sur le service de backend régional.
Affinité de session
L'affinité de session vous permet de configurer le service de backend de l'équilibreur de charge pour envoyer toutes les requêtes d'un même client au même backend, à condition que le backend soit opérationnel et dispose de la capacité requise.
L'équilibreur de charge réseau proxy interne offre une affinité basée sur les adresses IP client, qui permet de transmettre toutes les requêtes provenant d'une même adresse IP client au même backend, à condition que ce backend dispose d'une capacité suffisante et reste opérationnel.
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 des équilibreurs de charge réseau proxy internes:
Mode d'équilibreur de charge | Comportement de basculement | Comportement lorsque tous les backends ne sont pas opérationnels |
---|---|---|
Équilibreur de charge réseau proxy interne régional | L'équilibreur de charge implémente un algorithme de basculement souple par zone. Plutôt que d'attendre que tous les backends d'une zone deviennent non opérationnels, l'équilibreur de charge commence à rediriger le trafic vers une zone différente lorsque le ratio entre les backends opérationnels et non opérationnels dans une zone est inférieur à un certain seuil. (70 % ; ce seuil n'est pas configurable). Si aucun des backends de toutes les zones n'est opérationnel, l'équilibreur de charge met immédiatement fin à la connexion du client. Le proxy Envoy envoie le trafic aux backends opérationnels dans une région en fonction de la répartition du trafic configurée. |
Désactivation de la connexion |
Équilibreur de charge réseau proxy 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. |
Désactivation de la connexion |
Équilibrage de charge pour les applications GKE
Si vous créez des applications dans Google Kubernetes Engine, vous pouvez utiliser des NEG zonaux autonomes pour équilibrer la charge du trafic directement vers les conteneurs. Avec les NEG autonomes, vous devez créer l'objet Service qui crée le NEG, puis associer le NEG au service de backend afin que l'équilibreur de charge puisse se connecter aux pods.
Documentation GKE associée :
Quotas et limites
Pour en savoir plus sur les quotas et les limites, consultez la page Quotas et limites des ressources d'équilibrage de charge.
Limites
- L'équilibreur de charge réseau proxy interne ne prend pas en charge le trafic IPv6.
- L'équilibreur de charge réseau proxy interne n'est pas compatible avec les déploiements de VPC partagé pour lesquels l'interface de l'équilibreur de charge se trouve dans un projet hôte ou de service, ou le service de backend et les backends se trouvent dans un autre projet de service (également appelé référencement de services inter-projets).
Étape suivante
Configurez un équilibreur de charge réseau proxy interne régional avec un backend de NEG zonal
Configurez un équilibreur de charge réseau proxy interne régional avec un backend de NEG hybride
Configurer un équilibreur de charge réseau proxy interne régional avec un backend de NEG Internet