À propos des services LoadBalancer

Cette page offre un aperçu général de la manière dont Google Kubernetes Engine (GKE) crée et gère les équilibreurs de charge Trusted Cloud by S3NS lorsque vous appliquez un fichier manifeste des services LoadBalancer Kubernetes. Il décrit les types de LoadBalancer, les paramètres de configuration et fournit des recommandations de bonnes pratiques.

Avant de lire cette page, assurez-vous de connaître les concepts de la mise en réseau GKE.

Présentation

Lorsque vous créez un service LoadBalancer, GKE configure un Trusted Cloud équilibreur de charge direct dont les caractéristiques dépendent des paramètres de votre fichier manifeste du service.

Personnaliser votre service LoadBalancer

Lorsque vous choisissez la configuration du service LoadBalancer à utiliser, tenez compte des aspects suivants :

• Type d'équilibreur de charge : interne ou externe
• Règle de trafic externe
• Équilibrage de charge pondéré
• Affinité zonale

Type d'équilibreur de charge : interne ou externe

Lorsque vous créez un service LoadBalancer dans GKE, vous spécifiez si l'équilibreur de charge possède une adresse interne ou externe :

• Les services LoadBalancer externes sont mis en œuvre à l'aide d'équilibreurs de charge réseau passthrough externes. Les clients situés en dehors de votre réseau VPC et les VM disposant d'un accès à Internet peuvent accéder à un service LoadBalancer externe. Trusted Cloud

  Lorsque vous créez un service LoadBalancer sans spécifier de paramètres personnalisés, cette configuration est appliquée par défaut.

  Il est recommandé d'inclure l'annotation cloud.google.com/l4-rbs: "enabled" dans le fichier manifeste du service lorsque vous créez un service LoadBalancer externe. L'inclusion de cette annotation dans le fichier manifeste du service crée un équilibreur de charge réseau passthrough externe basé sur un service de backend.

  Les fichiers manifestes de service LoadBalancer qui omettent l'annotation cloud.google.com/l4-rbs: "enabled" créent un équilibreur de charge réseau passthrough externe basé sur un pool cible. L'utilisation d'équilibreurs de charge réseau passthrough externes basés sur un pool cible n'est plus recommandée.

• Les services LoadBalancer internes sont mis en œuvre à l'aide d'équilibreurs de charge réseau passthrough internes. Les clients situés sur le même réseau VPC ou sur un réseau connecté au réseau VPC du cluster peuvent accéder à un service LoadBalancer interne.

  Pour créer un service LoadBalancer interne :

  • Nous vous recommandons d'activer le sous-paramètre GKE afin que GKE puisse regrouper efficacement les nœuds à l'aide de groupes de points de terminaison du réseau (NEG) GCE_VM_IP. Le sous-paramètre GKE n'est pas obligatoire, mais il est fortement recommandé.

  • Incluez l'annotation networking.gke.io/load-balancer-type: "Internal" dans le fichier manifeste du service.

Effet sur externalTrafficPolicy

Le paramètre externalTrafficPolicy contrôle les éléments suivants :

• Quels nœuds reçoivent les paquets de l'équilibreur de charge
• Si les paquets peuvent être acheminés entre les nœuds du cluster une fois que l'équilibreur de charge les a transmis à un nœud
• Indique si l'adresse IP du client d'origine est conservée ou perdue.

externalTrafficPolicy peut correspondre à Local ou Cluster :

• Utilisez externalTrafficPolicy: Local pour vous assurer que les paquets sont uniquement remis à un nœud avec au moins un pod de diffusion prêt et qui n'est pas en cours d'arrêt, tout en conservant l'adresse IP source du client d'origine. Cette option est idéale pour les charges de travail avec un nombre relativement constant de nœuds avec des pods de diffusion, même si le nombre total de nœuds dans le cluster varie. Cette option est obligatoire pour prendre en charge l'équilibrage de charge pondéré.

• Utilisez externalTrafficPolicy: Cluster lorsque le nombre total de nœuds dans votre cluster est relativement constant, mais que le nombre de nœuds avec des pods actifs varie. Cette option ne conserve pas les adresses IP sources des clients d'origine et peut ajouter de la latence, car les paquets peuvent être acheminés vers un pod de diffusion sur un autre nœud après avoir été remis à un nœud à partir de l'équilibreur de charge. Cette option n'est pas compatible avec l'équilibrage de charge pondéré.

