Votre VPC ne manque pas d’adresses IP parce que vous avez trop de pods. Il en manque parce que GKE attribue à chaque nœud un /24 entier, que ce nœud planifie 8 pods ou 108. Sur une plateforme partagée et multi-tenant, cet arrondi structurel s’accumule vite : chaque cluster de tenant découpe de nouvelles plages dans le même espace d’adressage fini, et la première équipe à provisionner un gros cluster peut affamer toutes celles qui suivent. Voici un playbook pour les calculs que personne n’avait rassemblés au même endroit, le rayon d’impact qu’ils créent entre tenants, et un modèle d’allocation déterministe qui transforme l’épuisement en problème de planification plutôt qu’en incident.

À retenir

  • GKE dimensionne le CIDR de pods de chaque nœud en arrondissant à la puissance supérieure, si bien que la valeur par défaut de 110 pods maximum consomme un /24 par nœud (documentation réseau GKE de Google Cloud, 2026).
  • Plus de 95 % des clusters GKE font tourner 30 pods par nœud ou moins, et pourtant chacun de ces nœuds réclame un /24 entier (Google Cloud Blog, 2025).
  • Les plateformes multi-tenant atteignent l’épuisement en premier : espace VPC partagé, plages par tenant, aucun CIDR de pods mutualisé.
  • Corrigez le problème sans re-architecturer : CIDR multi-pods discontigu, espace Class E et max-pods correctement dimensionné.

Pourquoi GKE consomme-t-il un /24 sur chaque nœud ?

GKE n’alloue pas les IP de pods à la demande. Il réserve un CIDR de pods fixe par nœud, dimensionné en arrondissant votre paramètre max-pods à la puissance de deux supérieure, puis en le doublant. Avec la valeur par défaut de 110 pods maximum, ce calcul tombe sur un /24 : 256 adresses par nœud, quelle que soit la densité réelle (documentation réseau GKE de Google Cloud, 2026).

La valeur par défaut de 110 pods par nœud de GKE force l’allocateur d’IP à arrondir chaque nœud à un /24, soit 256 adresses. Une plage de pods /20 ne contient donc que 16 nœuds avant que le cluster ne puisse plus monter en charge, d’après la documentation des bonnes pratiques réseau GKE de Google Cloud (2026).

Mais ce gaspillage n’est pas un cas marginal, c’est la norme. La télémétrie de Google elle-même montre que plus de 95 % des clusters GKE font tourner 30 pods par nœud ou moins, et pourtant chacun de ces nœuds revendique un /24 complet (Google Cloud Blog, 2025). Vous payez donc pour 256 adresses et vous en utilisez une vingtaine. Combien de pods votre nœud le plus chargé fait-il réellement tourner ? Pour la plupart des flottes, la réponse honnête est bien en dessous de 40. Multipliez cet écart par chaque nœud et le VPC partagé se vide pour des raisons qui n’ont rien à voir avec le trafic réel.

Voici le calcul détaillé. D’abord, le CIDR par nœud suit l’arrondi à la puissance de deux. Ensuite, le nombre de nœuds par plage est une simple division. Dans notre travail sur les plateformes, c’est la ligne /20 qui piège les équipes : elle paraît généreuse jusqu’à ce qu’on la divise par 256.

max-pods / nœudCIDR par nœudnœuds dans un /20nœuds dans un /18nœuds dans un /16
110 (défaut)/24 (256)1664256
64/25 (128)32128512
32/26 (64)642561024
16/27 (32)1285122048

Un cluster de 100 nœuds avec les valeurs par défaut a besoin d’au moins 25 600 adresses IP de pods. Un /18 n’en offre que 16 384 : il échoue donc silencieusement à monter en charge. Résultat, il vous faut un /16 pour installer la flotte avec de la marge (Google Cloud Community, 2025). Le levier que la plupart des équipes actionnent en dernier, réduire max-pods, est aussi le moins coûteux. Passer de 110 à 32 pods par nœud quadruple votre plafond de nœuds dans le même CIDR, sans toucher au VPC. Les plages de pods ne sont d’ailleurs pas les seules à puiser dans un VPC partagé : les endpoints Private Service Connect répartis sur plusieurs gateways consomment le même espace d’adressage, alors intégrez-les au même plan.

