Présentation de l'équilibreur de charge réseau proxy externe

Ce document présente les concepts que vous devez maîtriser pour configurer un équilibreur de charge réseau proxy externe Trusted Cloud .

L'équilibreur de charge réseau proxy externe est un équilibreur de charge de proxy inverse qui distribue le trafic TCP provenant d'Internet aux instances de machines virtuelles (VM) de votre réseauTrusted Cloud cloud privé virtuel (VPC). Lorsque vous utilisez un équilibreur de charge réseau proxy externe, le trafic TCPentrant est interrompu au niveau de l'équilibreur de charge. Une nouvelle connexion transfère ensuite le trafic vers le backend disponible le plus proche.

Les équilibreurs de charge réseau proxy externes vous permettent d'utiliser une adresse IP unique pour vos utilisateurs du monde entier. L'équilibreur de charge achemine automatiquement le trafic vers les backends les plus proches de l'utilisateur.

Cet équilibreur de charge est disponible en mode régional. Il est désigné ci-après par le terme "équilibreur de charge réseau proxy externe régional". L'équilibreur de charge est mis en œuvre en tant que service géré basé sur le proxy Envoy Open Source. Le mode régional garantit que tous les clients et backends se trouvent dans une région spécifiée. Utilisez cet équilibreur de charge si vous souhaitez diffuser du contenu à partir d'une seule géolocalisation (par exemple, pour respecter les réglementations de conformité).

Architecture

Les schémas suivants montrent les composants des équilibreurs de charge réseau proxy externes.

Régional

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

Composants de l'équilibreur de charge réseau proxy externe régional.
Composants de l'équilibreur de charge réseau proxy externe régional (cliquez pour agrandir).

Les éléments présentés ci-dessous sont les composants des équilibreurs de charge réseau proxy externes.

Sous-réseau proxy réservé

Le sous-réseau proxy réservé fournit un ensemble d'adresses IP utilisées par Google pour exécuter des proxys Envoy en votre nom. Vous devez créer un sous-réseau proxy réservé dans chaque région d'un réseau VPC dans laquelle vous utilisez des équilibreurs de charge. L'option --purpose pour ce sous-réseau proxy réservé est définie sur REGIONAL_MANAGED_PROXY. Tous les équilibreurs de charge régionaux basés sur Envoy situés dans la même région et sur le même réseau VPC partagent un pool de proxys Envoy du même sous-réseau proxy réservé.

Les VM de backend ou les points de terminaison de tous les équilibreurs de charge situés dans une région et sur un réseau VPC reçoivent les connexions du sous-réseau proxy réservé.

Points à retenir :

  • Les sous-réseaux proxy réservés ne sont utilisés que pour les proxys Envoy, et non pour vos backends.
  • L'adresse IP de l'équilibreur de charge n'est pas située dans le sous-réseau proxy réservé. L'adresse IP de l'équilibreur de charge est définie par sa règle de transfert gérée en externe.

Règles de transfert et adresses 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 que vous pouvez utiliser, soit laisser Cloud Load Balancing en attribuer une pour vous. 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.

Spécification du port Les règles de transfert externes utilisées dans la définition de cet équilibreur de charge peuvent faire référence à un seul port de la plage 1-65535. Si vous souhaitez accepter plusieurs ports consécutifs, vous devez configurer plusieurs règles de transfert. Plusieurs règles de transfert peuvent être configurées avec la même adresse IP virtuelle et différents ports. Par conséquent, vous pouvez relayer plusieurs applications par proxy avec des ports personnalisés distincts vers la même adresse IP virtuelle du proxy TCP. Pour plus d'informations, consultez la section Spécifications de ports pour les règles de transfert.

Pour accepter plusieurs ports consécutifs, vous devez configurer plusieurs règles de transfert. Celles-ci peuvent être configurées avec la même adresse IP virtuelle et des ports différents. Par conséquent, vous pouvez relayer plusieurs applications par proxy avec des ports personnalisés distincts vers la même adresse IP virtuelle du proxy TCP.