Pour savoir comment externalTrafficPolicy affecte le routage de paquets dans les nœuds, consultez la section Traitement des paquets.

Équilibrage de charge pondéré

Les services LoadBalancer externes sont compatibles avec l'équilibrage de charge pondéré, ce qui permet aux nœuds avec plus de pods actifs, prêts et non terminaux de recevoir une plus grande proportion de nouvelles connexions par rapport aux nœuds avec moins de pods. Pour en savoir plus sur la façon dont les configurations d'équilibreur de charge changent avec l'équilibrage de charge pondéré, consultez Effet de l'équilibrage de charge pondéré.

Comme l'illustre le diagramme, les services avec équilibrage de charge pondéré activé distribuent les nouvelles connexions proportionnellement au nombre de pods prêts sur chaque nœud. Cela garantit que les nœuds avec plus de pods reçoivent une plus grande part des nouvelles connexions.

Pour utiliser l'équilibrage de charge pondéré, vous devez remplir toutes les conditions suivantes :

• Votre cluster GKE doit utiliser la version 1.31.0-gke.1506000 ou ultérieure.

• Le module complémentaire HttpLoadBalancing doit être activé pour votre cluster. Il est activé par défaut. Il permet au cluster de gérer les équilibreurs de charge qui utilisent des services de backend.

• Vous devez inclure l'annotation cloud.google.com/l4-rbs: "enabled" dans le fichier manifeste du service LoadBalancer pour que GKE crée un équilibreur de charge réseau passthrough externe basé sur un service de backend. Les équilibreurs de charge réseau passthrough externes basés sur un pool cible ne sont pas compatibles avec l'équilibrage de charge pondéré.

• Vous devez inclure l'annotation networking.gke.io/weighted-load-balancing: pods-per-node dans le fichier manifeste du service LoadBalancer pour activer la fonctionnalité d'équilibrage de charge pondéré.

• Le fichier manifeste du service LoadBalancer doit utiliser externalTrafficPolicy: Local. GKE ne vous empêche pas d'utiliser externalTrafficPolicy: Cluster, mais externalTrafficPolicy: Cluster désactive effectivement l'équilibrage de charge pondéré, car le paquet peut être acheminé, après l'équilibreur de charge, vers un autre nœud.

Pour utiliser l'équilibrage de charge pondéré, consultez Activer l'équilibrage de charge pondéré.

Affinité zonale

Les services LoadBalancer internes sont compatibles avec l'affinité zonale (preview), qui peut acheminer les nouvelles connexions vers des nœuds avec des pods de diffusion dans la même zone qu'un client. Conserver le trafic dans une zone permet de minimiser le trafic entre zones, ce qui réduit les coûts et la latence.

Pour utiliser l'affinité zonale, consultez Utiliser l'affinité zonale. Pour en savoir plus sur la façon dont les configurations d'équilibreur de charge changent avec l'affinité de zone, y compris lorsque vous pouvez conserver le trafic dans une zone, consultez Effet de l'affinité de zone. Pour en savoir plus sur la façon dont l'affinité zonale et externalTrafficPolicy influencent le routage des paquets sur les VM de nœuds, consultez Traduction d'adresse réseau source et routage sur les nœuds.

Remarques spécifiques aux services LoadBalancer internes

Cette section décrit l'option de sous-paramètre GKE, qui est propre aux services LoadBalancer internes, et explique comment le sous-paramètre GKE interagit avec externalTrafficPolicy pour influencer le nombre maximal de nœuds à équilibrer.

Sous-paramètre GKE

Bonne pratique:

Activez le sous-paramètre GKE pour améliorer l'évolutivité des services LoadBalancer internes.

Le sous-paramètre GKE, également appelé sous-paramètre GKE pour les équilibreurs de charge internes de couche 4, est une option de configuration à l'échelle du cluster qui améliore l'évolutivité des équilibreurs de charge réseau passthrough internes en regroupant plus efficacement les points de terminaison des nœuds dans des groupes de points de terminaison du réseau (NEG) GCE_VM_IP. Les NEG sont utilisés comme backends de l'équilibreur de charge.

