Clusters de VPC natif

Cette page présente les clusters de VPC natif dans Google Kubernetes Engine (GKE).

Cette page s'adresse aux architectes cloud et aux spécialistes de la mise en réseau qui conçoivent et implémentent le réseau pour leur organisation. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud, consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Présentation

GKE comprend deux types de clusters, caractérisés par la manière dont ils acheminent le trafic d'un pod à un autre.

Un cluster qui s'appuie sur des plages d'adresses IP d'alias est appelé cluster de VPC natif.

Un cluster qui utilise des routes statiques personnalisées dans un réseau VPC est appelé cluster basé sur le routage.

Avantages des clusters de VPC natif

Les clusters de VPC natif présentent plusieurs avantages :

• Les adresses IP des pods sont nativement routables au sein du réseau VPC du cluster et sur les autres réseaux VPC qui y sont connectés via l'appairage de réseaux VPC.

• Les adresses IP des pods sont réservées sur le réseau VPC avant la création des pods dans votre cluster. Cela évite tout conflit avec d'autres ressources sur le réseau VPC et vous permet de mieux planifier les attributions d'adresses IP.

• Les plages d'adresses IP des pods sont indépendantes des routes statiques personnalisées. Ces plages ne sont pas prises en compte dans le quota de routes statiques personnalisées et générées par le système. En effet, pour les clusters de VPC natif, ce sont les routes de sous-réseau générées automatiquement qui gèrent le routage.

• Vous pouvez créer des règles de pare-feu qui ne s'appliquent qu'aux plages d'adresses IP des pods et non aux adresses IP des nœuds du cluster.

• Les plages d'adresses IP des pods et les plages d'adresses IP secondaires des sous-réseaux en général sont accessibles à partir de réseaux sur site connectés à Cloud VPN ou Cloud Interconnect à l'aide des routeurs Cloud.

• Certaines fonctionnalités, telles que les groupes de points de terminaison du réseau (NEG), ne fonctionnent qu'avec les clusters de VPC natif.

Mode de réseau du cluster par défaut

Le VPC natif est le mode de réseau par défaut pour tous les clusters des versions 1.21.0-gke.1500 et ultérieures de GKE. Pour les versions antérieures, le mode de réseau du cluster par défaut dépend de la façon dont vous créez le cluster.

Le tableau suivant répertorie le mode de réseau du cluster par défaut pour les versions de cluster GKE et les méthodes de création de cluster.

Vous pouvez également créer un cluster basé sur le routage en spécifiant l'option --no-enable-ip-alias lors de la création du cluster.

Plages d'adresses IP pour les clusters de VPC natif

Lorsque vous créez un cluster de VPC natif, vous spécifiez un sous-réseau dans un réseau VPC. Le cluster utilise les plages d'adresses IP de sous-réseau suivantes :

Attribution d'adresses IPv4

Les clusters de VPC natif allouent des adresses IPv4 pour les nœuds, les pods et les services à l'aide de plages distinctes dans le sous-réseau spécifié, comme suit.

• Adresses IP de nœud : le cluster utilise la plage d'adresses IPv4 principale du sous-réseau pour attribuer des adresses IP à tous les nœuds.

• Adresses IP de pod : le cluster utilise la plage d'adresses IPv4 secondaire du sous-réseau pour toutes les adresses IPv4 de pods du cluster. Pour plus de flexibilité, vous pouvez utiliser des plages d'adresses IPv4 secondaires de sous-réseau supplémentaires en configurant le CIDR multipod non contigu.

• Adresses IP de service : le cluster utilise une plage d'adresses IP secondaire distincte pour toutes les adresses de services (ClusterIP). Pour savoir comment permettre à plusieurs clusters de partager la même plage IPv4 pour les services, consultez la page Partager des plages d'adresses IP entre clusters GKE.

Allocation d'adresses IPv6 (mise en réseau à double pile)

