Ce document offre un aperçu général de la manière dont Google Kubernetes Engine (GKE) crée et gère des équilibreurs de charge Google Cloud lorsque vous appliquez un fichier manifeste des services LoadBalancer Kubernetes. Il décrit les différents types d'équilibreurs de charge et la façon dont les paramètres tels que externalTrafficPolicy et le sous-paramètre GKE pour les équilibreurs de charge internes L4 déterminent la configuration des équilibreurs de charge.
Avant de lire ce document, 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 équilibreur de charge direct Google Cloud dont les caractéristiques dépendent des paramètres de votre fichier manifeste du service.
Choisir un service LoadBalancer
Lorsque vous choisissez la configuration du service LoadBalancer à utiliser, tenez compte des aspects suivants :
- Type d'adresse IP de l'équilibreur de charge. Votre équilibreur de charge peut possséder une adresse IP interne ou externe.
- Nombre et type de nœuds acceptés par LoadBalancer.
Après avoir déterminé les exigences liées à votre architecture réseau, utilisez l'arbre de décision ci-dessous pour déterminer le service LoadBalancer à choisir pour votre configuration réseau.
Équilibrage de charge externe ou interne
Lorsque vous créez un service LoadBalancer dans GKE, vous spécifiez si l'équilibreur de charge possède une adresse interne ou externe :
Si vos clients se trouvent sur le même réseau VPC ou sur un réseau connecté au cluster (réseau VPC), utilisez un service LoadBalancer interne. Les services LoadBalancer internes sont mis en œuvre à l'aide d'équilibreurs de charge réseau internes à stratégie directe. 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 au service via l'adresse IP de l'équilibreur de charge.
Pour créer un service LoadBalancer interne, placez l'une des annotations suivantes dans les
metadata.annotations[]du fichier manifeste du service :networking.gke.io/load-balancer-type: "Internal"(GKE 1.17 et versions ultérieures)cloud.google.com/load-balancer-type: "Internal"(versions antérieures à 1.17)
Si vos clients sont situés en dehors de votre réseau VPC, utilisez un service LoadBalancer externe. Vous pouvez utiliser l'un des types d'équilibreurs de charge réseau externes passthrough suivants accessibles sur Internet (y compris les VM Google Cloud avec accès Internet) :
- (Recommandé) Créez un équilibreur de charge réseau externe à stratégie directe basé sur un service de backend en incluant les éléments suivants dans la section
metadata.annotations[]du fichier manifeste :cloud.google.com/l4-rbs: "enabled" - Créez un équilibreur de charge réseau externe à stratégie directe basé sur un pool cible en omettant l'annotation
cloud.google.com/l4-rbs: "enabled".
- (Recommandé) Créez un équilibreur de charge réseau externe à stratégie directe basé sur un service de backend en incluant les éléments suivants dans la section
Effet sur externalTrafficPolicy
Vous pouvez définir externalTrafficPolicy sur Local ou Cluster pour spécifier la manière dont les paquets sont acheminés vers des nœuds avec des pods prêts et actifs. Tenez compte des scénarios suivants lorsque vous définissez externalTrafficPolicy :
Utilisez
externalTrafficPolicy: Localpour conserver les adresses IP clientes d'origine ou si vous souhaitez minimiser les perturbations lorsque le nombre de nœuds sans pods actifs dans le cluster change.Utilisez la valeur
externalTrafficPolicy: Clustersi le nombre total de nœuds sans pods actifs dans votre cluster est inchangé, mais que le nombre de nœuds avec des pods actifs change. Cette option ne conserve pas les adresses IP clientes d'origine.
Pour savoir comment externalTrafficPolicy affecte le routage de paquets dans les nœuds, consultez la section Traitement des paquets.
Sous-paramètre GKE
L'option de configuration à l'échelle du cluster du sous-paramètre GKE pour les équilibreurs de charge internes L4, ou sous-paramètre GKE, améliore l'évolutivité des équilibreurs de charge réseau internes à stratégie directe en regroupant plus efficacement les points de terminaison des nœuds pour les backends de l'équilibreur de charge.
Le schéma suivant montre deux services dans un cluster zonal comportant trois nœuds et le sous-paramètre GKE activé. Chaque service possède deux pods.
GKE crée un groupe de points de terminaison du réseau (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. Pour en savoir plus, consultez la section 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
HttpLoadBalancingactivé 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.
Remarques concernant le nombre de nœuds lors de l'activation du sous-paramètre GKE
Il est recommandé d'activer le sous-paramètre GKE si vous devez créer des services LoadBalancer internes. Le sous-paramètre GKE vous permet d'accepter davantage de nœuds dans votre cluster :
Si le sous-paramètre GKE est désactivé sur votre cluster, vous ne devez pas créer plus de 250 nœuds (dans tous les pools de nœuds). Si vous créez plus de 250 nœuds au total dans le cluster, les services LoadBalancer internes peuvent rencontrer une répartition inégale du trafic ou une perte complète de connectivité.
Si le sous-paramètre GKE est activé sur votre cluster, vous pouvez utiliser
externalTrafficPolicy: LocalouexternalTrafficPolicy: Cluster, à condition que le nombre de nœuds uniques avec au moins un pod actif ne dépasse pas 250 nœuds. Les nœuds sans pod actifs ne sont pas concernés. Si vous avez besoin de plus de 250 nœuds avec au moins un pod actif, vous devez utiliserexternalTrafficPolicy: Cluster.
Les équilibreurs de charge réseau internes à stratégie directe créés par GKE ne peuvent distribuer des paquets que jusqu'à 250 VM de nœud de backend. Cette limite existe parce que GKE n'utilise pas le sous-paramètre de backend de l'équilibreur de charge, et un équilibreur de charge réseau interne à stratégie directe ne peut distribuer des paquets qu'à 250 backends maximum lorsque le sous-paramètre de backend de l'équilibreur de charge est désactivé.
Regroupement de nœuds
Les annotations du fichier manifeste du service et, pour le service LoadBalancer interne, l'état du sous-paramètre GKE déterminent l'équilibreur de charge Google Cloud et le type de backends obtenus. Les backends des équilibreurs de charge directs Google Cloud identifient 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. Le type d'équilibreur de charge et de backends 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.
| Service LoadBalancer GKE | Équilibreur de charge Google 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 interne à stratégie directe 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 La règle |
| Service LoadBalancer interne créé dans un cluster avec le sous-paramètre GKE désactivé | Un équilibreur de charge réseau interne à stratégie directe 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 interne à stratégie directe. La règle 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
|
Un équilibreur de charge réseau externe à stratégie directe 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 externe à stratégie directe. La règle 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 externe à stratégie directe 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 |
1 Seuls les équilibreurs de charge réseau internes à stratégie directe créés après l'activation du sous-paramètre GKE utilisent des NEG GCE_VM_IP. Tous les services LoadBalancer internes créés avant d'activer le sous-paramètre GKE continuent d'utiliser des backends de groupe d'instances non gérés. Pour obtenir des exemples et des conseils de configuration, consultez la section Créer des services LoadBalancer internes.
2 GKE ne migre pas automatiquement les services LoadBalancer externes existants des équilibreurs de charge réseau externes à stratégie directe basés sur un pool cible vers des équilibreurs de charge réseau externes à stratégie directe basés sur un service de backend. Pour créer un service LoadBalancer externe reposant sur un équilibreur de charge réseau externe à stratégie directe basé sur un service de backend, vous devez inclure l'annotation cloud.google.com/l4-rbs: "enabled" dans le fichier manifeste du service au moment de la création.
3 La suppression de l'annotation cloud.google.com/l4-rbs: "enabled" d'un service LoadBalancer externe existant reposant sur un équilibreur de charge réseau externe à stratégie directe basé sur un service de backend n'entraîne pas la création par GKE d'un équilibreur de charge réseau externe à stratégie directe basé sur un pool en tant que cible. Pour créer un service LoadBalancer externe reposant sur un équilibreur de charge réseau externe à stratégie directe basé sur un pool cible, vous devez omettre l'annotation cloud.google.com/l4-rbs: "enabled" du fichier manifeste du service au moment de la création.
Adhésion des nœuds dans les backends de NEG GCE_VM_IP
Lorsque le sous-paramètre GKE est activé pour un cluster, GKE crée un NEG GCE_VM_IP unique dans chaque zone pour chaque service LoadBalancer interne. 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 le tableau suivant.
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 pods de diffusion pour les services LoadBalancer internes. Plus de 250 nœuds peuvent être présents dans le cluster, mais les équilibreurs de charge réseau internes à stratégie directe ne desservent que 250 VM de backend lorsque le sous-paramètre de backend de l'équilibreur de charge réseau interne à stratégie directe est désactivé. Même avec le sous-paramètre GKE activé, GKE ne configure jamais les équilibreurs de charge réseau internes à stratégie directe avec le sous-paramètre de backend d'équilibreur de charge réseau interne à stratégie directe. Pour en savoir plus sur cette limite, consultez la section Nombre maximal d'instances de VM par service de backend interne.
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 internes à stratégie directe créés pour les services LoadBalancer internes lorsque le sous-paramètre GKE est désactivé.
- Les équilibreurs de charge réseau externes à stratégie directe 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 internes à stratégie directe, d'équilibreurs de charge réseau externes à stratégie directe 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 nécessitent une vérification d'état de l'équilibreur de charge. La vérification d'état de l'équilibreur de charge est mise en œuvre en dehors du cluster et est différente d'une vérification d'aptitude ou d'activité.
La règle externalTrafficPolicy du service définit le déroulement de la vérification d'état de l'équilibreur de charge. Dans tous les cas, les vérificateurs d'état de l'équilibreur de charge envoient des paquets au logiciel kube-proxy exécuté sur chaque nœud. La vérification d'état de l'équilibreur de charge est un proxy pour les informations collectées par kube-proxy, telles que l'existence ou non d'un pod, s'il est en cours d'exécution et s'il a réussi sa vérification d'activité. Les vérifications d'état des services LoadBalancer ne peuvent pas être acheminées vers des pods actifs. La vérification d'état de l'équilibreur de charge est conçue pour diriger les nouvelles connexions TCP vers les nœuds.
Le tableau suivant décrit le comportement de la vérification de l'état :
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, même s'ils ne comportent aucun pod de diffusion. Si un ou plusieurs pods de diffusion existent sur un nœud, ce nœud réussit la vérification d'état de l'équilibreur de charge, même si les pods de diffusion sont en cours d'arrêt ou échouent aux vérifications d'aptitude. | 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 |
Seuls les nœuds avec au moins un pod de diffusion prêt et qui n'est pas en cours d'arrêt réussissent la vérification d'état de l'équilibreur de charge. 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 d'état de l'équilibreur de charge. Pendant les transitions d'état, un nœud passe toujours la vérification d'état de l'équilibreur de charge jusqu'à ce que le seuil de faible capacité 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 port de vérification de l'état est le port TCP 10256, sauf si vous spécifiez un port de vérification d'état personnalisé. |
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
L'équilibreur de charge direct Google Cloud achemine les paquets vers l'interface nic0 des nœuds du cluster GKE. Chaque paquet à équilibrage de charge reçu par 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
- Un protocole et un port spécifiés dans
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 sans GKE Dataplane V2 activé, 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
targetPortduspec.ports[]du service correspondant.
Traduction d'adresse réseau source sur les nœuds
La règle externalTrafficPolicy détermine si le traitement des paquets au niveau du nœud effectue également la traduction d'adresse réseau source (SNAT) ainsi que le chemin d'accès du paquet entre le nœud et le pod :
externalTrafficPolicy |
Comportement SNAT du nœud | Comportement du routage |
|---|---|---|
Cluster |
Le nœud modifie l'adresse IP source des paquets à équilibrage de charge afin qu'elle corresponde à l'adresse IP du nœud qui l'a reçu de l'équilibreur de charge. | Le nœud achemine les paquets vers n'importe quel pod de diffusion. Le pod de diffusion peut se trouver ou non sur le même nœud. Si le nœud qui reçoit les paquets de l'équilibreur de charge n'a pas de pod prêt et actif, le nœud achemine les paquets vers un autre nœud qui contient un pod prêt et actif. Les paquets de réponse du pod sont acheminés de son nœud vers le nœud qui a reçu les paquets de requête de l'équilibreur de charge. Ce premier nœud envoie ensuite les paquets de réponse au client d'origine à l'aide du retour direct du serveur (DSR, Direct Server Return). |
Local |
Le nœud ne modifie pas l'adresse IP source des paquets à équilibrage de charge. | Dans la plupart des cas, le nœud achemine le paquet vers un pod de diffusion s'exécutant sur le nœud qui a reçu le paquet de l'équilibreur de charge. Ce nœud envoie des paquets de réponse au client d'origine à l'aide du retour direct du serveur. Il s'agit de l'intent principal de ce type de règle de trafic. Dans certains cas, un nœud reçoit des paquets de l'équilibreur de charge, même s'il lui manque un pod de diffusion prêt et non final pour le service. Cette situation se produit lorsque la vérification d'état de l'équilibreur de charge n'a pas encore atteint son seuil d'échec, mais qu'un pod précédemment prêt et actif n'est plus prêt ou se termine (par exemple, lors d'une mise à jour progressive). Le mode de traitement des paquets dans cette situation dépend de la version de GKE, si le cluster utilise GKE Dataplane V2 et de la valeur de
|
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 de Google Cloud.
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 internes à stratégie directe 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 interne à stratégie directe par réseau cloud privé virtuel.
- Les équilibreurs de charge réseau externes à stratégie directe 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 externe à stratégie directe par projet.
- Les équilibreurs de charge réseau externes à stratégie directe 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 externe à stratégie directe par projet.
Étapes suivantes
- Paramètres du service GKE LoadBalancer.
- Services Kubernetes.
- Paramètres du service GKE LoadBalancer.