À 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 Google Cloud 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 Google 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 de service LoadBalancer à utiliser, tenez compte des aspects suivants :

Arbre de décision du service LoadBalancer.
Figure  : Arbre de décision du service LoadBalancer

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

    Pour créer un service LoadBalancer externe, utilisez l'une des techniques suivantes :

    • Dans les clusters exécutant GKE 1.33.1-gke.1779000 ou version ultérieure, ajoutez spec.loadBalancerClass: "networking.gke.io/l4-regional-external" au fichier manifeste de service avant de l'envoyer au cluster. Nous vous recommandons d'utiliser ce champ, car il crée toujours un équilibreur de charge réseau passthrough externe basé sur un service de backend avec des backends de NEG GCE_VM_IP. Le champ spec.loadBalancerClass est immuable et ne peut pas être modifié après la création du service.

    • Dans les clusters exécutant une version GKE compatible, vous pouvez ajouter l'annotation cloud.google.com/l4-rbs: "enabled" au fichier manifeste de service avant de l'envoyer au cluster. Cette annotation crée également un équilibreur de charge réseau passthrough externe basé sur un service de backend. L'équilibreur de charge utilise des backends NEG GCE_VM_IP si le fichier manifeste est envoyé à un cluster exécutant GKE 1.32.2-gke.1652000 ou version ultérieure. Sinon, l'équilibreur de charge utilise des backends de groupe d'instances. GKE n'évalue cette annotation que lorsque le fichier manifeste du service est appliqué pour la première fois au cluster.

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

    Avant de créer un service LoadBalancer interne, assurez-vous que le sous-paramètre GKE est activé. Le sous-ensemble GKE est automatiquement activé si votre cluster exécute GKE 1.36 ou version ultérieure. Pour les versions antérieures de GKE, vous devez activer explicitement le sous-paramètre GKE.

    Pour créer un service LoadBalancer interne, utilisez l'une des techniques suivantes :

    • Dans les clusters qui exécutent GKE 1.33.1-gke.1779000 ou version ultérieure et sur lesquels le sous-ensemble GKE est activé, ajoutez spec.loadBalancerClass: "networking.gke.io/l4-regional-internal" au fichier manifeste de service avant de l'envoyer au cluster. Nous vous recommandons d'utiliser ce champ, car il crée toujours un équilibreur de charge réseau passthrough interne avec des backends de NEG GCE_VM_IP. Le champ spec.loadBalancerClass est immuable et ne peut pas être modifié après la création du service.

    • Dans les clusters qui exécutent une version GKE compatible, vous pouvez ajouter l'annotation networking.gke.io/load-balancer-type: "Internal" au fichier manifeste de service avant de l'envoyer au cluster. Cette opération crée également un équilibreur de charge réseau passthrough interne. L'équilibreur de charge utilise des backends NEG GCE_VM_IP si le fichier manifeste est envoyé à un cluster sur lequel le sous-paramètre GKE est activé. Sinon, l'équilibreur de charge utilise des backends de groupe d'instances.

Les fichiers manifestes de service LoadBalancer qui ne contiennent pas d'annotation spec.loadBalancerClass et qui ne contiennent pas non plus les annotations cloud.google.com/l4-rbs: "enabled" ou networking.gke.io/load-balancer-type: "Internal" créent un équilibreur de charge réseau passthrough externe basé sur un pool cible. Nous vous déconseillons d'utiliser des équilibreurs de charge réseau passthrough externes basés sur un pool cible.

Prérequis HttpLoadBalancing

Pour créer des services LoadBalancer reposant sur des équilibreurs de charge réseau passthrough externes ou internes basés sur un service de backend, assurez-vous que le module complémentaire HttpLoadBalancing est activé si votre cluster exécute une version GKE antérieure à 1.36. Le module complémentaire HttpLoadBalancing est activé par défaut.

Les services LoadBalancer dans GKE version 1.36 et ultérieure ne dépendent pas du module complémentaire HttpLoadBalancing.

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
  • Indique 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 être 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é.

Répartition du trafic par équilibrage de charge pondéré.
Figure  : Répartition du trafic avec l'équilibrage de charge pondéré