• Adresses IPv6 des nœuds et des pods : dans les clusters avec mise en réseau à double pile, l'adresse IPv6 du nœud et toutes les adresses IPv6 des pods proviennent de la plage d'adresses IPv6 /96 désignée du nœud. L'adresse IP du nœud lui-même est la première /128 (adresse IPv6 unique) de cette plage. Pour en savoir plus, consultez la section Mise en réseau à double pile.

Le tableau suivant récapitule les plages d'adresses IP pour les nœuds, les pods et les services :

Adresses IP internes

Les adresses IP que vous utilisez pour les sous-réseaux de votre cluster de VPC natif doivent provenir d'une plage de sous-réseaux valide. Les plages valides incluent des adresses IP privées (RFC 1918 et d'autres adresses) et des adresses IP publiques réutilisées en mode privé. Pour plus d'informations sur les plages de sous-réseaux valides, consultez les pages Plages valides et Plages restreintes de la documentation sur les VPC.

Consultez la section Utiliser des plages d'adresses IP privées non-RFC 1918 pour obtenir des instructions sur l'activation de ces plages.

Consultez la section Activer les plages d'adresses IP publiques utilisées en mode privé afin d'obtenir des instructions sur l'utilisation de ces plages.

Méthodes d'attribution de plages secondaires

Vous pouvez attribuer des plages d'adresses IP de pods et des plages d'adresses de services (ClusterIP) à un cluster de VPC natif. Ces plages d'adresses IP peuvent être gérées par GKE ou par l'utilisateur.

Vous devez connaître les termes clés suivants pour comprendre les méthodes d'attribution de plages secondaires.

Attribution : l'attribution de plages d'adresses IP fait référence au processus d'allocation d'une plage de sous-réseau spécifique à un cluster de VPC natif. Cela établit un pool d'adresses IP que les composants peuvent utiliser dans le cluster, tels que les pods et les services.

Gestion : la gestion de la plage d'adresses IP fait référence aux opérations CRUD en cours (création, mise à jour, suppression, lecture) au niveau du cluster, du pool de nœuds ou du pod, en rapport avec les plages de sous-réseaux attribuées et l'allocation des ressources au sein de votre cluster de VPC natif.

Plages secondaires gérées par GKE (par défaut)

Pour les clusters Autopilot GKE exécutant la version 1.27 ou une version ultérieure et les clusters GKE Standard exécutant les versions 1.29 ou ultérieures, GKE attribue par défaut les adresses IP des services à partir d'une plage gérée par GKE : 34.118.224.0/20. Cela vous évite de spécifier votre propre plage d'adresses IP pour les services. Les considérations suivantes s'appliquent :

• Vous pouvez éventuellement spécifier des plages personnalisées pour les services à l'aide de l'option --services-ipv4-cidr.
• Si vous ne spécifiez qu'une taille de plage à l'aide de l'option --services-ipv4-cidr (par exemple, /22), GKE utilise toujours la plage gérée par Google pour obtenir la sous-plage de la plage d'adresses.
• GKE ne crée pas de plage d'adresses IP secondaire distincte pour les services lorsque la plage gérée par GKE est utilisée.

Gestion par l'utilisateur

Pour un contrôle total sur l'attribution d'adresses IP, vous pouvez gérer manuellement les sous-réseaux de votre cluster de VPC natif.

Vous pouvez créer les plages d'adresses IP secondaires du sous-réseau, puis créer un cluster qui utilise ces plages. Lors de la création du cluster, spécifiez le nom de plage de sous-réseau pour les pods et les services. Si vous créez manuellement les plages secondaires, vous devez les gérer vous-même.

La plus petite plage d'adresses IP que vous pouvez créer sans utiliser de CIDR multipods non contigu est la plage /28, mais cette plage ne vous permettra de créer qu'un seul nœud avec un maximum de 8 pods Vous devez utiliser une plage suffisamment grande pour le nombre maximal de nœuds dont vous avez besoin.

La plage minimale utilisable dépend également du nombre maximal de pods par nœud.

Reportez-vous au tableau de la section Optimiser l'allocation d'adresses IP pour connaître la plage CIDR minimale utilisable pour différentes valeurs du nombre maximal de pods par nœud.

