Paramètres du service LoadBalancer


Cette page décrit les paramètres des fichiers manifestes des services qui contrôlent le comportement et la configuration du service LoadBalancer. Avant de lire cette page, vous devez connaître les concepts de service LoadBalancer de Google Kubernetes Engine (GKE).

Paramètres de l'objet Service

GKE est compatible avec les paramètres suivants pour les services LoadBalancer.

Parameter Champ et description du service Interne Externe Compatibilité avec les versions
Équilibreur de charge réseau passthrough interne networking.gke.io/load-balancer-type: "Internal"

Indique à GKE de créer un équilibreur de charge réseau passthrough interne.

Pour en savoir plus, consultez la page Concepts du service LoadBalancer.

Toutes les versions compatibles.
Équilibreur de charge réseau passthrough externe basé sur un service de backend cloud.google.com/l4-rbs: "enabled"

Indique à GKE de créer un équilibreur de charge réseau passthrough externe basé sur un service de backend.

Pour en savoir plus, consultez la page Concepts du service LoadBalancer.

GKE 1.25.5+
Règle de trafic interne spec.internalTrafficPolicy

Lorsque ce paramètre est défini sur Local, GKE n'achemine que les paquets des pods clients d'un nœud vers les pods de diffusion du même nœud. Lorsque ce paramètre est défini sur Cluster, GKE achemine les paquets des pods clients d'un nœud vers les pods de diffusion sur n'importe quel nœud. Pour en savoir plus, consultez la page Règle de trafic interne de service.

Ce paramètre n'est pas compatible avec les clusters exécutant GKE Dataplane V2.

GKE 1.22+
Règle de trafic externe spec.externalTrafficPolicy

Contrôle les VM de nœud qui réussissent les vérifications d'état de l'équilibreur de charge et la manière dont les paquets sont acheminés vers les pods prêts et actifs du cluster. Contrôle également la manière dont les nœuds sont regroupés dans les NEG GCE_VM_IP lorsque le sous-paramètre GKE est activé.

Pour en savoir plus, consultez la page Concepts du service LoadBalancer.

GKE 1.14+ (1.23.4-gke.400+ pour le pool de nœuds Windows)
Port de la vérification de l'état spec.healthCheckNodePort

Déploie une vérification de l'état de l'équilibreur de charge pour les services LoadBalancer. Ce paramètre n'est valide que si spec.externalTrafficPolicy est défini sur Local.

Toutes les versions compatibles.
Règles de pare-feu et liste d'autorisation d'adresses IP sources spec.loadBalancerSourceRanges

Configure des règles de pare-feu facultatives dans GKE et dans le réseau VPC pour n'autoriser que certaines plages sources.

Toutes les versions compatibles.
Adresses IP statiques
  • spec.loadBalancerIP (IPv4 uniquement)
  • networking.gke.io/load-balancer-ip-addresses

Spécifie une adresse IPv4 statique, une plage d'adresses IPv6 statique ou les deux, attribuées aux règles de transfert de l'équilibreur de charge. Pour connaître les exigences de configuration et les informations de mise en œuvre importantes, consultez la section Éléments à prendre en compte dans le partage d'une adresse IP commune.

  • spec.loadBalancerIP : Toutes les versions compatibles
  • networking.gke.io/load-balancer-ip-addresses : GKE 1.29 et versions ultérieures Consultez la section Paramètres d'adresse IP statique pour obtenir des informations supplémentaires sur les exigences de configuration ou d'annotations du cluster.
Niveaux de service réseau cloud.google.com/network-tier

Spécifie les niveaux de service réseau utilisés par GKE pour la règle de transfert externe et l'adresse IP. Les valeurs d'annotation valides sont Standard et Premium (par défaut).

GKE 1.19 et versions ultérieures.
Sous-réseau personnalisé
  • networking.gke.io/internal-load-balancer-subnet
  • networking.gke.io/load-balancer-subnet