Le schéma suivant montre deux services dans un cluster zonal comportant trois nœuds. Le sous-paramètre GKE est activé sur le cluster. Chaque service possède deux pods. GKE crée un NEG GCE_VM_IP pour chaque service. Les points de terminaison de chaque NEG sont les nœuds avec les pods de diffusion pour le service concerné.

Vous pouvez activer le sous-paramètre GKE lorsque vous créez un cluster ou en modifiant un cluster existant. Une fois activé, vous ne pouvez plus désactiver le sous-paramètre GKE. Le sous-paramètre GKE nécessite :

• GKE version 1.18.19-gke.1400 ou ultérieure ;
• Et le module complémentaire HttpLoadBalancing activé pour le cluster. Ce module complémentaire est activé par défaut. Il permet au cluster de gérer les équilibreurs de charge qui utilisent des services de backend.

Nombre de nœuds

Un cluster avec le sous-paramètre GKE désactivé peut rencontrer des problèmes avec les services LoadBalancer internes s'il comporte plus de 250 nœuds au total (dans tous les pools de nœuds). Cela se produit, car les équilibreurs de charge réseau passthrough internes créés par GKE ne peuvent distribuer des paquets qu'à 250 VM de nœud de backend maximum. Cette limite existe pour deux raisons :

• GKE n'utilise pas le sous-paramètre de backend de l'équilibreur de charge.
• Un équilibreur de charge réseau passthrough interne ne peut distribuer des paquets qu'à 250 backends maximum lorsque le sous-paramètre de backend de l'équilibreur de charge est désactivé.

Un cluster avec le sous-paramètre GKE activé est compatible avec les services LoadBalancer internes dans les clusters comptant plus de 250 nœuds au total.

• Un service LoadBalancer interne utilisant externalTrafficPolicy: Local dans un cluster pour lequel le sous-paramètre GKE est activé peut accepter jusqu'à 250 nœuds avec des pods actifs qui prennent en charge ce service.

• Un service LoadBalancer interne utilisant externalTrafficPolicy: Cluster dans un cluster où le sous-paramètre GKE est activé n'impose aucune limite au nombre de nœuds avec des pods actifs, car GKE ne configure pas plus de 25 points de terminaison de nœud dans les NEG GCE_VM_IP. Pour en savoir plus, consultez Appartenance des nœuds aux backends de NEG GCE_VM_IP.

Répartition du trafic

Par défaut, les services LoadBalancer internes et externes créent des équilibreurs de charge réseau passthrough avec l'affinité de session définie sur NONE. Les équilibreurs de charge réseau passthrough utilisent l'affinité de session, les informations sur l'état et, dans certaines circonstances, des détails tels que la pondération pour identifier et sélectionner un backend de nœud éligible pour une nouvelle connexion.

Les nouvelles connexions créent des entrées dans la table de suivi des connexions, qui sont utilisées pour acheminer rapidement les paquets suivants de la connexion vers le backend de nœud éligible précédemment sélectionné. Pour en savoir plus sur la façon dont les équilibreurs de charge réseau passthrough identifient et sélectionnent les backends éligibles, et utilisent le suivi des connexions, consultez les pages suivantes :

• Distribution du trafic pour les équilibreurs de charge réseau passthrough internes

• Distribution du trafic pour les équilibreurs de charge réseau passthrough externes

Effet de l'équilibrage de charge pondéré

Lorsque vous configurez l'équilibrage de charge pondéré pour un service LoadBalancer externe, GKE active l'équilibrage de charge pondéré sur l'équilibreur de charge réseau passthrough externe correspondant. GKE configure le logiciel kube-proxy ou cilium-agent pour inclure un en-tête de réponse dans la réponse à la vérification de l'état de l'équilibreur de charge. Cet en-tête de réponse définit un poids proportionnel au nombre de pods en cours d'exécution, prêts et non terminés sur chaque nœud.

L'équilibreur de charge utilise les informations de pondération comme suit :

• L'ensemble des backends de nœuds éligibles de l'équilibreur de charge se compose de tous les nœuds opérationnels et dont la pondération est non nulle.