Si vous épuisez votre plage d'adresses IP pour les pods, vous devez effectuer l'une des opérations suivantes :

• Créer un cluster avec une plage d'adresses de pods plus étendue.
• Recréer vos pools de nœuds après avoir réduit la capacité --max-pods-per-node pour les pools de nœuds.
• Étendre la plage d'adresses IP secondaire des pods à l'aide d'un CIDR multipods non contigu.

Différences avec les clusters basés sur le routage

Le schéma d'attribution des adresses de pod et de service (ClusterIP) est différent de celui utilisé dans un cluster basé sur le routage. Au lieu de spécifier un seul CIDR pour les pods et les services, vous devez choisir ou créer deux plages d'adresses IP secondaires dans le sous-réseau du cluster : une pour les pods et une pour les services.

Considérations relatives au VPC partagé

Lors de la création d'un cluster de VPC natif dans un environnement VPC partagé, un propriétaire de projet, un éditeur ou un compte principal IAM (Identity and Access Management) disposant du rôle d'administrateur réseau dans le projet hôte du VPC partagé doit créer le sous-réseau et les plages d'adresses IP secondaires du cluster manuellement. Un administrateur de projet de service qui crée un cluster doit au moins disposer des autorisations au niveau du sous-réseau pour le sous-réseau dans le projet hôte du réseau VPC partagé.

Dans un environnement VPC partagé, les plages d'adresses IP secondaires ne peuvent pas être gérées par GKE. Un administrateur réseau du projet hôte de VPC partagé doit créer le sous-réseau et les plages d'adresses IP secondaires avant de pouvoir créer le cluster. Pour obtenir un exemple de configuration d'un cluster de VPC natif dans un réseau VPC partagé, reportez-vous à la section Configurer des clusters avec un VPC partagé.

Planifier des plages d'adresses IP

Utilisez les informations figurant dans les sections suivantes pour calculer les tailles des plages d'adresses IP principale et secondaire du sous-réseau utilisé par votre cluster.

Plage d'adresses IP principale du sous-réseau

Tenez compte des conditions suivantes lorsque vous planifiez la plage d'adresses IP de votre nœud principal :

• Chaque sous-réseau doit avoir une plage d'adresses IP principale. Il s'agit de la plage d'adresses IP utilisée par GKE pour allouer des adresses IP aux équilibreurs de charge internes et aux nœuds.
• Vous ne pouvez pas réduire ni modifier la plage d'adresses IP principale d'un sous-réseau une fois celui-ci créé.
• Les deux premières et les deux dernières adresses IP d'une plage d'adresses IP principale sont réservées à Google Cloud.
• Par défaut, les clusters dotés de Private Service Connect utilisent la plage de sous-réseaux principale pour provisionner l'adresse IP interne attribuée au point de terminaison du plan de contrôle. Toutefois, vous pouvez ignorer ce provisionnement d'adresse IP à l'aide de l'indicateur private-endpoint-subnetwork. Pour en savoir plus, consultez la section Créer un cluster et sélectionner la plage d'adresses IP du plan de contrôle.

Le tableau suivant indique le nombre maximal de nœuds que vous pouvez créer en fonction de la taille de la plage d'adresses IP principale du sous-réseau et de la configuration du cluster :

• Scénario 1 : Nombre maximal de nœuds dans un cluster utilisant le sous-réseau par défaut.
• Scénario 2 : nombre maximal de nœuds dans un cluster Private Service Connect qui n'utilisent pas l'indicateur private-endpoint-subnetwork.

Étendre la plage d'adresses IP principale

Si vous n'avez plus d'adresses IP dans la plage d'adresses IP principale, vous pouvez étendre la plage d'adresses IP principale à tout moment, même lorsque des ressources Google Cloud, telles que des équilibreurs de charge et des groupes de points de terminaison du réseau, utilisent le sous-réseau.

Avant d'étendre la plage d'adresses IP principale, tenez compte des points suivants :