Comme l'illustre le diagramme, les services pour lesquels l'équilibrage de charge pondéré est activé distribuent les nouvelles connexions proportionnellement au nombre de pods prêts sur chaque nœud.

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.

  • Vous devez créer un service LoadBalancer externe qui génère un équilibreur de charge réseau passthrough externe basé sur un service de backend. Vous pouvez utiliser l'une des techniques suivantes :

    • Dans les clusters qui exécutent GKE 1.33.1-gke.1779000 ou version ultérieure, ajoutez spec.loadBalancerClass: "networking.gke.io/l4-regional-external" au fichier manifeste de service avant de l'envoyer au cluster. Il s'agit de la méthode recommandée.

    • Dans les clusters qui exécutent une version GKE compatible, ajoutez l'annotation cloud.google.com/l4-rbs: "enabled" au fichier manifeste de service avant de l'envoyer au cluster.

  • Vous devez inclure l'annotation networking.gke.io/weighted-load-balancing: pods-per-node dans le fichier manifeste du service 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 routé, 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 router les nouvelles connexions vers des nœuds avec des pods de diffusion dans la même zone qu'un client. S'il n'y a aucun pod sain dans la zone, GKE achemine le trafic vers une autre zone. Conserver le trafic dans une zone peut minimiser le trafic entre zones, ce qui réduit les coûts et la latence. Pour activer l'affinité zonale dans un cluster GKE, vous devez activer le sous-paramètre GKE.

Pour en savoir plus sur la façon dont les configurations d'équilibreur de charge changent avec l'affinité zonale, y compris quand vous pouvez conserver le trafic dans une zone, consultez Effet de l'affinité zonale. 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 la fonctionnalité 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

Le sous-paramètre GKE pour les services LoadBalancer internes est activé par défaut pour les clusters GKE qui exécutent la version 1.36 et ultérieures. Pour ces versions, le sous-ensemble GKE reste actif même si l'indicateur --enable-l4-ilb-subsetting au niveau du cluster est défini sur false dans la configuration de votre cluster ou dans les outils Infrastructure as Code (IaC) tels que Terraform.

Cette option de configuration à l'échelle du cluster 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é.

Sous-ensemble GKE pour deux services sur un cluster zonal.

Pour les clusters exécutant des versions antérieures à 1.36, vous pouvez activer manuellement le sous-paramètre GKE lorsque vous créez un cluster ou mettez à jour un cluster existant. Une fois le sous-paramètre GKE activé, vous ne pouvez plus le désactiver.

Le sous-paramètre GKE nécessite :

  • GKE version 1.18.19-gke.1400 ou ultérieure ;
  • Si votre cluster utilise une version antérieure à la version 1.36, le module complémentaire HttpLoadBalancing doit être activé. 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. Si votre cluster utilise la version 1.36 ou ultérieure, le module complémentaire HttpLoadBalancing n'est pas un prérequis pour le sous-ensemble GKE.

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 les deux raisons suivantes :

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

Le nombre de nœuds compatibles avec le sous-paramètre GKE dépend de la valeur du champ externalTrafficPolicy pour le service LoadBalancer interne :

  • externalTrafficPolicy: Local : prend en charge jusqu'à 250 nœuds avec des pods de diffusion pour un service donné.

  • externalTrafficPolicy: Cluster : n'impose pas de limite au nombre de nœuds avec des pods de diffusion. Ce comportement se produit, car GKE configure un maximum de 25 points de terminaison de nœud dans les NEG GCE_VM_IP pour chaque service. Pour en savoir plus, consultez Adhésion des nœuds dans les 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 :

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 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 Google Cloud et le type de backends obtenus.

Le tableau suivant décrit les méthodes de regroupement de nœuds pour différentes configurations de service LoadBalancer :

Détails du service et du cluster Équilibreur de charge Google Cloud obtenu Méthode de regroupement des nœuds
Services LoadBalancer internes
GKE version 1.33.1-gke.1779000 ou ultérieure dans un cluster avec le sous-paramètre GKE activé1. Fichier manifeste du service envoyé au cluster avec spec.loadBalancerClass: "networking.gke.io/l4-regional-internal". 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 dans des NEG zonaux 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.

Toutes les versions de GKE compatibles dans un cluster avec le sous-paramètre GKE activé1. Fichier manifeste de service soumis au cluster avec l'annotation networking.gke.io/load-balancer-type: "Internal".
Versions de GKE antérieures à 1.36 dans un cluster avec le sous-paramètre GKE désactivé1. Fichier manifeste de service soumis au cluster avec l'annotation networking.gke.io/load-balancer-type: "Internal". 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.
Services LoadBalancer externes
GKE version 1.33.1-gke.1779000 ou ultérieure. Fichier manifeste du service envoyé au cluster avec spec.loadBalancerClass: "networking.gke.io/l4-regional-external". Équilibreur de charge réseau passthrough externe basé sur un service de backend avec des backends de groupes de points de terminaison du réseau (NEG) GCE_VM_IP

Les VM de nœud sont regroupées dans des NEG zonaux 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.