• L'équilibreur de charge tient compte du poids lorsqu'il sélectionne l'un des backends de nœud éligibles. Lorsque le service utilise externalTrafficPolicy: Local (requis pour que l'équilibrage de charge pondéré soit efficace), un backend de nœud éligible qui comporte plus de pods de diffusion, prêts et non finalisés est plus susceptible d'être sélectionné qu'un backend de nœud éligible avec moins de pods.

Effet de l'affinité zonale

Lorsque vous configurez l'affinité zonale pour un service LoadBalancer interne, GKE configure l'équilibreur de charge réseau passthrough interne correspondant avec l'option ZONAL_AFFINITY_SPILL_CROSS_ZONE et un ratio de débordement nul.

Avec cette configuration d'affinité zonale, l'équilibreur de charge réduit l'ensemble d'origine des backends de nœuds éligibles aux seuls backends de nœuds éligibles qui se trouvent dans la même zone que le client lorsque toutes les conditions suivantes sont remplies :

• Le client est compatible avec l'affinité zonale.

• Au moins un backend de nœud éligible et opérationnel se trouve dans la zone du client.

Dans toutes les autres situations, l'équilibreur de charge continue d'utiliser l'ensemble d'origine des backends de nœuds éligibles, sans appliquer d'optimisation de l'affinité zonale.

Pour en savoir plus sur l'impact de la configuration de l'affinité zonale sur le comportement de l'équilibreur de charge, consultez la documentation sur l'affinité zonale.

Regroupement de nœuds

La version de GKE, les annotations du fichier manifeste du service et, pour les services LoadBalancer internes, l'option Sous-paramètre GKE déterminent l'équilibreur de charge Trusted Cloud et le type de backends obtenus. Le type d'équilibreur de charge et de backend détermine la manière dont les nœuds sont regroupés dans les NEG GCE_VM_IP, les groupes d'instances ou les pools cibles. Dans tous les cas,les équilibreurs de charge directs Trusted Cloudidentifient l'interface réseau (carte d'interface réseau) du nœud GKE, et non un nœud ou une adresse IP de pod spécifique.

Service LoadBalancer GKE	Équilibreur de charge Trusted Cloud obtenu	Méthode de regroupement des nœuds
Service LoadBalancer interne créé dans un cluster avec le sous-paramètre GKE activé1	Un équilibreur de charge réseau passthrough interne dont le service de backend utilise des backends de groupes de points de terminaison du réseau (NEG) GCE_VM_IP	Les VM de nœud sont regroupées par zones dans des NEG GCE_VM_IP service par service en fonction de la règle externalTrafficPolicy du service et du nombre de nœuds dans le cluster. La règle externalTrafficPolicy du service contrôle également quels nœuds sont soumis à la vérification d'état de l'équilibreur de charge et au traitement des paquets.
Service LoadBalancer interne créé dans un cluster avec le sous-paramètre GKE désactivé	Un équilibreur de charge réseau passthrough interne dont le service de backend utilise des backends de groupes d'instances non gérés zonaux.	Toutes les VM de nœud sont placées dans des groupes d'instances non gérés zonaux que GKE utilise en tant que backends pour le service de backend de l'équilibreur de charge réseau passthrough interne. La règle externalTrafficPolicy du service contrôle quels nœuds sont soumis à la vérification d'état de l'équilibreur de charge et au traitement des paquets. Les mêmes groupes d'instances non gérés sont utilisés pour les autres services de backend d'équilibreur de charge créés dans le cluster en raison de la limitation des groupes d'instances à équilibrage de charge unique.
Service LoadBalancer externe avec l'annotation cloud.google.com/l4-rbs: "enabled"2 appliquée à un cluster exécutant GKE version 1.32.2-gke.1652000 ou ultérieure4	Un équilibreur de charge réseau passthrough externe basé sur un service de backend dont le service de backend utilise des backends de groupes de points de terminaison du réseau (NEG) GCE_VM_IP	Les VM de nœud sont regroupées par zones dans des NEG GCE_VM_IP service par service en fonction de la règle externalTrafficPolicy du service et du nombre de nœuds dans le cluster. La règle externalTrafficPolicy du service contrôle également quels nœuds sont soumis à la vérification d'état de l'équilibreur de charge et au traitement des paquets.
Service LoadBalancer externe avec l'annotation cloud.google.com/l4-rbs: "enabled"2 appliquée à un cluster exécutant une version GKE antérieure à 1.32.2-gke.16520004	Un équilibreur de charge réseau passthrough externe basé sur un service de backend dont le service de backend utilise des backends de groupes d'instances non gérés zonaux.	Toutes les VM de nœud sont placées dans des groupes d'instances non gérés zonaux que GKE utilise en tant que backends pour le service de backend de l'équilibreur de charge réseau passthrough externe. La règle externalTrafficPolicy du service contrôle quels nœuds sont soumis à la vérification d'état de l'équilibreur de charge et au traitement des paquets. Les mêmes groupes d'instances non gérés sont utilisés pour les autres services de backend d'équilibreur de charge créés dans le cluster en raison de la limitation des groupes d'instances à équilibrage de charge unique.
Service LoadBalancer externe sans l'annotation cloud.google.com/l4-rbs: "enabled"3	Un équilibreur de charge réseau passthrough externe basé sur un pool cible dont le pool cible contient tous les nœuds du cluster.	Le pool cible est une ancienne API qui ne repose pas sur des groupes d'instances. Tous les nœuds ont une appartenance directe au pool cible. La règle externalTrafficPolicy du service contrôle quels nœuds sont soumis à la vérification d'état de l'équilibreur de charge et au traitement des paquets.