• Le sous-réseau ne doit pas comporter de plages d'adresses IP qui se chevauchent.
• GKE utilise la plage d'adresses IP principale pour allouer des adresses IP aux équilibreurs de charge internes et aux nœuds.

Formules utiles

Vous pouvez utiliser les formules suivantes pour calculer :

• le nombre maximal de nœuds, N, qu'un masque de réseau donné peut accepter dans les clusters qui utilisent le sous-réseau par défaut. S indique la taille du masque de réseau dont la plage valide est comprise entre 8 et 29 inclus.

  N = 2^{(32 -S)} - 4

• la taille du masque de réseau, S, nécessaire pour pouvoir accepter le nombre maximal de nœuds N :

  S = 32 - ⌈log₂(N + 4)⌉

  ⌈⌉ correspond à la fonction plafond (le plus petit entier), soit la valeur arrondie au nombre entier supérieur. La plage valide pour la taille du masque de réseau, S, est comprise entre 8 et 29 inclus.

Dans les clusters Private Service Connect qui n'utilisent pas l'indicateur private-endpoint-subnetwork, vous pouvez utiliser les formules précédentes, mais réduire la valeur de N de 1.

Plage d'adresses IP secondaire du sous-réseau utilisée par les pods

Soyez attentif lorsque vous planifiez votre plage d'adresses IP secondaire pour les pods.

Le tableau suivant indique le nombre maximal de nœuds et de pods que vous pouvez créer dans tous les clusters utilisant le sous-réseau, en fonction de la plage d'adresses IP secondaire utilisée par les pods.

Ce tableau suppose que le nombre maximal de pods par nœud est de 110, ce qui correspond à la densité de pod par défaut.

Si vous avez modifié le nombre maximal de pods par nœud, utilisez les formules suivantes pour calculer le nombre maximal de nœuds et de pods qu'une plage d'adresses IP secondaire d'un sous-réseau pour les pods peut accepter :

1. Calculez la taille du masque de réseau de la plage de pods de chaque nœud, M.
   M = 31 - ⌈log2(Q)⌉ où :

   • Q correspond au nombre de pods par nœud.
   • ⌈⌉ est le plafond, soit la valeur arrondie au nombre entier supérieur.
   • Par exemple, si Q est égal à 110, alors M = 24

2. Calculez le nombre maximal de nœuds, N, que la plage d'adresses IP secondaire du sous-réseau pour les pods peut accepter :
   N = 2(M - S) , où :

   • M correspond à la taille du masque de réseau de la plage d'adresses IP d'alias de chaque nœud pour les pods, calculée à la première étape.
   • S correspond à la taille du masque de sous-réseau de la plage d'adresses IP secondaire du sous-réseau.
   • Par exemple, si M est égal à 24 et S à 20, alors N = 16

3. Calculez le nombre maximal de pods, P, que la plage d'adresses IP secondaire du sous-réseau pour les pods peut accepter :
   P = N × Q , où :

   • N correspond au nombre maximal de nœuds, calculé à l'étape précédente.
   • Q correspond au nombre de pods par nœud.
   • Par exemple, si N est égal à 16 et Q à 110, alors P = 1760

Vous pouvez ajouter d'autres adresses IP pour les pods en utilisant un CIDR multipods non contigu.

Plage d'adresses IP secondaire du sous-réseau utilisée par les services

Soyez attentif lorsque vous planifiez votre plage d'adresses IP secondaire pour les services. Comme il s'agit également d'une plage d'adresses IP secondaire de sous-réseau, cette plage ne peut pas être modifiée une fois le cluster créé.

Si vous utilisez des services multiclusters, l'objet ServiceImport utilise des adresses IP de la plage d'adresses IP secondaire pour les services.

Dans les clusters GKE Autopilot exécutant la version 1.27 ou une version ultérieure, et les clusters GKE Standard exécutant la version 1.29 ou une version ultérieure, GKE attribue par défaut les adresses IP des services à partir d'une plage gérée par GKE : 34.118.224.0/20. Cela vous évite de spécifier votre propre plage d'adresses IP pour les services. Les considérations suivantes s'appliquent :

