Pod Networking, Communication réseau entre Pods

Kubernetes définit un modèle réseau où chaque Pod possède sa propre IP et peut joindre les autres Pods du cluster directement, sans avoir à publier de ports comme avec Docker. L'implémentation concrète dépend du plugin CNI, mais le modèle garantit une communication transparente entre Pods. Contrairement à Docker où les conteneurs partagent l'IP de l'hôte et utilisent le port mapping, Kubernetes crée un réseau plat : chaque Pod possède son propre espace de noms réseau (network namespace), donc sa propre pile réseau et la totalité des 65 535 ports, sans jamais entrer en conflit avec un autre Pod du même nœud.

Modèle vs implémentation

Kubernetes définit le modèle réseau des Pods (les garanties), mais délègue l'implémentation à un plugin CNI compatible. Certains CNI utilisent des overlays (encapsulation), d'autres du routage natif, le résultat final respecte le même contrat.

Ce guide couvre le domaine Services & Networking (20%) de la certification CKA.

Ce que vous allez apprendre

• Le modèle réseau Kubernetes et ses garanties
• Comment un Pod obtient son adresse IP
• La communication Pod-to-Pod sur le même nœud et entre nœuds
• Le rôle du CNI et du kube-proxy
• Les commandes de diagnostic réseau

Le modèle réseau Kubernetes

Le modèle réseau est un contrat écrit dans la spécification Kubernetes : il énonce ce qui doit être vrai du réseau, sans dire comment l'obtenir. Cette séparation explique pourquoi deux clusters au comportement identique pour vos applications peuvent reposer sur des technologies radicalement différentes, du tunnel VXLAN au routage BGP. Comprendre le contrat avant l'implémentation évite de confondre un problème d'application avec un problème de plugin CNI.

Les 4 problèmes de networking

Kubernetes doit résoudre 4 types de communication, du plus local au plus exposé. Les deux premiers relèvent du réseau des Pods traité ici, les deux suivants passent par les Services et sont couverts par d'autres pages du parcours.

Type	Description	Solution
Container-to-Container	Conteneurs dans le même Pod	localhost (127.0.0.1)
Pod-to-Pod	Pods dans le cluster	Réseau Pod (ce guide)
Pod-to-Service	Pod vers un Service	kube-proxy + DNS
External-to-Service	Trafic externe vers le cluster	Ingress, LoadBalancer

Glissez pour voir

Les garanties du modèle

Kubernetes impose trois règles fondamentales que tout plugin CNI doit respecter pour être conforme. Elles ont une conséquence directe sur vos applications : une adresse IP relevée dans un log correspond bien au Pod émetteur, sans traduction d'adresse (NAT) qui la remplacerait par celle du nœud. C'est ce qui rend exploitables les journaux d'accès et les règles de filtrage basées sur l'IP source.

1. Chaque Pod reçoit sa propre adresse IP
2. Les Pods peuvent communiquer entre eux sans port mapping, quel que soit le nœud, l'IP vue par le Pod source correspond à l'IP réelle du Pod destination
3. L'IP vue par un Pod est la même que celle vue par les autres Pods (pas de SNAT entre Pods)

Architecture réseau

Le schéma ci-dessous montre les deux niveaux d'adressage qui coexistent dans un cluster : l'IP du nœud (192.168.1.x, celle de la machine physique ou virtuelle) et l'IP du Pod (10.244.x.x, distribuée par le plugin CNI). Retenez que les Pods d'un même nœud partagent un point de raccordement local, et que ce sont les nœuds qui se chargent du transport entre eux.

Allocation des adresses IP

Les adresses des Pods ne sont pas tirées au hasard : elles proviennent d'une plage réservée au cluster, découpée en sous-réseaux distribués nœud par nœud. Ce découpage est ce qui permet de router le trafic sans consulter un annuaire central, puisque le préfixe de l'adresse suffit à désigner le nœud de destination. Une plage mal dimensionnée ou en conflit avec le réseau de l'entreprise est une cause classique de cluster inutilisable, et elle se corrige difficilement après coup.