Pourquoi les plateformes multi-tenant atteignent-elles l’épuisement d’IP en premier ?

Les plateformes multi-tenant épuisent l’espace d’adressage plus tôt que les clusters mono-équipe parce que le gaspillage s’additionne d’un tenant à l’autre au lieu de s’amortir. Chaque cluster de tenant découpe son propre sous-réseau primaire, plus des plages secondaires distinctes pour les pods et les services, dans un unique VPC partagé. Ensuite, l’arrondi du /24 par nœud s’applique à l’intérieur de chacune de ces plages : la surcharge structurelle s’empile donc tenant après tenant.

Supposons que vous intégriez un tenant qui a besoin de trois clusters répartis sur deux régions. Cela fait six sous-réseaux primaires, six plages de pods et six plages de services découpés avant même qu’une seule charge de travail ne tourne. Imaginez maintenant dix tenants faisant de même, et vous pouvez voir un /16 s’évaporer sur le papier.

La règle du moindre privilège rend cela non négociable : ne partagez jamais une plage de pods entre tenants. Pourquoi est-ce si important ? Un CIDR de pods partagé signifie qu’un tenant qui met à l’échelle un job batch peut épuiser la plage de production d’un autre tenant. La pénurie d’IP se manifeste alors sous forme de pods non planifiables sans propriétaire évident. L’isolation est la bonne approche, mais l’isolation multiplie le coût fixe. La même discipline d’isolation gouverne le trafic est-ouest, où un programme eBPF obsolète peut casser silencieusement l’application des NetworkPolicy de GKE Dataplane V2 entre tenants.

Piège : discontigu ne veut pas dire désorganisé. Attribuer à chaque tenant une plage ad hoc prise là où il reste de la place aujourd’hui crée un cauchemar d’audit et un chevauchement futur quasi certain. Il vous faut de l’isolation et un plan, et c’est là que l’allocation déterministe justifie son existence.

Le schéma que nous rencontrons le plus souvent sur les parcs européens, c’est l’épuisement de RFC1918 hérité de décennies de fusions-acquisitions. D’après notre expérience, l’espace privé, soit environ 17,9 millions d’adresses réparties sur les trois blocs RFC1918, avait été découpé par une dizaine de réseaux hérités bien avant l’arrivée de Kubernetes (Google Cloud Blog, 2025). Si bien qu’au moment où une équipe plateforme veut des /16 contigus pour GKE, la carte est déjà un patchwork. Les équipes nord-américaines se heurtent à un autre mur : de vastes parcs AWS multi-comptes où personne n’est propriétaire du plan CIDR global.

Qu’est-ce que l’IPAM déterministe par SubnetPool ?

L’IPAM déterministe par SubnetPool remplace le découpage de CIDR à la demande par une allocation pré-planifiée à partir de pools déclarés par les architectes. Au lieu qu’un algorithme découpe un gros bloc au moment du provisioning, les architectes pré-calculent chaque sous-réseau valide sous forme d’entrée de catalogue explicite. Un cluster réclame une entrée entière de façon atomique. La même entrée produit toujours le même sous-réseau : la réconciliation est donc idempotente et chaque allocation se rattache à une seule entrée auditable.

Partager une plage de pods entre tenants permet à l’événement de mise à l’échelle d’une équipe d’affamer la charge de production d’une autre ; la bonne pratique multi-tenant impose donc un sous-réseau et une plage secondaire distincts par cluster. Les pools déterministes font respecter cette isolation tout en gardant l’ensemble de la carte CIDR planifiée et auditable, plutôt que dérivée algorithmiquement au moment du provisioning.