• Vous pouvez éventuellement spécifier des plages personnalisées pour les services à l'aide de l'option --services-ipv4-cidr ou de l'option --services-secondary-range-name.
• Si vous ne spécifiez qu'une taille de plage à l'aide de l'option --services-ipv4-cidr (par exemple, /22), GKE utilise toujours la plage gérée par Google pour obtenir la sous-plage de la plage d'adresses.
• GKE ne crée pas de plage d'adresses IP secondaire distincte pour les services lorsque la plage gérée par Google est utilisée. La plage gérée par GKE n'utilise pas le quota de plages d'adresses IP secondaires pour votre sous-réseau.

Le tableau suivant indique le nombre maximal de services que vous pouvez créer dans un seul cluster à l'aide du sous-réseau, en fonction de la plage d'adresses IP secondaire du sous-réseau réservée aux services.

Partager des plages d'adresses IP entre plusieurs clusters GKE

Vous pouvez partager la plage principale, la plage d'adresses IP secondaire utilisée par les pods et la plage d'adresses IP secondaire utilisée par les services entre les clusters d'un même sous-réseau.

Ce comportement est disponible pour les clusters standards et Autopilot.

Vous pouvez souhaiter partager des plages d'adresses IP si vous disposez d'une équipe centralisée qui gère l'infrastructure des clusters. Vous pouvez réduire les coûts en créant trois plages, respectivement pour les pods, les services et les nœuds, et en les réutilisant ou en les partageant, en particulier dans un modèle de VPC partagé. Cela facilite également la gestion des adresses IP par les administrateurs réseau, en leur évitant d'avoir à créer des sous-réseaux spécifiques pour chaque cluster.

Partager la plage d'adresses IP principale utilisée par les nœuds

Si vous créez plusieurs clusters dans le sous-réseau, la plage d'adresses IP principale des nœuds est partagée par défaut.

Le partage de la plage d'adresses IP principale utilisée par les nœuds présente les limites suivantes :

• Si vous partagez la plage d'adresses IP principale utilisée par les nœuds avec deux clusters de VPC natif ou plus, l'un des clusters peut utiliser une grande partie de la plage d'adresses IP partagée, laissant les autres clusters sans une quantité suffisante d'adresses IP pour leur expansion.

Partager la plage d'adresses IP secondaire utilisée par les pods

Lorsque vous partagez la plage secondaire utilisée par les pods, chaque pod obtient toujours une adresse IP unique.

Le partage de la plage d'adresses IP secondaire utilisée par les pods présente les limites suivantes :

• Si vous partagez la plage d'adresses IP secondaire utilisée par les pods avec deux clusters de VPC natif ou plus, l'un des clusters peut utiliser une grande partie de la plage d'adresses IP partagée, laissant les autres clusters sans une quantité suffisante d'adresses IP pour leur expansion.

• Parmi les différents types de plages secondaires, les plages de pods supplémentaires et gérées par GKE ne peuvent pas être partagées entre les clusters.

• Pour partager une plage d'adresses IP secondaire, transmettez-la via la ligne de commande à l'aide de --cluster-secondary-range. Vous ne pouvez pas utiliser une plage secondaire partagée lors de la création de clusters dans l'interface utilisateur.

Partager la plage d'adresses IP secondaire utilisée par les services

Deux clusters ou plus peuvent utiliser simultanément la même plage d'adresses IPv4 secondaire de sous-réseau pour les services lorsque vous utilisez des plages secondaires gérées par l'utilisateur.

Pour configurer au moins deux clusters afin de partager une plage d'adresses IPv4 secondaire de sous-réseau commune pour les services, utilisez la même plage d'adresses IPv4 secondaire de sous-réseau lorsque vous créez chaque cluster. Aucune option de configuration distincte n'est requise pour partager une plage d'adresses IPv4 commune pour les services.