Adhésion des nœuds dans les backends de NEG GCE_VM_IP

Lorsque le sous-paramètre GKE est activé pour un cluster, ou que des équilibreurs de charge réseau passthrough externes avec cloud.google.com/l4-rbs: "enabled" ont été créés sur GKE version 1.32.2-gke.1652000 ou ultérieure, GKE crée un NEG GCE_VM_IP unique dans chaque zone pour chaque service LoadBalancer. Contrairement aux groupes d'instances, les nœuds peuvent être membres de plusieurs NEG GCE_VM_IP à équilibrage de charge. La règle externalTrafficPolicy du service et le nombre de nœuds dans le cluster déterminent les nœuds ajoutés en tant que points de terminaison aux NEG GCE_VM_IP du service.

Le plan de contrôle du cluster ajoute des nœuds en tant que points de terminaison aux NEG GCE_VM_IP en fonction de la valeur de la règle externalTrafficPolicy du service et du nombre de nœuds dans le cluster, comme résumé dans les tableaux suivants.

Nœuds dans l'équilibreur de charge réseau passthrough interne

externalTrafficPolicy	Nombre de nœuds dans le cluster	Adhésion au point de terminaison
Cluster	1 à 25 nœuds	GKE utilise tous les nœuds du cluster comme points de terminaison pour le ou les NEG du service, même si un nœud ne contient pas de pod de diffusion pour le service.
Cluster	Plus de 25 nœuds	GKE utilise un sous-ensemble aléatoire de jusqu'à 25 nœuds comme points de terminaison pour le ou les NEG du service, même si un nœud ne contient pas de pod de diffusion pour le service.
Local	N'importe quel nombre de nœuds1	GKE n'utilise que les nœuds dont au moins un des pods de diffusion du service est utilisé comme point de terminaison pour le ou les NEG du service.

Nœuds dans l'équilibreur de charge réseau passthrough externe

externalTrafficPolicy	Nombre de nœuds dans le cluster	Adhésion au point de terminaison
Cluster	1 à 250 nœuds	GKE utilise tous les nœuds du cluster comme points de terminaison pour le ou les NEG du service, même si un nœud ne contient pas de pod de diffusion pour le service.
Cluster	Plus de 250 nœuds	GKE utilise un sous-ensemble aléatoire de jusqu'à 250 nœuds comme points de terminaison pour le ou les NEG du service, même si un nœud ne contient pas de pod de diffusion pour le service.
Local	N'importe quel nombre de nœuds1	GKE n'utilise que les nœuds dont au moins un des pods de diffusion du service est utilisé comme point de terminaison pour le ou les NEG du service.

Limite des groupes d'instances à équilibrage de charge unique

L'API Compute Engine interdit aux VM d'être membres de plusieurs groupes d'instances à équilibrage de charge. Les nœuds GKE sont soumis à cette contrainte.

Lorsque vous utilisez des backends de groupes d'instances non gérés, GKE crée ou met à jour des groupes d'instances non gérés contenant tous les nœuds de tous les pools de nœuds dans chaque zone utilisée par le cluster. Ces groupes d'instances non gérés sont utilisés pour :

