Dans un cluster Kubernetes, chaque Pod reçoit sa propre adresse IP. Le réseau Pod CIDR désigne la plage d’adresses IP réservée à l’ensemble des Pods du cluster. Cette plage, exprimée en notation CIDR, détermine combien de Pods peuvent coexister et comment ils communiquent entre eux sans conflit d’adresses.
Notation CIDR : le format qui définit une plage réseau
CIDR signifie Classless Inter-Domain Routing, soit routage inter-domaines sans classe. Cette méthode remplace l’ancien système d’adressage par classes (A, B, C) qui imposait des tailles de réseau rigides et gaspillait des blocs entiers d’adresses.
Lire également : Comment booster mon PC trop lent ?
La notation CIDR associe une adresse IP à un suffixe indiquant le nombre de bits réservés à la partie réseau. Par exemple, 10.244.0.0/16 signifie que les 16 premiers bits identifient le réseau, et les 16 bits restants sont disponibles pour adresser des hôtes, soit plusieurs dizaines de milliers d’adresses utilisables.
Plus le suffixe est petit, plus la plage est large. Un /16 offre bien plus d’adresses qu’un /24. Cette souplesse permet d’adapter la taille du réseau au besoin réel du cluster, sans réserver un bloc disproportionné ni se retrouver à court d’adresses.
A découvrir également : Qu'est-ce qui est mieux, Java 17 ou 21 ?
Pod CIDR dans Kubernetes : une plage dédiée aux Pods
Kubernetes repose sur un modèle réseau dit « plat » : chaque Pod possède son propre espace de noms réseau, donc sa propre pile réseau complète et la totalité des ports disponibles. Aucun Pod ne partage l’adresse IP d’un autre, même sur le même nœud.
Le Pod CIDR est la plage globale dans laquelle Kubernetes puise les adresses attribuées aux Pods. Elle se configure au moment de la création du cluster, via un paramètre souvent nommé --cluster-cidr ou pod_cidr selon la distribution utilisée.
Ce bloc global est ensuite subdivisé. Chaque nœud du cluster reçoit un sous-bloc dédié, dimensionné en fonction du nombre maximal de Pods qu’il peut héberger. Dans GKE par exemple, la configuration par défaut utilise généralement un bloc /24 par nœud, ce qui laisse une marge d’adresses pour absorber les créations et suppressions de Pods sans épuisement temporaire.
Trois plages réseau à ne pas confondre
Le Pod CIDR ne couvre qu’une partie de l’adressage du cluster. Deux autres plages coexistent et doivent être planifiées séparément :
- Le Service CIDR (souvent appelé
svc_cidr) réserve les adresses IP virtuelles attribuées aux objets Service de Kubernetes, ceux qui exposent un groupe de Pods derrière une IP stable. - La plage destinée aux Services de type LoadBalancer, qui doit être disponible et non conflictuelle sur le réseau physique sous-jacent, contrairement aux deux premières plages qui restent principalement internes au cluster.
- Le réseau des nœuds eux-mêmes, qui appartient à l’infrastructure hôte et ne chevauche idéalement aucune des plages précédentes.
Un chevauchement entre ces plages provoque des conflits de routage parfois difficiles à diagnostiquer. Toute la planification réseau d’un cluster commence par le choix de ces trois blocs.
Dimensionnement du Pod CIDR : une contrainte qui se paie après coup
Le dimensionnement du Pod CIDR constitue une décision structurante. Une plage trop petite limite le nombre de nœuds ou de Pods par nœud, et cette contrainte est difficile à corriger sur un cluster existant.
Le calcul repose sur deux variables : la taille du sous-bloc attribué à chaque nœud et le nombre total de nœuds prévu. Si chaque nœud consomme un /24, un Pod CIDR global en /16 ne peut alimenter que quelques centaines de nœuds. Réduire le nombre maximal de Pods par nœud permet d’attribuer des sous-blocs plus petits (un /25 ou /26) et donc d’accueillir davantage de nœuds dans la même plage globale.
Dans GKE, le nombre maximal de Pods par nœud se configure à la création du cluster ou du pool de nœuds. Il ne peut pas être modifié ensuite pour une ressource existante. Une mauvaise estimation initiale impose donc une migration ou une reconstruction complète du pool.
Adapter la taille au CNI utilisé
La consommation réelle d’adresses dépend aussi du plugin CNI (Container Network Interface) qui implémente le réseau. Certains CNI comme Calico ou Cilium gèrent l’attribution d’adresses avec leur propre logique de pools, tandis que d’autres, en mode VPC-natif sur les clouds publics, consomment des adresses directement dans le sous-réseau du fournisseur.
Le choix du CNI influence le nombre d’adresses réellement consommées par Pod. Un CNI en overlay encapsule le trafic et utilise un espace d’adressage virtuel, alors qu’un CNI en mode natif mappe chaque Pod sur une adresse du réseau physique, ce qui peut accélérer l’épuisement de la plage.
Communication entre Pods : ce que le Pod CIDR rend possible
Le modèle réseau de Kubernetes garantit que tout Pod peut joindre n’importe quel autre Pod du cluster par son adresse IP, sans NAT ni port mapping. Le Pod CIDR est le socle de cette garantie : puisque toutes les adresses de Pods appartiennent à une plage connue, les règles de routage peuvent être configurées de façon cohérente sur chaque nœud.
Sur un même nœud, la communication entre Pods passe par un pont virtuel (bridge) local. Entre nœuds différents, le trafic transite par le réseau sous-jacent, soit via un tunnel overlay, soit via des routes statiques ou dynamiques injectées par le CNI.
- En mode overlay (VXLAN, Geneve), le CNI encapsule les paquets Pod-to-Pod dans des paquets réseau standard, ce qui simplifie la configuration mais ajoute une légère surcharge.
- En mode natif ou routé, le CNI programme directement les tables de routage du réseau physique ou cloud pour acheminer le trafic vers le bon nœud, sans encapsulation.
- Dans les deux cas, le Pod CIDR reste la référence pour déterminer quel nœud héberge quel bloc d’adresses et orienter le trafic.
Planifier le Pod CIDR avant de déployer un cluster n’est pas une formalité administrative. C’est un choix d’architecture qui conditionne la capacité de croissance, la compatibilité réseau avec l’infrastructure existante et la facilité de dépannage. Le modifier après coup reste techniquement coûteux sur la plupart des distributions Kubernetes.