CIDR du cluster

Le cluster définit une plage d'adresses IP réservée aux Pods via le Pod CIDR :

# Voir le CIDR du cluster (méthode kubeadm)
kubectl cluster-info dump | grep -m 1 cluster-cidr

Sortie

                                "--cluster-cidr=10.244.0.0/16",

Commande non universelle

Cette commande fonctionne avec kubeadm. Selon la distribution, EKS, GKE ou k3s, le Pod CIDR se lit ailleurs : dans la configuration du CNI, dans l'API du fournisseur cloud, ou dans les paramètres des composants du control plane.

Configuration typique :

Paramètre	Valeur exemple	Description
--cluster-cidr	10.244.0.0/16	Plage totale pour les Pods
--node-cidr-mask-size	/24	Taille du sous-réseau par nœud

Glissez pour voir

CIDR par nœud

Chaque nœud reçoit un sous-réseau du CIDR cluster :

# Voir le CIDR alloué à chaque nœud
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.podCIDR}{"\n"}{end}'

Sortie

doc-k8s-control-plane   10.244.0.0/24
doc-k8s-worker          10.244.1.0/24

Deux enseignements dans ces deux lignes. Le control plane reçoit lui aussi un sous-réseau, même s'il est tainté et n'héberge pas vos Pods : l'allocation est faite par nœud, indépendamment de ce qui sera schedulé dessus. Et les sous-réseaux ne se chevauchent jamais, ce qui garantit qu'une adresse de Pod identifie son nœud sans ambiguïté.

Un sous-réseau /24 offre théoriquement jusqu'à 254 adresses IPv4 utilisables, mais ne dimensionnez pas votre cluster sur ce chiffre. La capacité réelle en Pods est le plus petit de trois plafonds : les adresses que le plugin CNI se réserve, la valeur maxPods du kubelet, et ce que le nœud peut réellement porter en mémoire et en CPU. C'est presque toujours maxPods, fixé à 110 par défaut, qui arrive en premier.

Qui attribue les IPs ?

Le plugin CNI est responsable de l'allocation IP via son composant IPAM (IP Address Management, le module qui tient le registre des adresses prises et libres). Ni l'API server ni le kubelet ne choisissent l'adresse : ils la reçoivent du plugin et se contentent de la publier dans le champ status.podIP du Pod. La chaîne d'appels ci-dessous est utile en dépannage, car elle indique où chercher les traces quand un Pod reste bloqué sans adresse.

Voir l'IP d'un Pod

L'adresse n'apparaît pas dans la sortie par défaut de kubectl get pods : il faut demander -o wide, -o jsonpath ou des colonnes personnalisées. Un Pod qui n'a pas fini de démarrer renvoie une valeur vide : c'est normal tant que le CNI n'a pas répondu.

# IP dans la description
kubectl get pod <name> -o wide

# IP via jsonpath
kubectl get pod <name> -o jsonpath='{.status.podIP}'

# IPs de tous les Pods
kubectl get pods -A -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,IP:.status.podIP

Communication Pod-to-Pod

Du point de vue de votre application, joindre un autre Pod revient à ouvrir une connexion vers son adresse : rien à configurer, rien à publier. En dessous, le chemin emprunté par le paquet change radicalement selon que les deux Pods tournent sur le même nœud ou non. Cette différence explique qu'une application fonctionne sur un cluster à un seul nœud et échoue dès qu'elle est répartie sur plusieurs machines.

Sur le même nœud

Quand deux Pods sont sur le même nœud, le trafic ne sort pas de la machine. Chez la plupart des plugins classiques, Flannel, Calico en mode standard ou kindnet, chaque Pod est raccordé par une interface veth à un bridge virtuel local, et le schéma ci-dessous décrit ce cas. Ce n'est pas une règle Kubernetes : le modèle impose le résultat, pas le chemin. Un plugin eBPF comme Cilium peut se passer de bridge et commuter les paquets directement dans le noyau.