• Équilibreurs de charge réseau passthrough internes créés pour les services LoadBalancer internes lorsque le sous-paramètre GKE est désactivé.
• Les équilibreurs de charge réseau passthrough externes basés sur un service de backend et créés pour les services LoadBalancer externes avec l'annotation cloud.google.com/l4-rbs: "enabled".
• Les équilibreurs de charge d'application externes créés pour les ressources Ingress GKE externes, qui utilisent le contrôleur GKE Ingress mais n'utilisent pas l'équilibrage de charge natif en conteneurs.

Comme les VM de nœud ne peuvent pas être membres de plusieurs groupes d'instances à équilibrage de charge, GKE ne peut pas créer ni gérer d'équilibreurs de charge réseau passthrough internes, d'équilibreurs de charge réseau passthrough externes basés sur un service de backend ou d'équilibreurs de charge d'application externes créés pour les ressources d'entrée GKE si l'une des conditions suivantes est true :

• En dehors de GKE, vous avez créé au moins un équilibreur de charge basé sur un service de backend, et vous avez utilisé les groupes d'instances gérés du cluster comme backends pour le service de backend de l'équilibreur de charge.
• En dehors de GKE, vous créez un groupe d'instances non géré personnalisé contenant tout ou partie des nœuds du cluster, puis vous associez ce groupe d'instances non géré personnalisé à un service de backend pour un équilibreur de charge.

Pour contourner cette limitation, vous pouvez demander à GKE d'utiliser des backends de NEG lorsque cela est possible :

• Activez le sous-paramètre GKE. Par conséquent, les nouveaux services LoadBalancer internes utilisent des NEG GCE_VM_IP à la place.
• Configurez les ressources Ingress GKE externes pour utiliser l'équilibrage de charge natif en conteneurs. Pour en savoir plus, consultez la page Équilibrage de charge natif en conteneurs GKE.

Vérifications de l'état de l'équilibreur de charge

Tous les services LoadBalancer de GKE implémentent une vérification de l'état de l'équilibreur de charge. Le système de vérification de l'état de l'équilibreur de charge fonctionne en dehors du cluster et est différent d'une vérification d'aptitude, d'activité ou de démarrage de pod.

Les paquets de vérification de l'état de l'équilibreur de charge sont traités par le logiciel kube-proxy (ancien dataplane) ou cilium-agent (GKE Dataplane V2) exécuté sur chaque nœud. Les vérifications de l'état de l'équilibreur de charge pour les services LoadBalancer ne peuvent pas être traitées par les pods.

La règle externalTrafficPolicy du service détermine quels nœuds sont soumis à la vérification d'état de l'équilibreur de charge. Pour en savoir plus sur la façon dont l'équilibreur de charge utilise les informations de vérification de l'état, consultez Distribution du trafic.

externalTrafficPolicy	Quels nœuds réussissent la vérification d'état	Quel est le port utilisé
Cluster	Tous les nœuds du cluster réussissent la vérification d'état, y compris ceux sans pods de diffusion. Si au moins un pod de diffusion existe sur un nœud, ce nœud réussit la vérification de l'état de l'équilibreur de charge, quel que soit l'état de son pod.	Le port de vérification de l'état de l'équilibreur de charge doit être le port TCP 10256. Il ne peut pas être personnalisé.
Local	La vérification de l'état de l'équilibreur de charge considère qu'un nœud est opérationnel si au moins un pod de diffusion prêt et qui n'est pas en cours d'arrêt existe sur le nœud, quel que soit l'état des autres pods. Les nœuds sans pod de diffusion, les nœuds dont les pods de diffusion échouent aux vérifications d'aptitude et les nœuds dont les pods de diffusion sont tous en fin d'arrêt échouent à la vérification de l'état'équilibreur de charge. Pendant les transitions d'état, un nœud passe toujours la vérification de l'état de l'équilibreur de charge jusqu'à ce que le seuil de faible capacité de la vérification de l'état de l'équilibreur de charge soit atteint. L'état de transition se produit lorsque tous les pods de diffusion sur un nœud commencent à échouer aux vérifications d'aptitude ou lorsque tous les pods de diffusion sur un nœud sont en cours d'arrêt. Le mode de traitement du paquet dans cette situation dépend de la version de GKE. Pour en savoir plus, consultez la section Traitement des paquets suivante.	Le plan de contrôle Kubernetes attribue le port de vérification de l'état à partir de la plage de ports du nœud, sauf si vous spécifiez un port de vérification de l'état personnalisé.