(s'applique uniquement à IPv6)
  • networking.gke.io/internal-load-balancer-subnet : Toutes les versions compatibles
  • networking.gke.io/load-balancer-subnet : GKE 1.29 et versions ultérieures Consultez la section Annotations de sous-réseaux personnalisés pour connaître les exigences supplémentaires.
Accès mondial networking.gke.io/internal-load-balancer-allow-global-access: "true"

Rend l'adresse IP de la règle de transfert accessible aux clients de n'importe quelle région du réseau VPC ou d'un réseau connecté.

Aperçu dans GKE 1.16+ Disponible pour tous les utilisateurs de GKE 1.17.9-gke.600 et versions ultérieures.
Tous les ports

Aucune annotation n'est requise, mais le sous-paramètre GKE doit être activé.

GKE configure automatiquement la règle de transfert de façon à utiliser tous les ports si au moins six ports uniques (jusqu'à 100) sont spécifiés dans spec.ports[].port.

GKE version 1.18.19-gke.1400 ou ultérieure
ipFamilyPolicy

spec.ipFamilyPolicy

Définit la façon dont GKE alloue les adresses IP à un service. Vous pouvez définir spec.ipFamilyPolicy sur SingleStack, PreferDualStack ou RequireDualStack.

Pour en savoir plus, consultez la section "Services" de la page "IPv4/IPv6 à double pile".

Les clusters GKE version 1.29 ou ultérieure sont compatibles avec le réseau double pile pour les services LoadBalancer.
ipFamilies (facultatif)

spec.ipFamilies

Définit la famille d'adresses IP à laquelle allouer des services à pile unique ou à double pile. Utilisez l'une des valeurs suivantes :

  • IPv4 pour le service IPv4 à pile unique seulement.
  • IPv6 pour le service IPv6 seulement.
  • IPv4,IPv6 pour le service à double pile, où l'adresse IP principale du service est IPv4.
  • IPv6,IPv4 pour le service à double pile, où l'adresse IP principale du service est IPv6.
Les clusters GKE version 1.29 ou ultérieure sont compatibles avec le réseau double pile pour les services LoadBalancer.

Port de la vérification de l'état

Comme décrit dans la section Vérifications de l'état de l'équilibreur de charge et externalTrafficPolicy, GKE déploie toujours une vérification de l'état de l'équilibreur de charge lorsqu'il crée un équilibreur de charge réseau passthrough externe ou un équilibreur de charge réseau passthrough interne.

Le fait de pouvoir définir ou non le paramètre healthCheckNodePort dépend de la configuration externalTrafficPolicy suivante :

externalTrafficPolicy Port de la vérification de l'état
Cluster

Vous ne pouvez pas utiliser spec.healthCheckNodePort.

Local

Vous pouvez sélectionner un port personnalisé à l'aide de spec.healthCheckNodePort. Si aucune valeur n'est spécifiée, le plan de contrôle Kubernetes attribue un port de vérification de l'état à partir de la plage de ports du nœud.

Règles de pare-feu et liste d'autorisation d'adresses IP sources

Lorsque vous créez un service LoadBalancer, GKE crée une règle de pare-feu VPC correspondant au service. Chaque règle de pare-feu présente les caractéristiques suivantes :

  • Le sens de la règle de pare-feu est une règle d'entrée, et son action est autorisée. Les règles de pare-feu implicites interdisant les entrées dans Google Cloud signifient que GKE utilise un modèle de liste d'autorisation lors de la création de règles de pare-feu d'entrée.
  • GKE définit le protocole et le port de destination de la règle de pare-feu sur ceux spécifiés dans la liste spec.ports[] du service.
  • GKE définit la destination de la règle de pare-feu en définissant son paramètre cible sur l'adresse IP virtuelle de l'équilibreur de charge.
  • Si le service inclut spec.loadBalancerSourceRanges[], GKE définit le paramètre source de la règle de pare-feu sur les adresses IP de cette liste. Si le service n'inclut pas loadBalancerSourceRanges[], GKE définit le paramètre source de la règle de pare-feu sur toutes les adresses IP (0.0.0.0/0).

La règle de pare-feu créée pour un service LoadBalancer autorise les paquets vers l'adresse IP virtuelle du service à condition qu'ils correspondent au protocole et aux ports de destination de ce service.

Services utilisant des ports communs

Lorsqu'un cluster contient au moins deux services partageant au moins un protocole et un port de destination communs, l'ensemble effectif de plages sources correspond à l'union de loadBalancerSourceRanges pour tous les services qui spécifient ce protocole et cette combinaison de port de destination. En effet, le paramètre cible d'une règle de pare-feu d'entrée définit les adresses IP de destination comme toutes les adresses IP associées à une VM.

Prenons l'exemple d'un cluster comportant deux services LoadBalancer :

  • Le spec.ports[0].port du premier service est le port TCP 80, et son spec.loadBalancerSourceRanges=[100.10.0.0/16]. L'équilibreur de charge correspondant à ce service possède l'adresse IP 192.0.2.2.
  • Le spec.ports[0].port du deuxième service est le port TCP 80, spec.ports[1].port est le port TCP 90, et son spec.loadBalancerSourceRanges=[172.16.0.0/24]. L'équilibreur de charge correspondant à ce service possède l'adresse IP 198.51.100.3.

GKE crée deux règles de pare-feu d'autorisation d'entrée dans le réseau cloud privé virtuel du cluster. Les deux règles de pare-feu spécifient tous les nœuds du cluster en tant que cibles :

  • La première règle de pare-feu autorise les paquets vers le port de destination TCP 80 à partir de la source 100.10.0.0/16.
  • La seconde règle de pare-feu autorise les paquets vers les ports de destination TCP 80 et 90 à partir de la source 172.16.0.0/24.

La première règle de transfert achemine le trafic correspondant à la destination 192.0.2.2:80. La deuxième règle de transfert achemine le trafic correspondant à la fois aux destinations 198.51.100.3:80 et 198.51.100.3:90. Les trois destinations suivantes sont valides sur chaque nœud : 192.0.2.2:80, 198.51.100.3:80 et 198.51.100.3:90. Le service s'occupe des opérations suivantes :

  • Les deux services acceptent les paquets vers le port TCP 80 depuis l'union des plages sources d'adresses IP, à partir de 100.10.0.0/16 ou de 172.16.0.0/24.
  • Le second service accepte les paquets vers le port TCP 90 à partir de 172.16.0.0/24.

L'ensemble effectif de plages sources pour tous les services utilisant la même combinaison de protocole et de port devient toutes les adresses IP si spec.loadBalancerSourceRanges est omis sur au moins un service utilisant cette combinaison de protocole et de port de destination. Par exemple, si le second service omet spec.loadBalancerSourceRanges, la source du deuxième pare-feu est 0.0.0.0/0 et :

  • Les deux services acceptent les paquets vers le port TCP 80 depuis l'union des plages sources d'adresses IP, de 100.10.0.0/16 ou de 0.0.0.0/0. Étant donné que la plage 0.0.0.0/0 inclut la plage 100.10.0.0/16, la source effective des paquets vers le port TCP 80 est n'importe quelle adresse IP.
  • Le second service accepte les paquets vers le port TCP 90 depuis 0.0.0.0/0 (n'importe quelle adresse IP).

Adresses IP statiques

Vous pouvez créer une adresse IP statique et configurer GKE pour l'attribuer à la règle de transfert de l'équilibreur de charge. L'utilisation d'une adresse IP statique garantit que l'adresse IP de l'équilibreur de charge reste la même, même si vous apportez des modifications au service LoadBalancer. Sans adresse IP statique, GKE peut attribuer une adresse IP différente à la règle de transfert de l'équilibreur de charge lorsque vous mettez à jour un service LoadBalancer. L'adresse IP de la règle de transfert n'est pas identique à l'adresse IP du service spec.clusterIP. L'adresse ClusterIP d'un service ne change jamais lorsque vous mettez à jour un service LoadBalancer.

Paramètres d'adresse IP statique

Pour indiquer à un service LoadBalancer d'utiliser une adresse IP statique, utilisez le paramètre spec.loadBalancerIP ou l'annotation networking.gke.io/load-balancer-ip-addresses. Dans GKE 1.29 et versions ultérieures, l'annotation est prioritaire sur spec.loadBalancerIP si le fichier manifeste du service contient à la fois le paramètre et l'annotation.

Paramètre ou annotation et valeur Conditions requises et fonctionnalités
spec.loadBalancerIP:
IPv4_ADDRESS

Vous pouvez spécifier une adresse IPv4 interne statique pour un service LoadBalancer interne IPv4 uniquement. Vous pouvez spécifier une adresse IPv4 externe statique pour un service LoadBalancer externe IPv4 uniquement. Le paramètre fonctionne avec toutes les versions de GKE compatibles.

networking.gke.io/load-balancer-ip-addresses:
IP_ADDRESS_RESOURCE_NAME
  • Pour les services LoadBalancer à pile unique, définissez la valeur de l'annotation sur le nom de la ressource d'adresse IPv4 ou IPv6, et non sur l'adresse IP elle-même.
  • Pour les services LoadBalancer à double pile, définissez la valeur de l'annotation sur le nom de ressource de l'adresse IPv4 statique et sur le nom de la ressource de la plage d'adresses IPv6 statique, séparés par une virgule.

Vous pouvez spécifier une adresse IPv4 statique, une plage d'adresses IPv6 statique ou les deux pour les services LoadBalancer internes et externes à double pile, IPv4 uniquement et IPv6 uniquement. L'annotation nécessite GKE 1.29 ou une version ultérieure, ainsi que les exigences supplémentaires suivantes:

  • Pour utiliser cette annotation avec un service LoadBalancer interne, vous devez créer le service LoadBalancer interne dans un cluster après avoir activé le sous-paramètre GKE.
  • Pour utiliser cette annotation avec un service LoadBalancer externe, vous devez inclure l'annotation cloud.google.com/l4-rbs: "enabled" dans le fichier manifeste du service lorsque vous créez le service LoadBalancer externe.

Éléments à prendre en compte pour le partage d'une adresse IP commune

Deux services LoadBalancer ou plus peuvent faire référence à la même adresse IP statique si la règle de transfert de chaque équilibreur de charge utilise une combinaison unique d'adresse IP, de protocole, de spécification de port et de spécification de niveaux de service réseau, comme indiqué dans le tableau de cette section. De plus :

  • Les adresses IPv6 statiques sont en fait des plages d'adresses IPv6 /96, mais GKE configure les nœuds pour qu'ils acceptent les paquets sur la première adresse IPv6 (/128) de la plage /96.

  • Pour qu'au moins deux services LoadBalancer internes utilisent la même adresse IPv4 interne ou la même plage d'adresses IPv6 interne, l'adresse IP statique doit être créée avec l'objectif SHARED_LOADBALANCER_VIP.

Service LoadBalancer interne Service LoadBalancer externe
Spécification du port

Les règles de transfert des équilibreurs de charge réseau passthrough internes acceptent jusqu'à cinq numéros de port distincts, ou peuvent être configurées pour utiliser tous les ports.

Lorsqu'un service LoadBalancer interne dispose d'au moins six spec.ports[] spécifiés, GKE configure la règle de transfert pour que l'équilibreur de charge réseau passthrough interne utilise tous les ports.

Lorsqu'une règle de transfert utilise tous les ports, aucune autre règle de transfert (par conséquent, aucun autre service LoadBalancer interne) ne peut utiliser la même adresse IP.

GKE crée un équilibreur de charge réseau passthrough externe basé sur un pool cible si le fichier manifeste du service LoadBalancer ne contient pas l'annotation cloud.google.com/l4-rbs: "enabled".

Les règles de transfert des équilibreurs de charge réseau passthrough externes basés sur un pool cible doivent utiliser des plages de ports contiguës. La plage de ports contigus inclut tous les ports dont le service a besoin, mais elle peut également inclure des ports supplémentaires non utilisés par le service. Par exemple, un service LoadBalancer externe fourni par un équilibreur de charge réseau passthrough externe basé sur un pool cible, qui spécifie les ports 80 et 443 dans son fichier manifeste de service, utilise une règle de transfert d'équilibreur de charge avec une plage de ports de 80 à 443. Cette plage de ports empêche d'autres services LoadBalancer externes d'utiliser les ports 80 et 443, ainsi que les numéros compris entre 80 et 443.

GKE crée un équilibreur de charge réseau passthrough externe basé sur un service de backend si le fichier manifeste du service LoadBalancer inclut l'annotation cloud.google.com/l4-rbs: "enabled". Les règles de transfert des équilibreurs de charge réseau passthrough externes basés sur un service de backend acceptent jusqu'à cinq numéros de port distincts, une plage de ports contiguë, ou elles peuvent être configurées pour utiliser tous les ports.

Niveaux de service réseau Non configurable : les adresses internes sont toujours associées au niveau Premium.

Configurable pour les adresses IPv4 externes régionales statiques. Les plages d'adresses IPv6 externes statiques régionales ne peuvent être créées qu'avec le niveau Premium.

La spécification des niveaux de service réseau de l'adresse IP externe statique doit correspondre à l'un des éléments suivants:

  • Le niveau spécifié dans l'annotation cloud.google.com/network-tier du fichier manifeste du service LoadBalancer, si cette annotation est présente dans le fichier manifeste, ou
  • Niveau par défaut du projet, si l'annotation cloud.google.com/network-tier est absente du fichier manifeste du service LoadBalancer.

Le niveau par défaut du projet est Premium, sauf si vous l'avez configuré différemment.

Sous-réseau d'équilibreur de charge

Vous pouvez configurer un service LoadBalancer interne pour utiliser une adresse IPv4 éphémère ou statique, une plage d'adresses IPv6 ou les deux, dans un sous-réseau personnalisé situé dans la même région et sur le même réseau VPC que le cluster. Utiliser un sous-réseau personnalisé pour un service LoadBalancer interne afin d'effectuer les opérations suivantes:

  • Regrouper les équilibreurs de charge réseau passthrough internes créés par des services LoadBalancer internes à partir de deux clusters GKE ou plus dans le même réseau VPC et la même région.
  • Créer des services LoadBalancer internes dont les équilibreurs de charge réseau passthrough internes ont des adresses IPv4 distinctes des adresses IPv4 des nœuds du cluster.
  • Dans un cluster à deux piles, créez des services LoadBalancer internes dont les équilibreurs de charge réseau passthrough internes disposent de plages d'adresses IPv6 distinctes des adresses IPv6 de nœud et de pod du cluster. Un sous-réseau LoadBalancer personnalisé est obligatoire pour prendre en charge les services LoadBalancer internes si le sous-réseau du cluster possède une plage d'adresses IPv6 externe.

Vous pouvez configurer un service LoadBalancer externe pour utiliser une plage d'adresses IPv6 éphémère ou statique dans un sous-réseau personnalisé situé dans la même région et sur le même réseau VPC que le cluster. Utilisez un sous-réseau personnalisé pour créer des services LoadBalancer externes dont les équilibreurs de charge réseau passthrough externes disposent de plages d'adresses IPv6 distinctes des adresses IPv6 de nœud et de pod du cluster. Un sous-réseau LoadBalancer personnalisé est obligatoire pour prendre en charge les services LoadBalancer externes dans un cluster privé à double pile, car le sous-réseau du cluster possède une plage d'adresses IPv6 internes.

Annotations de sous-réseau personnalisé

Utilisez l'une des annotations suivantes pour indiquer à un service LoadBalancer d'utiliser une adresse IP éphémère ou statique dans un sous-réseau personnalisé. Si un fichier manifeste d'un service LoadBalancer inclut les deux annotations, l'annotation networking.gke.io/load-balancer-subnet est prioritaire tant que ses exigences d'annotation sont remplies.

Annotation et valeur Conditions requises et fonctionnalités
networking.gke.io/internal-load-balancer-subnet:
SUBNET_RESOURCE_NAME

Vous ne pouvez utiliser l'annotation que pour spécifier un sous-réseau personnalisé pour un service LoadBalancer interne IPv4 uniquement. L'annotation fonctionne avec toutes les versions de GKE compatibles.

networking.gke.io/load-balancer-subnet:
SUBNET_RESOURCE_NAME

Vous pouvez spécifier un sous-réseau personnalisé pour un service LoadBalancer interne à double pile, IPv4 uniquement ou IPv6 uniquement. Vous pouvez spécifier un sous-réseau personnalisé pour un service LoadBalancer externe à double pile ou IPv6 uniquement. L'annotation nécessite GKE 1.29 ou une version ultérieure, ainsi que les exigences supplémentaires suivantes:

  • Pour utiliser cette annotation afin de spécifier un sous-réseau personnalisé pour un service LoadBalancer interne, vous devez créer le service LoadBalancer interne dans un cluster après avoir activé le sous-paramètre GKE.
  • Pour utiliser cette annotation afin de spécifier un sous-réseau personnalisé pour un service LoadBalancer externe, vous devez inclure l'annotation cloud.google.com/l4-rbs: "enabled" dans le fichier manifeste du service lorsque vous créez le service LoadBalancer externe.

Sous-réseau et adresse IPv4 pour un service LoadBalancer interne

Le tableau ci-dessous décrit les combinaisons de spécifications de sous-réseau et d'adresses IPv4 valides pour un service LoadBalancer interne à double pile ou IPv4 uniquement.

Adresse IPv4 statique Adresse IPv4 éphémère
Sous-réseau personnalisé
Sous-réseau personnalisé et adresse IPv4 statique: l'adresse IPv4 interne statique doit avoir été créée dans la plage d'adresses IPv4 principale du sous-réseau personnalisé. Sous-réseau personnalisé et adresse IPv4 éphémère: GKE utilise une adresse IPv4 interne non allouée dans la plage d'adresses IPv4 principale du sous-réseau personnalisé.
Sous-réseau de cluster Sous-réseau de cluster et adresse IPv4 statique: l'adresse IPv4 interne statique doit avoir été créée dans la plage d'adresses IPv4 principale du sous-réseau de cluster. Sous-réseau de cluster et adresse IPv4 éphémère: GKE utilise une adresse IPv4 interne non allouée dans la plage d'adresses IPv4 principale du sous-réseau de cluster.

Sous-réseau et plage d'adresses IPv6 pour un service LoadBalancer interne

Le tableau ci-dessous décrit les combinaisons de spécifications de sous-réseau et de plages d'adresses IPv6 valides pour un service LoadBalancer interne à double pile ou IPv6 uniquement. Même si la règle de transfert IPv6 de l'équilibreur de charge réseau interne passthrough utilise une plage d'adresses IPv6 interne /96, GKE ne configure les nœuds que pour accepter les paquets dont les destinations correspondent à la première adresse IPv6 (/128) de la plage /96 de la règle de transfert.

Plage d'adresses IPv6 statiques Plage d'adresses IPv6 éphémère
Sous-réseau à double pile personnalisé
  • Doit se trouver dans le même réseau VPC et dans la même région que le cluster.
  • Doit disposer d'une plage d'adresses IPv6 interne (type d'accès INTERNAL).
  • Doit être spécifié à l'aide de l'annotation networking.gke.io/load-balancer-subnet.
Sous-réseau personnalisé et plage d'adresses IPv6 statique: la plage d'adresses IPv6 interne statique /96 doit avoir été créée dans la plage d'adresses IPv6 /64 internes du sous-réseau personnalisé. Sous-réseau personnalisé et plage d'adresses IPv6 éphémère : GKE utilise une plage d'adresses IPv6 interne /96 non allouée de la plage d'adresses IPv6 interne /64 du sous-réseau personnalisé.
Sous-réseau à double pile du cluster
  • Doit disposer d'une plage d'adresses IPv6 interne (type d'accès INTERNAL).
Sous-réseau de cluster et plage d'adresses IPv6 statique: la plage d'adresses IPv6 interne statique /96 doit avoir été créée dans la plage d'adresses IPv6 /64 internes du sous-réseau de cluster. Sous-réseau de cluster et plage d'adresses IPv6 éphémère : GKE utilise une plage d'adresses IPv6 interne /96 non allouée de la plage d'adresses IPv6 /64 interne du sous-réseau de cluster.

Sous-réseau et adresse IPv4 pour un service LoadBalancer externe

Pour les services LoadBalancer externes IPv4 uniquement et à double pile, l'adresse IPv4 externe, qu'il s'agisse d'une adresse IPv4 externe statique ou d'une adresse IPv4 externe éphémère, ne vient pas. d'un sous-réseau.

Sous-réseau et plage d'adresses IPv6 pour un service LoadBalancer externe

Le tableau ci-dessous décrit les combinaisons valides de spécifications de sous-réseau et de plages d'adresses IPv6 pour un service LoadBalancer externe IPv6 uniquement ou à double pile. Même si la règle de transfert IPv6 de l'équilibreur de charge réseau passthrough externe utilise une plage d'adresses IPv6 /96 externe, GKE ne configure les nœuds que pour accepter les paquets dont les destinations correspondent à la première adresse IPv6 (/128) de la plage /96 de la règle de transfert.

Plage d'adresses IPv6 statiques Plage d'adresses IPv6 éphémère
Sous-réseau à double pile personnalisé
  • Doit se trouver dans le même réseau VPC et dans la même région que le cluster.
  • Doit disposer d'une plage d'adresses IPv6 externe (type d'accès EXTERNAL).
  • Doit être spécifié à l'aide de l'annotation networking.gke.io/load-balancer-subnet.
Sous-réseau personnalisé et plage d'adresses IPv6 statiques: la plage d'adresses IPv6 externe statique /96 doit avoir été créée dans la plage d'adresses IPv6 externes /64 du sous-réseau personnalisé. Les plages d'adresses IPv6 externes statiques ne peuvent être créées qu'avec le niveau Premium. Sous-réseau personnalisé et plage d'adresses IPv6 éphémère : GKE utilise une plage d'adresses IPv6 externe /96 non allouée de la plage d'adresses IPv6 externe /64 du sous-réseau personnalisé.
Sous-réseau à double pile du cluster
  • Doit disposer d'une plage d'adresses IPv6 externe (type d'accès EXTERNAL).
Sous-réseau de cluster et plage d'adresses IPv6 statique: la plage d'adresses IPv6 externe statique /96 doit avoir été créée dans la plage d'adresses IPv6 /64 externe du sous-réseau de cluster. Les plages d'adresses IPv6 externes statiques ne peuvent être créées qu'avec le niveau Premium. Sous-réseau de cluster et plage d'adresses IPv6 éphémère : GKE utilise une plage d'adresses IPv6 externe /96 non allouée, de la plage d'adresses IPv6 /64 externe du sous-réseau de cluster.

Accès mondial

Lorsque l'annotation networking.gke.io/internal-load-balancer-allow-global-access est définie sur false ou non spécifiée pour un service LoadBalancer interne, GKE crée un équilibreur de charge réseau passthrough interne dont l'accès mondial est désactivé pour la règle de transfert. Lorsque l'accès mondial est désactivé, les clients devant accéder à l'équilibreur de charge doivent se trouver dans la même région et sur le même réseau VPC, ou bien un réseau connecté au réseau VPC du cluster.

Lorsque l'annotation networking.gke.io/internal-load-balancer-allow-global-access est définie sur true pour un service LoadBalancer interne, GKE active l'option d'accès mondial sur la règle de transfert de l'équilibreur de charge réseau passthrough interne. Les clients situés dans n'importe quelle région du réseau VPC ou sur un réseau connecté au réseau VPC du cluster peuvent accéder à l'équilibreur de charge.

Pour en savoir plus sur l'accès mondial qui s'applique aux clients d'un réseau connecté, consultez les pages suivantes :

Toutes les règles de transfert de ports

Les règles de transfert des équilibreurs de charge réseau passthrough internes acceptent cinq numéros de port uniques ou bien l'ensemble des ports.

Dans les clusters GKE avec le sous-paramètre GKE désactivé, un service LoadBalancer interne ne peut utiliser que cinq ports uniques dans le spec.ports[].port du service.

Dans les clusters GKE avec le sous-paramètre GKE activé, un service LoadBalancer interne ne peut accepter que 100 ports dans le spec.ports[].port du service. Pour les services LoadBalancer internes comportant entre six et 100 entrées spec.ports[].port uniques, GKE configure la règle de transfert de l'équilibreur de charge réseau passthrough interne afin d'utiliser tous les ports depuis sa création. Le contrôleur GKE active tous les ports de la règle de transfert, car le service dispose de plus de cinq ports. Lors de la configuration d'une règle de transfert pour utiliser tous les ports, GKE ne crée des règles de pare-feu d'autorisation d'entrée que pour les ports spécifiques configurés dans spec.ports[].port sur le service.

Pour en savoir plus sur les règles de transfert de l'équilibreur de charge réseau passthrough interne et les spécifications de port valides, consultez la page Règles de transfert et spécifications de ports.

Service LoadBalancer à double pile IPv4/IPv6

Vous pouvez créer un service LoadBalancer interne ou externe qui peut être à pile unique (IPv4 seulement ou IPv6 uniquement) ou à double pile. Les services LoadBalancer à pile unique créent une règle de transfert unique avec une adresse IPv4 ou avec une adresse IPv6. Les services LoadBalancer à double pile créent deux règles de transfert : l'une avec une adresse IPv4 et l'autre avec une adresse IPv6. Pour créer un service LoadBalancer à double pile IPv4/IPv6, déployez-le sur un cluster à double pile IPv4/IPv6 et effectuez l'une des opérations suivantes, selon le type d'équilibreur de charge que vous utilisez :

Pour chaque service, vous pouvez définir les spécifications ipFamilyPolicy et ipFamilies. Pour en savoir plus, consultez la page IPv4/IPv6 à double pile.

Restrictions applicables aux services LoadBalancer à double pile

  • Les services LoadBalancer avec des adresses IPv6 ne sont compatibles qu'avec les clusters avec pile de type ipv4-ipv6. Pour en savoir plus, découvrez comment utiliser une adresse IP à double pile pour un cluster de VPC natif.
  • Les services LoadBalancer créés avec une adresse à simple pile ne peuvent pas être mis à niveau vers des services à double pile.

  • Les services LoadBalancer créés avec des adresses à double pile peuvent passer en mode à pile unique conformément aux conditions suivantes :

    • Un service avec ipFamilies ["IPv4","IPv6"] peut devenir un service avec ipFamilies IPv4, mais pas IPv6.
    • Un service avec ipFamilies ["IPv6","IPv4"] peut devenir un service avec ipFamilies IPv6, mais pas IPv4.