Cette page présente les clusters de VPC natif dans Google Kubernetes Engine (GKE).
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.
Pour les clusters GKE Autopilot, le routage du trafic VPC natif est activé par défaut.
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.
| Versions de GKE | Méthode de création du cluster | Mode de réseau du cluster |
|---|---|---|
| Toutes les versions | Google Cloud Console | VPC natif |
| 1.21.0-gke.1500 et versions ultérieures | API Kubernetes Engine ou Google Cloud CLI | VPC natif |
| Antérieur à 1.21.0-gke.1500 | API Kubernetes Engine ou Google Cloud CLI | Basé sur le routage |
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
/96dé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 :
| Plage | Explication | Exemple |
|---|---|---|
| Nœuds |
Les adresses IP des nœuds sont attribuées à partir de la plage d'adresses IP principale du sous-réseau associé à votre cluster. Les adresses IP des nœuds et la taille de la plage d'adresses IP secondaire du sous-réseau des pods limitent le nombre de nœuds pouvant être acceptés par un cluster. Pour plus d'informations, reportez-vous à la page Plages de limites de nœud. |
Si vous envisagez de créer un cluster de 900 nœuds, la plage d'adresses IP principale du sous-réseau du cluster doit être au moins égale à Pour plus d'informations, reportez-vous aux sections Plage d'adresses IP principale du sous-réseau et Plage d'adresses IP secondaire du sous-réseau utilisée par les pods. |
| Pods |
Les adresses IP de pod sont extraites de la plage d'adresses IP secondaire du sous-réseau du cluster utilisée par les pods. À moins de définir un nombre maximal de pods par nœud différent, GKE attribue une plage d'adresses IP d'alias |
Pour un cluster de 900 nœuds pouvant accepter jusqu'à 110 pods par nœud, vous avez besoin de 900 × 256 = 230 400 adresses IP pour les pods. (Une plage d'adresses IP d'alias dont la taille du masque de réseau est de /24 est attribuée à chaque nœud.) Ce cluster nécessite un sous-réseau dont la plage d'adresses IP secondaire des pods comporte un masque de sous-réseau inférieur ou égal à /14. Cette plage d'adresses IP secondaire fournit 2(32-14) = 218 = 262 144 adresses IP pour les pods. Pour plus d'informations, reportez-vous à la section Plage d'adresses IP secondaire du sous-réseau utilisée par les pods. |
| Services |
Les adresses de services (ClusterIP) sont obtenues à partir de la plage d'adresses IP secondaire du sous-réseau du cluster pour les services. Vous devez vous assurer que cette plage est suffisamment étendue pour contenir les adresses de tous les services Kubernetes que vous hébergez dans votre cluster. Dans les nouveaux clusters Autopilot exécutant la version 1.27 de GKE ou une version ultérieure, GKE attribue par défaut les adresses IP des services GKE à partir d'une plage gérée par Google : |
Pour un cluster qui exécute jusqu'à 3 000 services, vous avez besoin de 3 000 adresses IP de cluster. Vous avez besoin d'une plage secondaire de taille /20 ou plus. Une plage d'adresses IP de taille /20 contient 2(32-20) = 212 = 4 096 adresses IP. Pour plus d'informations, reportez-vous à la page Plage d'adresses IP secondaire du sous-réseau utilisée par 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)
Par défaut, GKE attribue et gère les adresses IP de vos clusters de VPC natif. Lorsque vous créez un cluster, vous n'avez pas besoin de créer un sous-réseau.
Vous pouvez définir une plage CIDR ou la taille d'un masque de réseau pour les pods et les services. GKE gère la création et la gestion des plages de sous-réseaux.
Par exemple, vous pouvez spécifier 10.1.0.0/16 pour les pods et 10.2.0.0/20 pour les services, ou /16 pour les pods et /20 pour les services.
Pour les clusters Autopilot exécutant GKE 1.27 ou une version ultérieure, GKE attribue par défaut les adresses IP des services à partir d'une plage gérée par Google 34.118.224.0/20, ce qui élimine le besoin de spécifier votre propre plage 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 Google est utilisée.
Géré 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-nodepour 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
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.
Le tableau suivant indique le nombre maximal de nœuds que vous pouvez créer dans tous les clusters utilisant le sous-réseau, en fonction de la plage d'adresses IP principale du sous-réseau.
| Plage d'adresses IP principale du sous-réseau | Nombre maximal de nœuds |
|---|---|
| /29 Taille minimale de la plage d'adresses IP principale d'un sous-réseau |
4 nœuds |
| /28 | 12 nœuds |
| /27 | 28 nœuds |
| /26 | 60 nœuds |
| /25 | 124 nœuds |
| /24 | 252 nœuds |
| /23 | 508 nœuds |
| /22 | 1 020 nœuds |
| /21 | 2 044 nœuds |
| /20 Taille par défaut de la plage d'adresses IP principale d'un sous-réseau dans les réseaux en mode automatique |
4 092 nœuds |
| /19 | 8 188 nœuds |
| /8 Taille maximale de la plage d'adresses IP principale d'un sous-réseau |
16 777 212 nœuds |
É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. S indique la taille du masque de réseau dont la plage valide est comprise entre
8et29inclus.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 - ⌈log2(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 entre8et29inclus.
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.
| Plage d'adresses IP secondaire du sous-réseau utilisée par les pods | Nombre maximal d'adresses IP de pod | Nombre maximal de nœuds | Nombre maximal de pods |
|---|---|---|---|
| /24 Plage d'adresses IP de pod la plus réduite possible lorsque la méthode d'attribution de plages secondaires est gérée par l'utilisateur |
256 adresses | 1 nœud |
Autopilot: 32 pods Standard: 110 pods |
| /23 N'est possible que lorsque la méthode d'attribution des plages secondaires est gérée par l'utilisateur |
512 adresses | 2 nœuds |
Autopilot: 64 pods Standard: 220 pods |
| /22 N'est possible que lorsque la méthode d'attribution des plages secondaires est gérée par l'utilisateur |
1 024 adresses | 4 nœuds |
Autopilot: 128 pods Standard: 440 pods |
| /21 Plage d'adresses IP de pod la plus réduite possible lorsque la méthode d'attribution des plages secondaires est gérée par GKE |
2 048 adresses | 8 nœuds |
Autopilot: 256 pods Standard: 880 pods |
| /20 | 4 096 adresses | 16 nœuds |
Autopilot: 512 pods Standard: 1 760 pods |
| /19 | 8 192 adresses | 32 nœuds |
Autopilot: 1 024 pods Standard: 3 520 pods |
| /18 | 16 384 adresses | 64 nœuds |
Autopilot: 2 048 pods Standard: 7 040 pods |
| /17 | 32 768 adresses | 128 nœuds |
Autopilot: 4 096 pods Standard: 14 080 pods |
| /16 | 65 536 adresses | 256 nœuds |
Autopilot: 8 192 pods Standard: 28 160 pods |
| /15 | 131 072 adresses | 512 nœuds |
Autopilot: 16 384 pods Standard: 56 320 pods |
| /14 Taille par défaut de la plage d'adresses IP secondaire du sous-réseau utilisée par les pods lorsque la méthode d'attribution des plages secondaires est gérée par GKE |
262 144 adresses | 1 024 nœuds |
Autopilot: 32 768 pods Standard: 112 640 pods |
| /13 | 524 288 adresses | 2 048 nœuds |
Autopilot: 65 536 pods Standard: 225 280 pods |
| /12 | 1 048 576 adresses | 4 096 nœuds |
Autopilot: 131 072 pods Standard: 450 560 pods |
| /11 | 2 097 152 adresses | 8 192 nœuds |
Autopilot: 262 144 pods Standard: 901 120 pods |
| /10 | 4 194 304 adresses | 16 384 nœuds |
Autopilot: 524 288 pods Standard: 1 802 240 pods |
| /9 Plage d'adresses IP de pod la plus étendue possible |
8 388 608 adresses | 32 768 Nœuds |
Autopilot: 1 048 576 pods Standard: 3 604 480 pods |
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 :
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
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
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 nouveaux clusters Autopilot exécutant les versions 1.27 ou ultérieures de GKE, GKE attribue par défaut les adresses IP des services à partir d'une plage gérée par Google : 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-cidrou 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 Google 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.
| Plage d'adresses IP secondaire utilisée par les services | Nombre maximal de services |
|---|---|
| /28 Plage d'adresses de services la plus réduite possible lorsque la méthode d'attribution de plages secondaires est gérée par l'utilisateur |
16 services |
| /27 Plage d'adresses de services la plus réduite possible lorsque la méthode d'attribution des plages secondaires est gérée par GKE |
32 services |
| /26 | 64 services |
| /25 | 128 services |
| /24 | 256 services |
| /23 | 512 services |
| /22 | 1 024 services |
| /21 | 2 048 services |
| /20 Taille par défaut de la plage d'adresses IP secondaire du sous-réseau utilisée par les services lorsque la méthode d'attribution de plages secondaires est gérée par GKE |
4 096 services |
| /19 | 8 192 services |
| /18 | 16 384 services |
| /17 | 32 768 services |
| /16 Plage d'adresses de services la plus étendue possible |
65 536 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 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,NodePortetLoadBalancer.
- 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 :
Option ipv6-access-type |
Attribution d'adresses IP | Plage de sous-réseaux |
|---|---|---|
EXTERNAL |
GKE attribue des adresses IPv6 externes routables vers Internet. |
De 2600:1900/28
|
INTERNAL |
GKE attribue des adresses IPv6 internes qui ne peuvent pas être routées vers Internet. Les clusters dotés du type d'accès IPv6 |
À partir de fd20::/20 (sous-ensemble de la plage ULA globale : fc00::/7)
|
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 IPv6 de type ClusterIP, NodePort ou 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.