Clusters de VPC natif

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.

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. 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.

Mode de réseau du cluster par défaut

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 chaque méthode de création de cluster.

Méthode de création du cluster Mode de réseau du cluster
Google Cloud Console VPC natif
API REST Basé sur le routage
gcloud v256.0.0 et versions supérieures, ou v250.0.0 et versions inférieures Basé sur le routage
gcloud v251.0.0 – 255.0.0 VPC natif

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 trois plages d'adresses IP de sous-réseau uniques :

  • la plage d'adresses IP principale du sous-réseau pour toutes les adresses IP de nœud ;
  • une plage d'adresses IP secondaire pour toutes les adresses IP des pods ;
  • une autre plage d'adresses IP secondaire pour toutes les adresses de services (ClusterIP).

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 à /22 (2(32-22) = 210 = 1 024 adresses). Sur ces 1 024 adresses, 1 020 sont utilisables, car quatre adresses IP sont réservées dans chaque plage d'adresses IP principale.

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 /24 (256 adresses) à chaque nœud pour les pods en cours d'exécution. Sur chaque nœud, ces 256 adresses IP d'alias permettent d'accepter jusqu'à 110 pods.

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.

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 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 le cloud privé virtuel.

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é pour obtenir des instructions sur l'utilisation de ces plages dans des clusters privés.

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 à l'aide de l'une des deux méthodes suivantes :

Gestion par GKE (par défaut)

GKE peut créer et gérer automatiquement les plages secondaires du sous-réseau. Lorsque vous créez le cluster, vous spécifiez soit une plage CIDR complète, soit la taille d'un masque de réseau pour les pods et les services. 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.

Si vous créez le cluster et le sous-réseau simultanément, les plages d'adresses IP des pods et des services sont gérées par GKE.

Gestion par l'utilisateur

Vous pouvez créer les plages d'adresses IP secondaires du sous-réseau, puis créer un cluster qui utilise ces plages. 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 est de taille /28. Toutefois, vous devez utiliser une plage suffisamment grande pour permettre la création d'au moins un nœud. La plage minimale utilisable dépend 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 créer un cluster avec une plage d'adresses des pods plus étendue ou recréer vos pools de nœuds en réduisant la capacité --max-pods-per-node pour les pools de nœuds.

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 membre IAM 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 concerné 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 est possible d'étendre la plage d'adresses IP principale à tout moment, même lorsque les ressources Google Cloud utilisent le sous-réseau. Cependant, vous ne pouvez pas réduire ni modifier le schéma d'adresses IP principale d'un sous-réseau une fois que le sous-réseau a été 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

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 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 - ⌈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 entre 8 et 29 inclus.

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. Bien qu'une plage d'adresses IP secondaire d'un sous-réseau puisse être remplacée, cette opération n'est pas disponible en raison des risques pour la stabilité du cluster.

Toutefois, vous pouvez créer des plages d'adresses IP de pods supplémentaires à l'aide du CIDR multipods non contigu.

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 (densité de pod par défaut la plus élevée possible).

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 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 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 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 880 pods
/20 4 096 adresses 16 nœuds 1 760 pods
/19 8 192 adresses 32 nœuds 3 520 pods
/18 16 384 adresses 64 nœuds 7 040 pods
/17 32 768 adresses 128 nœuds 14 080 pods
/16 65 536 adresses 256 nœuds 28 160 pods
/15 131 072 adresses 512 nœuds 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 112 640 pods
/13 524 288 adresses 2 048 nœuds 225 280 pods
/12 1 048 576 adresses 4 096 nœuds 450 560 pods
/11
2 097 152 adresses 8 192 nœuds 901 120 pods
/10
4 194 304 adresses 16 384 nœuds 1 802 240 Pods
/9
Plage d'adresses IP de pod la plus étendue possible
8 388 608 adresses 32 768 Nœuds 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 :

  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.
  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.
  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.

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, vous ne pouvez la remplacer que si aucune ressource Google Cloud ne l'utilise. Il n'est pas possible de la modifier tant qu'un cluster l'utilise pour les services (adresses IP du cluster).

Contrairement à ce que nous avons vu précédemment au sujet des plages d'adresses IP de nœud et de pod, chaque cluster doit disposer d'une plage d'adresses IP secondaire de sous-réseau unique réservée aux services et ne peut pas provenir d'une plage d'adresses IP principale ou secondaire partagée.

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
/27
Plage d'adresses de services la plus réduite possible
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

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.

Cloud Console affiche des messages d'erreur comme ci-dessous pour indiquer 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

Étape suivante