L’objet central est une ressource de catalogue de pools de sous-réseaux, indexée par région, type d’accès, criticité et type de cluster. Chaque pool contient une liste ordonnée d’entrées. Une entrée est un CIDR primaire, plus des plages secondaires nommées pour les pods et les services, et une plage master /28 optionnelle pour le plan de contrôle privé.

apiVersion: platform.example.io/v1
kind: SubnetPool
metadata:
  name: europe-west1-internal-standard
spec:
  region: europe-west1
  accessType: Internal        # Internal | External
  criticality: Standard       # Standard | Critical | Strategical
  reclaimPolicy: Quarantine   # Retain | Delete | Quarantine (7d TTL)
  entries:
    - primary: 10.4.0.0/22
      pods:   10.128.0.0/17    # plage secondaire dimensionnée au plus juste
      services: 10.4.4.0/22
      masterCidr: 10.4.8.0/28  # optionnel, /28 validé
    - primary: 10.4.12.0/22
      pods:   10.128.128.0/17
      services: 10.4.16.0/22

Cette ligne reclaimPolicy n’est pas décorative. Nous avons un jour vu un CIDR réutilisé ressusciter un enregistrement DNS obsolète, et c’est la fenêtre de quarantaine de 7 jours qui l’a empêché de virer à la panne.

Comment l’allocation déterministe reste-t-elle exempte de conditions de course ?

Lorsqu’un cluster a besoin d’un sous-réseau, le contrôleur sélectionne un pool correspondant, choisit la première entrée libre dans une boucle de nouvelle tentative sur conflit, puis enregistre la revendication sous forme d’objet d’allocation distinct. Au début, deux clusters se sont réconciliés au même instant et ont saisi des plages qui se chevauchaient. La boucle de nouvelle tentative sur conflit est le correctif que nous avons livré pour l’empêcher. Il valide ensuite le CIDR choisi par rapport aux sous-réseaux gérés et bruts existants dans le même VPC avant de le matérialiser. Comme les pools pré-déclarent l’univers entier, la détection de chevauchement est un test d’appartenance à un ensemble, et non un calcul d’intervalles. Un contrôleur qui réclame des plages doit aussi survivre à la péremption du cache qui fait agir les contrôleurs Kubernetes sur un état obsolète, sinon deux réconciliations peuvent encore diverger sur ce qui est libre.

Comment les pools sont-ils amorcés par environnement ?

Une étape d’amorçage initialise chaque nouvel environnement avec le produit cartésien complet des pools, région par type d’accès par criticité par type de cluster, à partir d’un catalogue d’entrées CIDR par région. La réconciliation est purement additive : elle ne réécrit jamais les allocations existantes et rejette les chevauchements intra-pool à l’admission. Ce plan CIDR master, rédigé une seule fois en amont, est l’artefact que lit votre prévision de capacité.

Et les régions non primaires et les sous-réseaux BYO ?

Un unique pool fourre-tout couvre toutes les régions hors de votre empreinte primaire, sélectionné par nom de pool plutôt que par étiquette de région, ce qui vous permet d’étendre la couverture sans dupliquer le plan. Notre premier catalogue ne couvrait que deux régions européennes. Le jour où une équipe en a demandé une troisième, nous avons ajouté un pool fourre-tout au lieu de modifier des CIDR à la main. Les sous-réseaux BYO (fournis par le tenant) sont le cas limite le plus délicat. Lorsqu’un tenant fournit un sous-réseau externe, la plateforme ne peut pas dériver la plage master du plan de contrôle. Elle exige donc un bloc CIDR master explicite et un nom de plage secondaire dans la spec.

Comment corriger l’épuisement sans re-architecturer ?

Vous pouvez récupérer de l’espace d’adressage sur une plateforme en production sans reconstruire le VPC, à l’aide de trois manœuvres par ordre croissant de rayon d’impact. D’abord, dimensionnez max-pods au plus juste. Ensuite, ajoutez un CIDR de pods discontigu. Ne recourez à l’espace hors RFC1918 que lorsque la carte privée est réellement pleine. Aucune de ces manœuvres n’exige de recréer le cluster sur GKE moderne.