Le tableau suivant présente les exigences concernant les règles de transfert pour les équilibreurs de charge réseau proxy externes.

Mode d'équilibreur de charge Network Service Tier Règle de transfert, adresse IP et schéma d'équilibrage de charge Routage depuis Internet vers l'interface de l'équilibreur de charge
Équilibreur de charge réseau proxy externe régional Niveau Premium

Règle de transfert externe régionale

Adresse IP externe régionale

Schéma d'équilibrage de charge : EXTERNAL_MANAGED

 Requêtes acheminées vers les proxys Envoy situés 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 réseau proxy externe régional

Le réseau VPC de la règle de transfert est celui dans lequel le sous-réseau proxy réservé a été créé. Vous spécifiez le réseau lorsque vous créez la règle de transfert.

Proxy cibles

Les équilibreurs de charge réseau proxy externes mettent fin aux connexions du client et créent de nouvelles connexions vers les backends. Le proxy cible achemine ces nouvelles connexions vers le service de backend.

Par défaut, le proxy cible ne conserve ni l'adresse IP ni les informations de port d'origine du client. Vous pouvez conserver ces informations en activant le protocole de PROXY sur le proxy cible.

Le tableau suivant présente les exigences relatives aux proxys cibles pour les équilibreurs de charge réseau proxy externes.

Mode d'équilibreur de charge Network Service Tier Proxy cible
Équilibreur de charge réseau proxy externe régional Niveau Premium et Standard regionTargetTcpProxies

Services de backend

Les services de backend dirigent le trafic entrant vers un ou plusieurs backends associés. Chaque backend est composé d'un groupe d'instances ou d'un groupe de points de terminaison du réseau, ainsi que d'informations sur la capacité de diffusion du backend. La capacité de diffusion du backend peut être basée sur l'utilisation du processeur ou sur le nombre de requêtes par seconde (RPS).

Chaque équilibreur de charge possède une seule ressource de service de backend qui spécifie la vérification de l'état à effectuer sur les backends disponibles.

Les modifications apportées au service de backend ne sont pas instantanées. La propagation des modifications sur les GFE peut prendre plusieurs minutes. 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.

Pour plus d'informations sur la ressource du service de backend, voir Présentation des services de backend.

Le tableau suivant spécifie les différents backends compatibles avec le service de backend des équilibreurs de charge réseau proxy externes.

Mode d'équilibreur de charge Backends compatibles sur un service de backend
Groupes d'instances NEG zonaux NEG Internet NEG sans serveur NEG hybrides GKE
Équilibreur de charge réseau proxy externe régional Points de terminaison de type GCE_VM_IP_PORT NEG régionaux uniquement

Backends et réseaux VPC

Pour les backends d'équilibreur de charge réseau proxy externe régional :

  • Pour les groupes d'instances, les NEG zonaux et les NEG de connectivité hybride, tous les backends doivent être situés dans le même projet et la même région que le service de backend. Toutefois, un équilibreur de charge peut référencer un backend qui utilise un autre réseau VPC dans le même projet que le service de backend. La connectivité entre le réseau VPC de l'équilibreur de charge et le réseau VPC du backend peut être configurée à l'aide de l'appairage de réseaux VPC, de tunnels Cloud VPN ou de rattachements de VLAN Cloud Interconnect.

    Définition du réseau de backend

    • Pour les NEG zonaux et hybrides, vous spécifiez explicitement le réseau VPC lorsque vous créez le NEG.
    • Pour les groupes d'instances gérés, le réseau VPC est défini dans le modèle d'instance.
    • Pour les groupes d'instances non gérés, le réseau VPC du groupe d'instances est défini pour correspondre au réseau VPC de l'interface nic0 de la première VM ajoutée au groupe d'instances.

    Exigences du réseau de backend

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

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

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

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

Backends et interfaces réseau

