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 Rôles utilisateur et tâches courantes de 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.
Planifiez et concevez la configuration de votre cluster avec les architectes réseau, les administrateurs réseau ou toute autre équipe d'ingénieurs réseau de votre organisation chargée de définir, d'implémenter et de gérer l'architecture de votre réseau.
Avantages des clusters de VPC natif
Les clusters de VPC natif présentent plusieurs avantages :
Les adresses IP des pods sont acheminées en mode natif 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. Elles 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 | La console Google Cloud | VPC natif |
| 1.21.0-gke.1500 et versions ultérieures | API GKE ou Google Cloud CLI | VPC natif |
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 comme suit.
Adresses IPv4 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 IPv4 de pod : le cluster utilise une ou plusieurs plages d'adresses IPv4 secondaires de sous-réseau pour toutes les adresses IPv4 de pods. Cette page se concentre sur l'utilisation d'une seule plage d'adresses IPv4 secondaire de sous-réseau. Pour en savoir plus sur l'utilisation de plusieurs plages, consultez Ajouter des plages d'adresses IPv4 de pod.
Adresses IPv4 du service : deux options sont disponibles :
Adresses IPv4 de service provenant de
34.118.224.0/20: les clusters GKE Autopilot exécutant la version 1.27 ou ultérieure et les clusters GKE Standard exécutant la version 1.29 ou ultérieure utilisent la plage d'adresses IPv434.118.224.0/20pour les services.Google Cloud utilise la plage d'adresses34.118.224.0/20à des fins privées et ne publie aucune route sur l'Internet public pour cette plage. Vous ne pouvez pas utiliser cette plage pour les adresses IPv4 externes de vos ressources.Adresses IPv4 de service provenant d'une plage d'adresses IPv4 secondaire de sous-réseau : pour toutes les adresses de service (
ClusterIP), le cluster utilise une plage d'adresses IPv4 secondaire de sous-réseau différente de celle ou celles utilisées par les pods.
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.Adresses IPv6 de service : les clusters GKE utilisent la plage d'adresses IPv6
2600:2D00:0:4::0:0/64pour les services. Google Cloudutilise la plage d'adresses2600:2D00:0:4::0:0/64à des fins privées et ne publie aucune route sur l'Internet public pour cette plage. Vous ne pouvez pas utiliser cette plage pour les adresses IPv6 externes de vos ressources.
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 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 GKE à partir d'une plage gérée par GKE : |
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 IPv4 internes
Les adresses IPv4 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 les adresses IPv4 privées, telles que RFC 1918, et les adresses IP publiques utilisées en mode privé. Pour en savoir plus sur les plages d'adresses IPv4 valides pour les sous-réseaux, consultez les pages Plages valides et Plages restreintes de la documentation sur les VPC.
Pour obtenir des informations importantes sur l'utilisation d'adresses privées qui ne sont pas des adresses RFC 1918, consultez Utiliser des plages d'adresses IPv4 privées non-RFC 1918.
Pour obtenir des informations importantes sur l'utilisation des plages d'adresses IPv4 publiques utilisées en mode privé, consultez Activer les plages d'adresses IP publiques utilisées en mode privé.
Méthodes d'attribution de plages d'adresses IPv4 secondaires de sous-réseau
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 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. - 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 Plages CIDR de pods dans les clusters standards 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éez 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 IPv4 principale du sous-réseau
Lorsque vous planifiez la plage d'adresses IPv4 principale du sous-réseau d'un cluster, tenez compte des points suivants :
- 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éé.
- Une fois qu'un sous-réseau a été créé, vous pouvez étendre sa plage d'adresses IP principale, mais vous ne pouvez pas la réduire. Si vous étendez un sous-réseau utilisé par un cluster avec des réseaux autorisés, vous devez ajouter la plage d'adresses IP étendue à la liste des réseaux autorisés du plan de contrôle. Avant d'étendre une plage, veillez à consulter les limites et les recommandations dans Étendre une plage IPv4 principale.
- Les deux premières et les deux dernières adresses IP d'une plage d'adresses IP principale sont réservées parGoogle 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 remplacer ce provisionnement d'adresse IP avec 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 IPv4 principale du sous-réseau et de la configuration du cluster :
- Scénario 1 : nombre maximal de nœuds dans un cluster qui utilise le sous-réseau par défaut.
- Scénario 2 : nombre maximal de nœuds dans un cluster Private Service Connect qui n'utilise pas l'option
private-endpoint-subnetwork.
| Plage d'adresses IP principale du sous-réseau | Scénario 1 | Scénario 2 |
|---|---|---|
| /29 Taille minimale de la plage d'adresses IP principale d'un sous-réseau |
4 nœuds | 3 nœuds |
| /28 | 12 nœuds | 11 nœuds |
| /27 | 28 nœuds | 27 nœuds |
| /26 | 60 nœuds | 59 nœuds |
| /25 | 124 nœuds | 123 nœuds |
| /24 | 252 nœuds | 251 nœuds |
| /23 | 508 nœuds | 507 nœuds |
| /22 | 1 020 nœuds | 1 019 nœuds |
| /21 | 2 044 nœuds | 2 043 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 | 4 091 nœuds |
| /19 | 8 188 nœuds | 8 187 nœuds |
| /8 Taille maximale de la plage d'adresses IP principale d'un sous-réseau |
16 777 212 nœuds | 16 777 211 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.
- Si le cluster utilise des réseaux autorisés, vous devez ajouter la plage d'adresses IP principale étendue à la liste des réseaux autorisés.
Formules utiles
Vous pouvez utiliser les formules suivantes pour calculer :
Calculez 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
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.
Dans les clusters Private Service Connect qui n'utilisent pas l'indicateur private-endpoint-subnetwork, vous pouvez utiliser les formules précédentes, mais en réduisant la valeur de N de 1.
Considérations relatives au dimensionnement du cluster pour la plage d'adresses IP secondaire pour les pods
Pour calculer le nombre maximal de pods que votre cluster peut accepter, tenez compte de la taille du sous-réseau de pods et du nombre maximal de pods par nœud. Le nombre maximal de pods dépend du masque de sous-réseau et du nombre maximal de pods par nœud. N'oubliez pas non plus que certaines adresses IP sont réservées dans la plage principale.
Variables clés
Q: nombre maximal de pods par nœud.DS: taille du bloc CIDR sélectionné pour le sous-réseau de pods (par exemple,/17).M: taille du masque de réseau pour la plage de pods de chaque nœud.HM: nombre de bits d'hôte pour le masque de réseau de la plage de pods du nœud.HD: nombre de bits d'hôte pour le bloc CIDR du sous-réseau de pods.MN: nombre maximal de nœuds pouvant être acceptés.MP: nombre maximal de pods pouvant être pris en charge.S: longueur de préfixe de la plage d'adresses IP principale du sous-réseau.N: nombre d'adresses IP utilisables dans la plage d'adresses IP principale du sous-réseau.
Étapes à suivre pour calculer le nombre maximal de pods
Déterminez le nombre maximal de pods par nœud (
Q) :- Pour les clusters Autopilot, la valeur de
Qest fixe et définie sur 32. - Pour les clusters standards, vous pouvez configurer
Q.
- Pour les clusters Autopilot, la valeur de
Définissez la taille du bloc CIDR pour le sous-réseau de pods (
DS) :- Déterminez la taille du bloc CIDR sélectionné pour le sous-réseau de pods (par exemple,
/17).
- Déterminez la taille du bloc CIDR sélectionné pour le sous-réseau de pods (par exemple,
Calculez la taille du masque de réseau (
M) :M = 31 - ⌈log₂(Q)⌉Remplacez
Qpar la valeur du nombre maximal de pods par nœud. Utilisez la fonction plafond (⌈ ⌉) pour arrondir à l'entier le plus proche.Calculez les bits d'hôte pour la plage de pods (
HM) :HM = 32 - MCalculez les bits d'hôte pour le bloc CIDR sélectionné (
HD) :HD = 32 - DSCalculez le nombre maximal de nœuds (
MN) :MN = 2<sup>(HD - HM)</sup>Le résultat de ce calcul correspond au nombre maximal de nœuds que le sous-réseau de pods sélectionné peut accepter.
Calculez le nombre maximal de pods (
MP) :MP = MN * QLe résultat de ce calcul correspond au nombre maximal de pods que le cluster peut accepter.
Calculez le nombre d'adresses IP utilisables dans la plage principale (
N) :none N = 2<sup>(32-S)</sup> - 4OùScorrespond à la longueur du préfixe de la plage CIDR principale du sous-réseau.
Remarques importantes
- Toutes les adresses IP de la plage secondaire peuvent être utilisées pour les pods.
- Ces calculs fournissent les maximums théoriques. Les performances réelles peuvent être affectées par d'autres facteurs.
Exemple
Supposons que vous créiez un cluster GKE Autopilot avec les éléments suivants :
- Bloc CIDR de sous-réseau de pod de
/17(DS= 17). - 32 pods par nœud au maximum (
Q= 32).
Calculez le nombre maximal de pods :
M = 31 - ⌈log₂(32)⌉ = 26HM = 32 - 26 = 6HD = 32 - 17 = 15MN = 2(15 - 6) = 512MP = 512 * 32 = 16,384
Ce cluster peut accepter jusqu'à 512 nœuds et 16 384 pods.
Vous pouvez ajouter d'autres adresses IPv4 pour les pods en ajoutant des plages d'adresses IPv4 de pods ou en ajoutant des sous-réseaux aux clusters.
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-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 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.
| 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 de sous-réseaux personnalisée pour le plan de contrôle
Par défaut, GKE utilise la plage de sous-réseau principale pour provisionner le point de terminaison interne du plan de contrôle. Toutefois, dans les clusters avec Private Service Connect, vous pouvez configurer GKE pour qu'il provisionne le point de terminaison interne à partir d'un autre sous-réseau que vous avez créé. Vous pouvez partager ce sous-réseau avec d'autres clusters ou entre projets si vous utilisez un VPC partagé.
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 de plage secondaire partagée lorsque vous créez des 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 de plage secondaire partagée pour les services lorsque vous créez des 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 taille de 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 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. Si des erreurs de validation s'affichent lorsque vous activez la mise en réseau à double pile sur les clusters GKE qui ont été mis à niveau de la version 1.24 vers la version 1.25 ou 1.26, contactez l' Google Cloud équipe d'assistance.
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 en savoir plus, consultez 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 en savoir plus, 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. |
À partir 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 comme plage d'adresses IP de pod 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 d'une plage secondaire des pods réservée 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.