Le paquet reste local au nœud, aucun trafic ne sort sur le réseau physique.

Entre nœuds différents

Quand les Pods sont sur des nœuds différents, le trafic doit traverser le réseau :

Overlay (VXLAN)

Le CNI encapsule le paquet Pod dans un paquet UDP :

Utilisé par : Flannel (mode vxlan), Calico (mode VXLAN), Cilium (mode overlay)

Native Routing (BGP)

Les Pod CIDRs sont annoncés via BGP aux routeurs du réseau :

Le trafic Pod n'est pas encapsulé, meilleure performance mais nécessite une infrastructure BGP.

Utilisé par : Calico (mode BGP), Cilium (mode native routing)

IP-in-IP

Le paquet IP Pod est encapsulé dans un autre paquet IP :

Plus simple que VXLAN, moins de métadonnées.

Utilisé par : Calico (mode IP-in-IP)

Le rôle de kube-proxy

kube-proxy ne gère pas la communication Pod-to-Pod directe. Son rôle est de :

• Implémenter les Services (ClusterIP, NodePort, LoadBalancer)
• Configurer les règles iptables ou IPVS pour router vers les Pods backend

Pod A veut contacter Service "nginx" (ClusterIP 10.96.1.100)
                    │
                    ▼
           iptables/IPVS (kube-proxy)
                    │
                    ▼
        NAT vers un Pod backend (10.244.2.15)
                    │
                    ▼
          Communication Pod-to-Pod normale

Trois backends existent, et savoir lequel tourne change la façon de lire les règles quand vous déboguez un Service.

Mode	État en 1.37
iptables	le défaut le plus répandu, mature et stable
nftables	stable depuis la 1.33, c'est la cible des migrations
ipvs	déprécié depuis la 1.35, retrait annoncé dans une version future

Glissez pour voir

Vérifiez le vôtre plutôt que de le supposer, par la configuration :

kubectl get configmap kube-proxy -n kube-system -o yaml | grep -E '^\s+mode:'

Sortie sur le cluster de la formation

    mode: iptables

Le Pod le confirme dans ses propres journaux, ce qui lève le doute si la ConfigMap a été modifiée sans redémarrage :

kubectl -n kube-system logs -l k8s-app=kube-proxy | grep -i proxier

Sortie

I0912 20:33:31.316951  1 server_linux.go:144] "Using iptables Proxier"

Tester la connectivité Pod-to-Pod

Vérifier le réseau demande deux Pods réellement en cours d'exécution : aucune commande kubectl ne teste le chemin réseau sans trafic. La méthode consiste à lancer des Pods jetables, à relever leurs adresses, puis à provoquer un échange de l'un vers l'autre. Placez-les sur des nœuds différents pour éprouver le chemin entre nœuds : sinon le test reste local et ne prouve rien sur le réseau superposé.

Test basique

Ce test enchaîne création, relevé des adresses, échange, puis nettoyage. Supprimez bien les Pods à la fin : lancés avec sleep infinity, ils tournent indéfiniment et consomment des ressources.

1. Créez deux Pods de test

   kubectl run test1 --image=busybox:1.37@sha256:9db7b59979c38555a39def84a31fb98b5296952f9e3afd4f6f11f05b07adfab0 --command -- sleep infinity
   kubectl run test2 --image=busybox:1.37@sha256:9db7b59979c38555a39def84a31fb98b5296952f9e3afd4f6f11f05b07adfab0 --command -- sleep infinity

2. Récupérez les IPs

   kubectl get pods -o wide

   NAME    READY   STATUS    IP           NODE
   test1   1/1     Running   10.244.1.5   worker1
   test2   1/1     Running   10.244.2.8   worker2

3. Testez la connectivité

   # Depuis test1, ping test2
   kubectl exec test1 -- ping -c 3 10.244.2.8

   ping pas toujours fiable

   Le test ping peut échouer pour d'autres raisons que le réseau : image sans ping, NetworkPolicy qui bloque ICMP, ou filtrage ICMP sur l'infrastructure. Préférez wget ou curl vers un service HTTP : le test est plus fiable.