Si vous utilisez des backends de groupe d'instances, les paquets sont toujours distribués à nic0. Si vous souhaitez envoyer des paquets à des interfaces non nic0 (vNIC ou interfaces réseau dynamiques), utilisez plutôt des backends de NEG.

Si vous utilisez des backends de NEG zonaux, les paquets sont envoyés à l'interface réseau représentée par le point de terminaison dans le NEG. Les points de terminaison du NEG doivent se trouver dans le même réseau VPC que le réseau VPC défini explicitement pour le NEG.

Protocole de communication avec les backends

Lorsque vous configurez un service de backend pour un équilibreur de charge réseau proxy externe, 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 externes n'acceptent que TCP pour la communication avec les backends.

Règles de pare-feu

Les règles de pare-feu suivantes sont requises :

  • Pour les équilibreurs de charge réseau proxy externes régionaux, une règle de pare-feu d'entrée pour autoriser le trafic provenant du sous-réseau proxy réservé à accéder à vos backends.

  • Une règle de pare-feu qui autorise le trafic entrant (allow), pour permettre au trafic provenant des plages de vérification d'état d'atteindre vos backends. Pour plus d'informations sur les vérifications d'état et découvrir pourquoi il est nécessaire d'autoriser le trafic qui en provient, consultez Plages d'adresses IP de vérification et règles de pare-feu.

Les règles de pare-feu sont mises en œuvre au niveau de l'instance de VM, et non au niveau des proxys GFE. Vous ne pouvez pas utiliser les règles de pare-feu pour empêcher le trafic d'atteindre l'équilibreur de charge.

Les ports de ces règles de pare-feu doivent être configurés comme suit :

  • Autorisez le trafic vers le port de destination pour la vérification d'état de chaque service de backend.
  • Pour les backends de groupe d'instances : déterminez les ports à configurer par le mappage entre le port nommé du service de backend et les numéros de port associés à ce port nommé sur chaque groupe d'instances. Les numéros de port peuvent varier entre les groupes d'instances attribués au même service de backend.
  • Pour les backends de NEG zonaux GCE_VM_IP_PORT NEG : autorisez le trafic vers les numéros de port des points de terminaison.

Adresses IP sources

Les adresses IP sources des paquets, telles qu'elles sont perçues par les backends, ne correspondent pas à l'adresse IP externeTrusted Cloud de l'équilibreur de charge. En d'autres termes, il existe deux connexions TCP :

Pour les équilibreurs de charge réseau proxy externes régionaux :

  • Connexion 1, du client d'origine vers l'équilibreur de charge (sous-réseau proxy réservé) :

    • Adresse IP source : le client d'origine (ou l'adresse IP externe si le client est protégé par une passerelle NAT ou un proxy de transfert).
    • Adresse IP de destination : adresse IP de votre équilibreur de charge.

  • Connexion 2, de l'équilibreur de charge (sous-réseau proxy réservé) vers la VM de backend ou le point de terminaison :

    • Adresse IP source : adresse IP du sous-réseau proxy réservé partagée entre tous les équilibreurs de charge basés sur Envoy déployés dans la même région et sur le même réseau que l'équilibreur de charge.

    • Adresse IP de destination : adresse IP interne de la VM de backend ou du conteneur dans le réseau VPC.

Ports ouverts

Les équilibreurs de charge réseau proxy externes sont des équilibreurs de charge de type "proxy inverse". L'équilibreur de charge interrompt les connexions entrantes, puis ouvre de nouvelles connexions entre lui-même et les backends. Ces équilibreurs de charge sont mis en œuvre à l'aide de proxys Google Front End (GFE) dans le monde entier.

Les GFE offrent plusieurs ports ouverts pour les autres services Google exécutés sur la même architecture. Lorsque vous exécutez une analyse de port, d'autres ports ouverts peuvent s'afficher pour d'autres services Google s'exécutant sur des GFE.