Lorsque l'équilibrage de charge pondéré est activé, l'équilibreur de charge utilise à la fois les informations sur l'état et la pondération pour identifier l'ensemble des backends de nœuds éligibles. Pour en savoir plus, consultez Effet de l'équilibrage de charge pondéré.

Lorsque l'affinité de zone est activée, l'équilibreur de charge peut affiner l'ensemble des backends de nœuds éligibles. Pour en savoir plus, consultez Effet de l'affinité zonale.

Traitement de paquets

Les sections suivantes expliquent comment fonctionnent les nœuds de l'équilibreur de charge et du cluster pour acheminer les paquets reçus pour les services LoadBalancer.

Équilibrage de charge direct

Les équilibreurs de charge réseau passthrough acheminent les paquets vers l'interface nic0 des nœuds du cluster GKE. Chaque paquet à équilibrage de charge reçu sur un nœud présente les caractéristiques suivantes :

• L'adresse IP de destination du paquet correspond à l'adresse IP de la règle de transfert de l'équilibreur de charge.
• Le protocole et le port de destination du paquet correspondent à ces deux éléments :
  • Un protocole et un port spécifiés dans spec.ports[] du fichier manifeste du service
  • Un protocole et un port configurés sur la règle de transfert de l'équilibreur de charge

Traduction d'adresses réseau de destination sur les nœuds

Une fois que le nœud a reçu le paquet, il effectue un traitement supplémentaire du paquet. Dans les clusters GKE qui utilisent l'ancien plan de données, les nœuds utilisent iptables pour traiter les paquets à équilibrage de charge. Dans les clusters GKE avec GKE Dataplane V2 activé, les nœuds utilisent eBPF à la place. Le traitement des paquets au niveau du nœud inclut toujours les actions suivantes :

• Le nœud effectue la traduction d'adresse réseau de destination (DNAT) sur le paquet, en définissant son adresse IP de destination sur une adresse IP de pod de diffusion.
• Le nœud remplace le port de destination du paquet par le targetPort du spec.ports[] du service correspondant.

Traduction d'adresse réseau source et routage sur les nœuds

Le tableau suivant montre la relation entre externalTrafficPolicy et la question de savoir si le nœud qui a reçu les paquets à équilibrer effectue une traduction d'adresse réseau source (SNAT) avant d'envoyer les paquets à équilibrer à un pod :

externalTrafficPolicy	Comportement SNAT
Cluster	Dans les clusters GKE qui utilisent l'ancien plan de données, chaque nœud ayant reçu des paquets à équilibrage de charge modifie toujours l'adresse IP source de ces paquets pour qu'elle corresponde à l'adresse IP du nœud, que le nœud route les paquets vers un pod local ou vers un pod sur un autre nœud. Dans les clusters GKE qui utilisent GKE Dataplane V2, chaque nœud ayant reçu des paquets à équilibrage de charge modifie l'adresse IP source de ces paquets pour qu'elle corresponde à l'adresse IP du nœud uniquement si le nœud de réception route les paquets vers un pod sur un nœud différent. Si le nœud qui a reçu les paquets à équilibrage de charge les achemine vers un pod local, il ne modifie pas l'adresse IP source de ces paquets.
Local	Chaque nœud ayant reçu des paquets à équilibrage de charge les achemine exclusivement vers un pod local, et le nœud ne modifie pas l'adresse IP source de ces paquets.

Le tableau suivant montre comment externalTrafficPolicy contrôle la manière dont les nœuds routent les paquets à charge équilibrée et les paquets de réponse :