4. Nettoyez

   kubectl delete pod test1 test2

Test avec wget/curl

Un échange HTTP vaut mieux qu'un ping : il traverse la même pile TCP que vos applications et n'est pas filtré par les règles ICMP. L'option --rm supprime le Pod de test dès la fin de la commande, ce qui évite d'oublier un Pod Completed dans le namespace.

# Créer un serveur nginx
kubectl run nginx --image=nginx:1.30@sha256:d5792f71a9496b833bc08ea834a758c46e2b6a6306c10f4be926f38a656cdc1c
kubectl expose pod nginx --port=80

# Tester depuis un autre Pod
kubectl run test --rm -it --image=busybox:1.37@sha256:9db7b59979c38555a39def84a31fb98b5296952f9e3afd4f6f11f05b07adfab0 -- wget -qO- nginx

Diagnostic avancé

Quand l'échange échoue, la question suivante est de savoir si le Pod a bien reçu une interface et une route par défaut. Les deux premières commandes s'exécutent dans le Pod et supposent une image contenant ip : busybox et nicolaka/netshoot en disposent, pas nginx. La troisième s'exécute sur le nœud, en root.

# Voir les interfaces réseau dans un Pod
kubectl exec <pod> -- ip addr

# Voir la table de routage
kubectl exec <pod> -- ip route

# Voir les règles iptables du nœud (depuis le nœud)
iptables -t nat -L -n -v | head -50

Problèmes courants et solutions

La grande majorité des pannes réseau d'un cluster se ramène à trois situations : le plugin CNI n'est pas installé ou plante, l'allocation d'adresse échoue, ou le trafic entre nœuds est bloqué par le réseau sous-jacent. Chaque cas se reconnaît à un symptôme distinct, et les commandes de diagnostic diffèrent. Traitez-les dans cet ordre, car un CNI absent rend tous les autres tests inutiles.

Le Pod ne peut pas ping un autre Pod

Ce symptôme couvre aussi bien un CNI défaillant qu'une Network Policy trop restrictive. Commencez par confirmer que les Pods du plugin réseau tournent dans kube-system avant de suspecter votre application.

Symptômes : ping timeout ou "Network unreachable"

Ne cherchez pas le plugin par son nom. Un grep -E 'calico|cilium|flannel' paraît pratique mais il ne trouve rien sur un cluster qui tourne parfaitement avec un autre plugin, kindnet par exemple, celui de la formation. Le diagnostic conclurait alors à un CNI absent alors qu'il est en marche. Deux contrôles ne dépendent d'aucun nom : le fichier de configuration posé sur le nœud, et la liste des DaemonSets de kube-system, où tout plugin réseau apparaît puisqu'il doit tourner sur chaque nœud.

Diagnostic :

# 1. La configuration CNI est-elle posée sur le nœud ?
ls /etc/cni/net.d/

# 2. Quel plugin tourne, quel que soit son nom ?
kubectl get daemonset -n kube-system

# 3. Ses logs, une fois le nom connu
kubectl logs -n kube-system -l app=<nom-du-plugin>

# 4. Vérifier les routes sur le nœud
ip route | grep 10.244

Sortie de l'étape 1 sur le cluster de la formation

10-kindnet.conflist

Solutions possibles :

• Installer un plugin CNI si absent
• Vérifier les Network Policies qui pourraient bloquer
• Redémarrer le DaemonSet CNI

Le Pod est en ContainerCreating

Un Pod coincé dans cet état attend que quelque chose se termine, et l'attribution d'adresse par le CNI en fait partie. Les événements du Pod portent le message d'erreur exact renvoyé par le plugin, c'est le premier endroit à consulter.

Cause fréquente : Erreur CNI lors de l'allocation IP

# Voir les événements du Pod
kubectl describe pod <name> | grep -A5 Events

# Vérifier les logs kubelet
journalctl -u kubelet | grep -i cni