L'exécution d'une analyse de port sur l'adresse IP d'un équilibreur de charge basé sur GFE n'est pas utile du point de vue de l'audit pour les raisons suivantes :

  • Une analyse de port (par exemple, avec nmap) n'attend généralement pas de paquet de réponse ni de paquet TCP RST lors de l'exécution de la vérification TCP SYN. Les GFE n'envoient des paquets SYN-ACK en réponse aux vérifications SYN que pour les ports sur lesquels vous avez configuré une règle de transfert. Les GFE n'envoient des paquets à vos backends qu'en réponse aux paquets envoyés à l'adresse IP de votre équilibreur de charge et au port de destination configuré sur sa règle de transfert. Les paquets envoyés à une adresse IP ou à un port différents ne sont pas envoyés à vos backends.

    Les GFE mettent en œuvre des fonctionnalités de sécurité telles que Google Cloud Armor. Avec Cloud Armor Standard, les GFE offrent une protection permanente contre les attaques DDoS volumétriques et basées sur un protocole, et les inondations SYN. Cette protection est disponible même si vous n'avez pas explicitement configuré Cloud Armor. Vous ne serez facturé que si vous configurez des règles de sécurité ou si vous vous inscrivez au niveau Managed Protection Plus.

  • Les paquets envoyés à l'adresse IP de votre équilibreur de charge peuvent recevoir une réponse de n'importe quel GFE du parc de Google. Cependant, l'analyse d'une combinaison d'adresse IP et de port de destination d'un équilibreur de charge n'interroge qu'un seul GFE par connexion TCP. L'adresse IP de votre équilibreur de charge n'est pas attribuée à un seul appareil ou système. Ainsi, l'analyse de l'adresse IP d'un équilibreur de charge basé sur un GFE n'analyse pas tous les GFE du parc de Google.

En gardant cela à l'esprit, voici quelques moyens plus efficaces d'auditer la sécurité de vos instances backend :

  • Un auditeur de sécurité doit inspecter la configuration des règles de transfert pour la configuration de l'équilibreur de charge. Les règles de transfert définissent le port de destination pour lequel votre équilibreur de charge accepte les paquets et les transfère aux backends. Pour les équilibreurs de charge basés sur GFE, chaque règle de transfert externe ne peut référencer qu'un seul port TCP de destination.

  • Un auditeur de sécurité doit inspecter la configuration des règles de pare-feu applicable aux VM de backend. Les règles de pare-feu que vous définissez bloquent le trafic entre les GFE et les VM de backends, mais elles ne bloquent pas le trafic entrant vers les GFE. Pour connaître les bonnes pratiques, consultez la section Règles de pare-feu.

Architecture du VPC partagé

Les équilibreurs de charge réseau proxy externes régionaux sont compatibles avec les déploiements qui utilisent des réseaux VPC partagés. 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 externe doit être définie dans le même projet que l'équilibreur de charge. La règle de transfert externe doit être définie dans le même projet que les instances backend (le projet de service). Le proxy TCP cible doit être défini dans le même projet que les instances backend.

Pour les équilibreurs de charge réseau externes proxy régionaux, 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.

Répartition du trafic

Lorsque vous ajoutez un groupe d'instances backend ou un NEG à un service de backend, vous spécifiez un mode d'équilibrage de charge, qui définit une méthode permettant de mesurer la charge du backend et la capacité cible.

Pour les équilibreurs de charge réseau proxy externes, le mode d'équilibrage peut être CONNECTION ou UTILIZATION:

  • Si le mode d'équilibrage de charge est CONNECTION, la charge est répartie en fonction du nombre total de connexions que le backend peut gérer.
  • Si le mode d'équilibrage de charge est UTILIZATION, la charge est répartie en fonction de l'utilisation des instances dans un groupe d'instances. Ce mode d'équilibrage ne s'applique qu'aux backends de groupes d'instances de VM.

La répartition du trafic entre les backends est déterminée par le mode d'équilibrage de l'équilibreur de charge.