externalTrafficPolicy	Routage de paquets à équilibrage de charge	Routage des paquets de réponse
Cluster	Voici le comportement de référence pour le routage des paquets à équilibrage de charge : Si le nœud qui a reçu les paquets à équilibrage de charge ne dispose pas d'un pod de diffusion prêt et non final, il achemine les paquets vers un autre nœud qui dispose d'un pod de diffusion prêt et non final. Si le nœud qui a reçu les paquets équilibrés en charge dispose d'un pod de diffusion prêt et non final, il peut acheminer les paquets vers l'un des éléments suivants : Un pod local. Un autre nœud disposant d'un pod actif, prêt et non final. Dans les clusters régionaux, si le nœud qui a reçu les paquets à équilibrage de charge les route vers un autre nœud, l'affinité zonale a l'effet suivant : Si l'affinité zonale n'est pas activée, le nœud différent peut se trouver dans n'importe quelle zone. Si l'affinité zonale est activée, le nœud qui a reçu les paquets à équilibrage de charge tente de les acheminer vers un autre nœud de la même zone. Si ce n'est pas possible, le nœud différent peut se trouver dans n'importe quelle zone. En dernier recours, si aucun pod de diffusion, prêt et non en cours d'arrêt n'est disponible pour le service sur tous les nœuds du cluster, les événements suivants se produisent : Si l'option "Points de terminaison avec arrêt du proxy" est activée1, le nœud qui a reçu les paquets équilibrés en charge les achemine vers un pod de diffusion en cours d'arrêt, si possible. Si l'option "Points de terminaison avec arrêt du proxy" est désactivée ou s'il n'y a aucun pod dans l'ensemble du cluster, le nœud qui a reçu les paquets à équilibrage de charge ferme la connexion avec une réinitialisation TCP.	Les paquets de réponse sont toujours envoyés à partir d'un nœud à l'aide du retour direct du serveur : Si le nœud avec le pod de diffusion n'est pas celui qui a reçu les paquets d'équilibrage de charge correspondants, le nœud de diffusion renvoie les paquets de réponse au nœud de réception. Le nœud de réception envoie ensuite les paquets de réponse à l'aide du retour direct du serveur. Si le nœud avec le pod de diffusion est celui qui a reçu les paquets à équilibrage de charge, il envoie les paquets de réponse à l'aide du retour direct du serveur.
Local	Voici le comportement de base pour le routage des paquets à équilibrage de charge : le nœud qui a reçu les paquets à équilibrage de charge dispose généralement d'un pod de diffusion prêt et qui n'est pas en cours d'arrêt (car il est nécessaire d'avoir un tel pod pour réussir la vérification d'état de l'équilibreur de charge). Le nœud achemine les paquets à équilibrage de charge vers un pod local. Dans les clusters régionaux, l'affinité zonale ne modifie pas le comportement de référence pour le routage des paquets à équilibrage de charge. En dernier recours, s'il n'y a pas de pods de diffusion prêts et non finalisés pour le service sur le nœud qui a reçu les paquets équilibrés en charge, les événements suivants se produisent : Si l'option "Points de terminaison de fin de proxy" est activée1, le nœud qui a reçu les paquets à équilibrage de charge les achemine vers un pod de diffusion et de fin local, si possible. Si l'option "Points de terminaison de l'arrêt du proxy" est désactivée ou si le nœud qui a reçu les paquets à équilibrage de charge ne dispose d'aucun pod de diffusion, ce nœud ferme la connexion avec une réinitialisation TCP.	Le nœud avec le pod de diffusion est toujours le nœud qui a reçu les paquets à équilibrage de charge. Ce nœud envoie les paquets de réponse à l'aide du retour direct du serveur.

Quotas

Le nombre de règles de transfert que vous pouvez créer est contrôlé par des quotas d'équilibreur de charge :

• Les équilibreurs de charge réseau passthrough internes utilisent le quota de services de backend par projet, le quota de vérifications d'état par projet et les quota de règles de transfert de l'équilibreur de charge réseau passthrough interne par réseau cloud privé virtuel.
• Les équilibreurs de charge réseau passthrough externes basés sur un service de backend utilisent le quota de services de backend par projet, le quota de vérifications d'état par projet et le quota quota de règles de transfert de l'équilibreur de charge réseau passthrough externe par projet.
• Les équilibreurs de charge réseau passthrough externes basés sur un pool cible utilisent le quota de pools cibles par projet, le quota de vérifications d'état par projet et le quota de règles de transfert de l'équilibreur de charge réseau passthrough externe par projet.

Étape suivante

• En savoir plus sur les paramètres du service GKE LoadBalancer
• En savoir plus sur les services Kubernetes