Communication inter-nœuds KO

Quand deux Pods se joignent sur un même nœud mais pas entre nœuds, la cause est presque toujours en dehors de Kubernetes : port UDP 4789 fermé pour VXLAN, protocole IP 4 filtré pour IP-in-IP, ou session BGP non établie. Les commandes suivantes confirment d'abord que le cluster a bien distribué les sous-réseaux, puis que le nœud sait par où sortir.

Vérifications :

# Les nœuds se voient-ils ?
kubectl get nodes

# Le CIDR est-il correctement alloué ?
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.podCIDR}{"\n"}{end}'

# Route vers l'autre sous-réseau Pod
ip route get 10.244.2.1

Commandes CKA essentielles

L'épreuve CKA est chronométrée et se joue au terminal : ces commandes couvrent l'essentiel des questions réseau du domaine Services & Networking. Entraînez-vous à les taper sans consulter la documentation, en particulier les expressions jsonpath qui sont les plus longues à reconstituer sous pression.

# Voir l'IP d'un Pod
kubectl get pod <name> -o wide

# CIDR par nœud
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.podCIDR}{"\n"}{end}'

# Interfaces dans un Pod
kubectl exec <pod> -- ip addr

# Routes dans un Pod
kubectl exec <pod> -- ip route

# Test de connectivité
kubectl exec <pod1> -- ping -c 2 <pod2-ip>

# DNS test (Pod-to-Service), en nom COMPLET, voir juste en dessous
kubectl exec <pod> -- nslookup kubernetes.default.svc.cluster.local

# Vérifier le CNI, sans présumer de son nom
ls /etc/cni/net.d/
kubectl get daemonset -n kube-system

Pourquoi nslookup kubernetes.default échoue depuis un Pod busybox

Le nom court est celui que tout le monde tape, et c'est précisément celui qui rend NXDOMAIN avec busybox, l'image de test la plus utilisée. Le cluster n'y est pour rien : depuis le même Pod, wget https://kubernetes.default résout et reçoit une réponse de l'API server. C'est l'outil qui diffère.

Le /etc/resolv.conf d'un Pod déclare options ndots:5, ce qui demande d'essayer la liste search pour tout nom comportant moins de cinq points. Le résolveur de la bibliothèque C respecte cette consigne ; le nslookup de busybox, lui, n'applique la liste search que si le nom ne contient aucun point. Avec kubernetes.default, il interroge donc ce nom tel quel, que personne ne sert, et déclare l'échec.

Deux conséquences pratiques. Utilisez le nom pleinement qualifié en diagnostic, <service>.<namespace>.svc.cluster.local, qui ne dépend d'aucune liste search et fonctionne partout. Et ne vous fiez pas au code de retour de ce nslookup : interrogé sur un nom court qu'il résout bel et bien, il affiche la bonne adresse puis sort en 1 parce que les entrées suivantes de la liste search ont échoué.

À retenir

1. Chaque Pod a sa propre IP, pas de port mapping nécessaire
2. Modèle réseau = contrat : Kubernetes définit les garanties, le CNI implémente
3. Le CNI configure le réseau et attribue les IPs
4. Pod CIDR divisé en sous-réseaux par nœud
5. Overlay (VXLAN) ou native routing (BGP) pour le trafic inter-nœuds
6. kube-proxy gère les Services, pas le routage Pod-to-Pod direct
7. Les conteneurs d'un même Pod communiquent via localhost

Testez vos connaissances

Ce questionnaire reprend les points du guide au format des questions CKA. Le seuil de réussite est fixé à 70 %, comme à l'examen.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Pour aller plus loin

• Troubleshooting cluster : Le diagnostic d'un trafic entre Pods qui ne passe pas, plugin CNI compris.
• Observer la santé d'un cluster : Les commandes qui confirment que le réseau du cluster est bien opérationnel.
• mTLS pod-to-pod : Le chiffrement de ces échanges, que le plan réseau laisse en clair par défaut.

×

📖 Voir la documentation →