Dimensionnez d’abord max-pods au plus juste. C’est le changement au plus fort effet de levier et au plus faible risque. La plupart de vos charges de travail entassent-elles vraiment 110 pods sur un nœud ? Presque aucune. Le tableau ci-dessus montre le plafond se multiplier à mesure que la densité baisse : réglez donc max-pods sur votre densité p99 réelle plus une marge, et non sur la valeur par défaut.

Ajoutez un CIDR multi-pods discontigu. GKE vous permet d’attacher des plages de pods supplémentaires, non adjacentes, à un cluster en fonctionnement, et un sous-réseau prend en charge jusqu’à 170 plages secondaires (documentation Google Cloud, 2026). Supposons que votre seul espace libre soit constitué de trois /22 dispersés. Vous n’avez pas besoin qu’ils soient contigus. Attachez les trois comme plages de pods, et le cluster assemble sa capacité à partir des fragments que la carte héritée vous a laissés, sans recréation.

Utilisez Class E comme issue de secours. Lorsque RFC1918 est épuisé, la plage Class E (240.0.0.0/4) offre environ 268,4 millions d’adresses utilisables, contre environ 17,9 millions pour l’ensemble de RFC1918 (Google Cloud Blog, 2025). GKE la prend en charge pour les plages de pods. Traitez-la comme un espace strictement interne et testez vos chemins on-premise et pare-feu, car certains équipements hérités refusent encore de la router.

Piège : Class E n’est pas un repas gratuit. Des équipements réseau anciens, certaines piles OS et certaines allow-lists SaaS rejettent toujours 240.0.0.0/4 comme réservé. Validez le chemin complet avant d’y engager un tenant, sous peine de troquer l’épuisement d’IP contre des pannes de connectivité silencieuses.

Qu’est-ce qui change quand vous faites cela sur AWS ?

Le calcul d’IP est de saveur EKS plutôt que GKE, mais la discipline est identique : planifiez l’espace CIDR global avant que les tenants ne le consomment. Sur des parcs AWS multi-comptes et multi-VPC, utilisez donc AWS IPAM pour allouer et suivre les pools de manière centralisée, au lieu de laisser chaque compte saisir des plages indépendamment. Le mode de défaillance, chevauchement non coordonné et épuisement silencieux, est le même que celui que les pools déterministes résolvent sur GCP.

La règle empirique propre à AWS, c’est la marge : gardez 20 à 30 % de chaque sous-réseau libre pour que l’autoscaling et les déploiements progressifs disposent de marge de rafale. Les pools déterministes et AWS IPAM sont la même idée sous des logos différents. Tous deux remplacent « saisissez une plage quand vous en avez besoin » par « réclamez une entrée pré-planifiée dans un catalogue gouverné ». Résultat, le chevauchement devient un test d’appartenance plutôt qu’un exercice de médecine légale post-incident. Donc, si vous exploitez les deux clouds, rédigez un seul plan CIDR et projetez-le dans l’outil de chaque fournisseur, au lieu d’entretenir deux modèles mentaux.

Comment planifier la capacité avant que le VPC ne soit à sec ?

La planification de capacité part du plafond de nœuds, pas du nombre de pods. Puisque chaque nœud consomme un CIDR fixe, votre véritable contrainte est le nombre de nœuds par plage. Par exemple, un cluster par défaut de 100 nœuds a déjà besoin d’un /16 pour installer ses 25 600 adresses IP de pods avec de la marge (Google Cloud Community, 2025). Dimensionnez donc à rebours à partir du pic du nombre de nœuds, puis réservez de la marge par-dessus.