GKE version 1.32.2-gke.1652000 ou ultérieure. Fichier manifeste de service soumis au cluster avec l'annotation cloud.google.com/l4-rbs: "enabled"2.
Version de GKE antérieure à 1.32.2-gke.16520003. Fichier manifeste de service soumis au cluster avec l'annotation cloud.google.com/l4-rbs: "enabled"2. Équilibreur de charge réseau passthrough externe basé sur un service de backend avec 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.
Toutes les versions de GKE compatibles. Fichier manifeste de service envoyé au cluster sans tous les éléments suivants :
  • spec.loadBalancerClass
  • networking.gke.io/load-balancer-type annotation
  • cloud.google.com/l4-rbs annotation
 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 NEG ni 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.

1 Le sous-paramètre GKE est automatiquement activé dans GKE 1.36 et versions ultérieures. Le sous-paramètre GKE ne peut pas être désactivé une fois qu'il a été activé.

2 L'annotation cloud.google.com/l4-rbs: "enabled" n'est prise en compte que lorsque le fichier manifeste Service est envoyé au cluster. L'ajout de cette annotation à un fichier manifeste de service existant ne convertit pas un équilibreur de charge réseau passthrough externe basé sur un pool cible en équilibreur de charge réseau passthrough externe basé sur un service de backend.

3 GKE ne met pas automatiquement à jour les équilibreurs de charge réseau passthrough externes basés sur un service de backend avec des backends de groupe d'instances vers des équilibreurs de charge réseau passthrough externes basés sur un service de backend avec des backends de NEG GCE_VM_IP. Pour obtenir des instructions de migration manuelle, consultez Migrer vers les backends NEG GCE_VM_IP.

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

Lorsque GKE crée un équilibreur de charge réseau passthrough interne ou un équilibreur de charge réseau passthrough externe basé sur un service de backend avec des backends de NEG GCE_VM_IP, il crée et gère les NEG comme suit :

  • 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 gère les points de terminaison des nœuds dans les 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.

1 Limité à 250 nœuds avec des pods de diffusion. Plus de 250 nœuds peuvent être présents dans le cluster, mais les équilibreurs de charge réseau passthrough internes ne peuvent distribuer des paquets qu'à 250 VM de backend lorsque le sous-paramètre de backend de l'équilibreur de charge réseau passthrough interne est désactivé. Même avec le sous-paramètre GKE activé, GKE ne configure jamais les équilibreurs de charge réseau passthrough internes avec le sous-paramètre de backend d'équilibreur de charge réseau passthrough interne. Pour en savoir plus sur cette limite, consultez la section Nombre maximal d'instances de VM par service de backend interne.

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.

1 Limité à 3 000 nœuds avec pods de diffusion. Plus de 3 000 nœuds peuvent être présents dans le cluster, mais GKE ne permet de créer que 3 000 points de terminaison maximum lorsqu'il crée des équilibreurs de charge réseau passthrough externes basés sur un service de backend qui utilisent des backends NEG GCE_VM_IP.

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 des backends pour les équilibreurs de charge créés par GKE suivants :

  • Équilibreur de charge réseau passthrough interne créé pour un service LoadBalancer interne dont le fichier manifeste comporte l'annotation networking.gke.io/load-balancer-type: "Internal", envoyé à un cluster exécutant une version GKE antérieure à la version 1.36, avec le sous-paramètre GKE désactivé.
  • Équilibreur de charge réseau passthrough externe basé sur un service de backend créé pour un service LoadBalancer externe dont le fichier manifeste comporte l'annotation cloud.google.com/l4-rbs: "enabled" et qui est envoyé à un cluster exécutant une version GKE antérieure à 1.32.2-gke.1652000.
  • Équilibreur de charge d'application externe créé pour une entrée GKE externe, utilisant le contrôleur GKE Ingress, mais n'utilisant 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 :

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 d'é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'é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 de l'état'é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'état, consultez Répartition 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 de l'é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'é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'é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 de l'état à partir de la plage de ports du nœud, sauf si vous spécifiez un vérification de l'état 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 dataplane, 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, s'il n'existe aucun pod de diffusion, prêt et non en cours d'arrêt pour le service sur tous les nœuds du cluster, les événements suivants se produisent :

  • Si l'option "Points de terminaison de l'arrêt du proxy" est activée1, le nœud qui a reçu les paquets à équilibrage de charge les achemine vers un pod de diffusion, mais 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 de l'état 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 terminaison du 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 terminaison 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.

1 Les points de terminaison de terminaison du proxy sont activés dans les configurations suivantes :

  • Clusters GKE qui utilisent l'ancien dataplane : GKE version 1.26 et ultérieure
  • Clusters GKE utilisant GKE Dataplane V2 : GKE version 1.26.4-gke.500 et ultérieure

Tarifs et quotas

La tarification du réseau s'applique aux paquets traités par un équilibreur de charge. Pour plus d'informations, consultez la section Tarifs de Cloud Load Balancing et des règles de transfert. Vous pouvez également estimer les frais de facturation à l'aide du simulateur de coût Google Cloud .

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

Étapes suivantes