Lors du partage d'une plage d'adresses IPv4 commune pour les services, chaque cluster utilise la plage d'adresses IPv4 secondaire de sous-réseau entière pour les services en interne. Les adresses IP pour les services sont programmées dans le nœud de chaque cluster, mais elles ne sont attribuées à l'interface réseau d'aucun nœud. Les adresses IP de services ne peuvent pas être routées dans le réseau VPC du cluster. Les adresses IP de services ne peuvent être utilisées que par les pods clients situés dans le même cluster que le service.

Lorsqu'un pod envoie un paquet à une adresse IP de services, la configuration iptables ou eBPF sur le nœud effectue la traduction d'adresse réseau (NAT, Network Address Translation) de destination, avec pour effet de faire passer l'adresse IP de destination du paquet de l'adresse IP de services à une adresse IP de pod de diffusion. Le paquet est acheminé en fonction de l'adresse IP du pod de destination.

Le partage de la plage d'adresses IP secondaire utilisée par les services offre les avantages suivants :

• Réduire le nombre de plages d'adresses IP secondaires uniques pour les services créés sur un sous-réseau
• Utiliser moins d'adresses IP

Le partage de la plage d'adresses IP secondaire utilisée par les services présente les limites suivantes :

• Le partage de la plage d'adresses IP secondaire utilisée par les services n'est pas compatible avec le champ d'application VPC Cloud DNS pour GKE.

• Vous ne pouvez pas partager des plages correspondant à l'expression régulière suivante :

  ^gke-.*-services-[abcdef0-9]{8}
  

• Pour partager une plage d'adresses IP secondaire utilisée par les services, transmettez-la via la ligne de commande à l'aide de --cluster-secondary-range. Vous ne pouvez pas utiliser une plage secondaire partagée pour les services lors de la création de clusters dans l'interface utilisateur.

Plages de limites de nœud

Le nombre maximal de pods et de services qu'un cluster GKE donné peut utiliser est limité par la taille des plages d'adresses IP secondaires du cluster. Le nombre maximal de nœuds dans le cluster est limité par la plage d'adresses IP principale du sous-réseau du cluster et la plage d'adresses IP des pods du cluster.

Le message d'erreur suivant indique que la plage d'adresses IP principale du sous-réseau ou la plage d'adresses IP des pods du cluster (la plage d'adresses IP secondaire du sous-réseau réservée aux pods) est épuisée :

Instance [node name] creation failed: IP space of [cluster subnet] is
exhausted

Vous pouvez ajouter d'autres adresses IP destinées aux nœuds en développant le sous-réseau principal ou en ajoutant de nouvelles adresses IP destinées aux pods à l'aide d'un CIDR multipod discontinu. Pour en savoir plus, consultez la section Pas assez d'espace d'adresses IP libre pour les pods.

Mise en réseau de la double pile IPv4/IPv6

Avec la mise en réseau à double pile IPv4/IPv6, vous pouvez définir la façon dont GKE alloue les adresses IP (ipFamilies) aux objets suivants :

• Pour les pods et les nœuds, GKE attribue des adresses IPv4 et IPv6.
• Pour les services, GKE attribue des adresses à simple pile (IPv4 uniquement ou IPv6 uniquement) ou à double pile.

Dans GKE version 1.24 ou ultérieure, vous pouvez activer la mise en réseau à double pile pour les nouveaux clusters GKE sur les réseaux VPC autonomes et partagés. Vous pouvez également appliquer des règles de réseau lorsque la mise en réseau à double pile est activée.

Avantages

La mise en réseau à double pile offre les avantages suivants :

• Permet une communication IPv6 de bout en bout.
• Permet de meilleures performances par rapport à la traduction d'adresse réseau (NAT) ou à la tunnelisation IP. Cela est dû à l'absence de traduction IPv6 vers IPv4.

Disponibilité

La mise en réseau à double pile avec GKE présente les restrictions suivantes :