Passez cette checklist avant de découper le premier sous-réseau de tenant :

  • Réglez max-pods sur la densité réelle. Basez-le sur le p99 mesuré de pods par nœud, pas sur 110. Ce seul nombre fixe la taille de toutes les plages en aval.
  • Dimensionnez les plages de pods à partir du pic de nœuds. Multipliez le pic du nombre de nœuds par le CIDR par nœud du tableau, puis ajoutez un tampon de croissance.
  • Un sous-réseau et une plage secondaire par cluster de tenant. Ne partagez jamais une plage de pods entre tenants ; l’isolation plafonne le rayon d’impact de chaque tenant.
  • Rédigez un plan CIDR master en amont. Pré-déclarez les pools par région et par environnement pour que l’allocation soit déterministe et le chevauchement un test d’appartenance.
  • Gardez 20 à 30 % de marge par sous-réseau. Donnez à l’autoscaling et aux déploiements progressifs de quoi monter en rafale sans heurter le mur.
  • Pré-validez un bloc Class E ou secondaire. Validez le chemin de routage d’une plage de secours avant d’en avoir besoin, pas pendant une panne.

Le plan, c’est le produit

L’épuisement d’IP a des airs de limite d’infrastructure, mais sur une plateforme Kubernetes multi-tenant, c’est presque toujours un manque de planification. L’arrondi par nœud de GKE est prévisible, la multiplication par tenant est prévisible, et les correctifs, max-pods dimensionné au plus juste, CIDR discontigu et Class E, sont tous documentés et disponibles dès aujourd’hui. Alors, qu’est-ce qui manque le plus souvent ? Un unique plan CIDR faisant autorité, que lit chaque allocation.

L’IPAM déterministe par SubnetPool transforme ce plan en contrat imposé : les architectes pré-déclarent l’univers d’adressage, les contrôleurs réclament des entrées entières de façon atomique, et le chevauchement devient un test d’appartenance à un ensemble plutôt qu’une panne. Ce contrôleur SubnetPool n’est qu’un composant d’un schéma plus large, le même que celui qui sous-tend la construction d’un Kubernetes as a Service avec un control plane sur mesure. Faites le calcul une fois, par région et par environnement, avant que le premier tenant ne provisionne. Les équipes qui survivent à leur propre croissance sont celles qui ont traité l’espace d’adressage comme une ressource conçue, et non comme un accident d’exécution.

Réponses directes

Questions fréquentes

Pourquoi GKE attribue-t-il un /24 par nœud par défaut ?

GKE réserve à l'avance le CIDR de pods de chaque nœud, dimensionné en arrondissant max-pods à la puissance de deux supérieure puis en le doublant. La valeur par défaut de 110 pods maximum s'arrondit à un /24, soit 256 adresses, quel que soit le nombre réel de pods planifiés. Réduire max-pods diminue directement le bloc par nœud.

Puis-je ajouter de la capacité IP à un cluster GKE en fonctionnement ?

Oui. GKE prend en charge le CIDR multi-pods discontigu, qui permet d'attacher des plages de pods supplémentaires et non adjacentes à un cluster en production, et un unique sous-réseau contient jusqu'à 170 plages secondaires. Vous évitez totalement la recréation et assemblez la capacité à partir des fragments encore libres dans votre carte d'adressage existante.

Est-il sûr de partager une plage de pods entre tenants ?

Non. Une plage de pods partagée signifie qu'un tenant qui met à l'échelle une charge de travail peut épuiser les adresses dont dépendent les pods de production d'un autre tenant, et la défaillance apparaît sous forme de pods non planifiables sans propriétaire clair. La bonne pratique multi-tenant impose un sous-réseau et une plage secondaire distincts par cluster, ce que les pools déterministes garantissent par construction.

Quand faut-il utiliser l'espace d'adressage Class E ?

Ne recourez à Class E (240.0.0.0/4) que lorsque RFC1918 est réellement épuisé. Elle offre environ 268,4 millions d'adresses contre 17,9 millions pour RFC1918. Traitez-la comme strictement interne et validez d'abord le routage on-premise et les chemins pare-feu, car certains équipements hérités rejettent encore la plage comme réservée.