Équilibreur de charge réseau proxy externe régional

Pour les équilibreurs de charge réseau proxy externes régionaux, la répartition du trafic est basée sur le mode d'équilibrage de charge et sur la règle d'équilibrage de charge de la localité.

Le mode d'équilibrage détermine la pondération et la fraction de trafic à envoyer à chaque backend (groupe d'instances ou NEG). La règle de localité d'équilibrage de charge (LocalityLbPolicy) détermine la manière dont les backends du groupe sont équilibrés.

Lorsqu'un service de backend reçoit du trafic, il dirige tout d'abord le trafic vers un backend (groupe d'instances ou NEG) en fonction de son mode d'équilibrage. Ensuite, une fois le backend sélectionné, le trafic est réparti entre les instances ou les points de terminaison de ce groupe de backend conformément à la règle de localité d'équilibrage de charge.

Pour en savoir plus, consultez les ressources suivantes :

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.

Les équilibreurs de charge réseau proxy externes offrent les types d'affinité de session suivants :

  • None

    Un paramètre d'affinité de session de NONE ne signifie pas qu'il n'y a pas d'affinité de session. Cela signifie qu'aucune option d'affinité de session n'est explicitement configurée.

    Le hachage est toujours effectué pour sélectionner un backend. Un paramètre d'affinité de session NONE signifie que l'équilibreur de charge utilise un hachage à cinq tuples pour sélectionner un backend. Le hachage à cinq tuples est constitué de l'adresse IP source, du port source, du protocole, de l'adresse IP de destination et du port de destination.

    La valeur par défaut de l'affinité de session est NONE.

  • Affinité basée sur les adresses IP client

    L'affinité de session Adresse IP client (CLIENT_IP) est un hachage à deux tuples créé à partir des adresses IP source et de destination du paquet. L'affinité basée sur les adresses IP client 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.

    Lorsque vous utilisez l'affinité basée sur les adresses IP client, gardez à l'esprit les points suivants :

    • L'adresse IP de destination du paquet n'est identique à l'adresse IP de la règle de transfert de l'équilibreur de charge que si le paquet est envoyé directement à l'équilibreur de charge.
    • L'adresse IP source du paquet peut ne pas correspondre à une adresse IP associée au client d'origine si le paquet est traité par un système NAT ou proxy intermédiaire avant d'être distribué à un équilibreur de charge Trusted Cloud . Dans les situations où de nombreux clients partagent la même adresse IP source effective, certaines VM de backend peuvent recevoir plus de connexions ou de requêtes que d'autres.

Gardez à l'esprit les éléments suivants lors de la configuration de l'affinité de session :

  • Ne comptez pas sur l'affinité de session pour l'authentification ou la sécurité. L'affinité de session peut se rompre chaque fois que le nombre de backends actifs et opérationnels change. Pour en savoir plus, consultez la section Perte d'affinité de session.

  • Les valeurs par défaut des options --session-affinity et --subsetting-policy sont NONE, et une seule d'entre elles peut être définie sur une valeur différente.

Perte d'affinité de session

Toutes les options d'affinité de session nécessitent les éléments suivants :

  • L'instance ou le point de terminaison de backend sélectionnés doivent rester configurés en tant que backend. L'affinité de session peut être rompue lorsque l'un des événements suivants se produit :
    • Vous supprimez l'instance sélectionnée de son groupe d'instances.
    • L'autoscaling ou l'autoréparation d'un groupe d'instances géré supprime l'instance sélectionnée de son groupe d'instances géré.
    • Vous supprimez le point de terminaison sélectionné de son NEG.
    • Vous supprimez du service de backend le groupe d'instances ou le NEG contenant l'instance ou le point de terminaison sélectionnés.
  • L'instance ou le point de terminaison de backend sélectionnés doivent rester opérationnels. L'affinité de session peut cesser lorsque l'instance ou le point de terminaison sélectionnés échouent aux vérifications de l'état.
  • Pour les équilibreurs de charge réseau proxy externes globaux et les équilibreurs de charge réseau proxy classiques, l'affinité de session peut être rompue si un autre Google Front End (GFE) de première couche est utilisé pour les requêtes ou connexions ultérieures après la modification du chemin de routage. Un autre GFE de première couche peut être sélectionné si le chemin de routage d'un client sur Internet vers Google change entre les requêtes ou les connexions.
Toutes les options d'affinité de session sont soumises aux exigences supplémentaires suivantes :

  • Le groupe d'instances ou le NEG contenant l'instance ou le point de terminaison sélectionné ne doit pas être complet, comme défini par sa capacité cible. (Pour les groupes d'instances gérés régionaux, le composant zonal du groupe d'instances contenant l'instance sélectionnée ne doit pas être complet.) L'affinité de session peut être interrompue lorsque le groupe d'instances ou le NEG est plein et que d'autres groupes d'instances ou NEG ne le sont pas. Étant donné que la capacité peut changer de manière imprévisible lorsque vous utilisez le mode d'équilibrage UTILIZATION, vous devez utiliser le mode d'équilibrage RATE ou CONNECTION pour minimiser les situations où l'affinité de session peut être rompue.

  • Le nombre total d'instances ou de points de terminaison de backend configurés doit rester constant. Lorsque l'un des événements suivants se produit, le nombre d'instances ou de points de terminaison de backend configurés change, et l'affinité de session peut être interrompue :

    • Ajouter des instances ou des points de terminaison :

      • Vous ajoutez des instances à un groupe d'instances existant sur le service de backend.
      • L'autoscaling de groupe d'instances géré ajoute des instances à un groupe d'instances géré sur le service de backend.
      • Vous ajoutez des points de terminaison à un NEG existant sur le service de backend.
      • Vous ajoutez des groupes d'instances ou des NEG non vides au service de backend.

    • Supprimer une instance ou un point de terminaison (pas seulement l'instance ou le point de terminaison sélectionné) :

      • Vous supprimez une instance d'un backend de groupe d'instances.
      • L'autoscaling ou l'autoréparation d'un groupe d'instances géré supprime toute instance d'un backend de groupe d'instances géré.
      • Vous supprimez un point de terminaison d'un backend NEG.
      • Supprimez tout groupe d'instances ou NEG backend existant et non vide du service de backend.

  • Le nombre total d'instances ou de points de terminaison de backend opérationnels doit rester constant. Lorsque l'un des événements suivants se produit, le nombre d'instances ou de points de terminaison de backend opérationnels change, et l'affinité de session peut être rompue :

    • Une instance ou un point de terminaison réussit sa vérification de l'état l'état et passe de l'état "Non opérationnel" à l'état "Opérationnel".
    • Une instance ou un point de terminaison échoue à la vérification de l'état de l'état et passe de l'état "opérationnel" à l'état "non opérationnel" ou "délai avant expiration".

Basculement

Le basculement pour les équilibreurs de charge réseau proxy externes fonctionne comme suit :

  • 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 abandonne le trafic.

Équilibrage de charge pour les applications GKE

Si vous créez des applications dans Google Kubernetes Engine, vous pouvez utiliser des NEG 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.

Pour en savoir plus, consultez la section Équilibrage de charge natif en conteneurs via des NEG zonaux autonomes.

Limites

  • Vous ne pouvez pas créer d'équilibreur de charge réseau proxy externe régional au niveau Premium à l'aide de la consoleTrusted Cloud . Utilisez plutôt l'gcloud CLI ou l'API.

  • Trusted Cloud ne fournit aucune garantie sur la durée de vie des connexions TCP lorsque vous utilisez des équilibreurs de charge réseau proxy externes. Les clients doivent être résilients aux connexions interrompues, à la fois en raison de problèmes Internet plus généraux et en raison des redémarrages réguliers des proxys gérant les connexions.

Étapes suivantes