• La mise en réseau à double pile n'est disponible que pour les clusters de VPC natif sur lesquels GKE Dataplane V2 est activé.
• La mise en réseau à double pile n'est possible que sur les sous-réseaux des VPC en mode personnalisé. Pour plus d'informations, consultez la section Types de réseaux VPC Google Cloud.
• Les adresses IPv6 à pile unique ne sont pas prises en charge pour les pods ou les nœuds.
• Les clusters à double pile consomment de la mémoire supplémentaire par nœud pour prendre en charge les clusters IPv4 et IPv6 plutôt que les clusters IPv4 uniquement. Tenez compte de cette caractéristique lorsque vous configurez des clusters à grande échelle.
• Les clusters à double pile ne sont pas compatibles avec l'accès privé à Google sur IPv6.
• Les versions 1.26.0-gke.2200 et ultérieures de GKE sont compatibles avec les enregistrements IPv6 (enregistrements AAAA) avec Cloud DNS pour les opérations internes au cluster et les requêtes DNS externes.
• Les services à double pile sont compatibles avec les services ClusterIP, NodePort et LoadBalancer.

• Le protocole IPv6 n'est pas compatible avec les nœuds Windows.

Tenez compte des restrictions précédentes avant de créer un cluster avec une mise en réseau à double pile. Pour plus d'informations, découvrez comment créer un cluster de VPC natif avec une mise en réseau à double pile.

Attribution d'adresses IPv6 publiques et privées

Le tableau suivant récapitule les adresses IPv6 publiques et privées utilisant un comportement et des configurations de mise en réseau à double pile :

Pour en savoir plus, découvrez comment utiliser un réseau à double pile pour un cluster de VPC natif.

Architecture

Les plages suivantes sont allouées à un cluster avec une mise en réseau à double pile IPv4/IPv6 :

• Une plage /64 pour chaque sous-réseau en tant que plage principale.
• Une plage /96 pour chaque nœud à partir de la plage principale afin de l'utiliser comme plage d'adresses IP de nœud principal.

• Une plage /112 pour chaque nœud à partir de la plage d'adresses IP du nœud principal afin de l'utiliser plage d'adresses IP dédiées aux pods pour ce nœud. Avec la mise en réseau à double pile, les pods obtiennent leurs adresses IPv6 à partir de la plage d'adresses IP globale des pods (semblable aux nœuds), et non de la plage secondaire des pods réservés aux adresses IPv4.

  La plage d'adresses IP globale des pods est composée de plages d'adresses IP qui ne se chevauchent pas. Par conséquent, cette plage d'adresses IP des pods est discontinue.

• Une plage /112 à utiliser pour les services. Cette plage provient d'une plage /64 de la plage d'adresses privée de Google, qui a été réservée pour la plage d'adresses IP secondaire des services de GKE.

Le schéma suivant montre comment Google Cloud et GKE allouent les adresses IPv6 :

Dans le schéma, la plage principale du sous-réseau VPC est 2600:1900:0:1::/64 et la plage réservée des services GKE est 2600:2D00:0:4::0:0/64. Chaque nœud du cluster dispose d'une plage d'adresses IP de taille /96 pour la plage d'adresses IP du nœud principal et d'une plage de taille /112 pour la plage d'adresses IP des pods. Le cluster possède également une plage d'adresses IP secondaire des services de taille /112.

Services

Vous pouvez créer un service à double pile IPv4/IPv6 de type ClusterIP ou NodePort. Les nouveaux clusters GKE exécutant la version 1.29 ou ultérieure sont compatibles avec les services double pile de type LoadBalancer.

Vous pouvez exposer un déploiement avec un service de type ClusterIP, NodePort ou LoadBalancer. Pour chacun de ces types de service, vous pouvez définir les champs ipFamilies et ipFamilyPolicy en tant que service IPv4, IPv6 ou double pile. Pour plus d'informations, consultez un exemple de configuration de déploiement.

Étapes suivantes

• En savoir plus sur l'appairage de réseaux VPC.
• Apprenez à créer un cluster de VPC natif.

• Découvrez les insights sur l'utilisation des adresses IP GKE.