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” où chaque Pod est un citoyen de première classe.

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

Les 4 problèmes de networking

Kubernetes doit résoudre 4 types de communication :

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 :

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)

Pas de port mapping

Contrairement à Docker, vous n’avez jamais besoin de gérer le mapping de ports entre conteneurs. Chaque Pod a son propre espace réseau avec toute la plage de ports disponibles.

Architecture réseau

┌─────────────────────────────────────────────────────────────────────────┐
│                        Cluster Kubernetes                                │
│                                                                          │
│  ┌─────────────────────────────┐    ┌─────────────────────────────┐    │
│  │         Node 1              │    │         Node 2              │    │
│  │   IP: 192.168.1.10          │    │   IP: 192.168.1.11          │    │
│  │                             │    │                             │    │
│  │  ┌─────────┐ ┌─────────┐   │    │  ┌─────────┐ ┌─────────┐   │    │
│  │  │  Pod A  │ │  Pod B  │   │    │  │  Pod C  │ │  Pod D  │   │    │
│  │  │10.244.  │ │10.244.  │   │    │  │10.244.  │ │10.244.  │   │    │
│  │  │ 1.5     │ │ 1.12    │   │    │  │ 2.7     │ │ 2.19    │   │    │
│  │  └────┬────┘ └────┬────┘   │    │  └────┬────┘ └────┬────┘   │    │
│  │       │           │        │    │       │           │        │    │
│  │       └─────┬─────┘        │    │       └─────┬─────┘        │    │
│  │             │              │    │             │              │    │
│  │      ┌──────┴──────┐       │    │      ┌──────┴──────┐       │    │
│  │      │ CNI bridge  │       │    │      │ CNI bridge  │       │    │
│  │      │ ou fabric   │       │    │      │ ou fabric   │       │    │
│  │      └──────┬──────┘       │    │      └──────┬──────┘       │    │
│  │             │              │    │             │              │    │
│  └─────────────┼──────────────┘    └─────────────┼──────────────┘    │
│                │                                  │                   │
│                └──────────────┬───────────────────┘                   │
│                               │                                       │
│                    ┌──────────┴──────────┐                           │
│                    │   Réseau physique   │                           │
│                    │   ou overlay        │                           │
│                    └─────────────────────┘                           │
│                                                                       │
└───────────────────────────────────────────────────────────────────────┘

Allocation des adresses IP

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

Commande non universelle

Cette commande fonctionne avec kubeadm, mais selon la distribution (EKS, GKE, k3s…), le Pod CIDR peut être visible ailleurs : configuration du CNI, API du cloud provider, ou paramètres des composants 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}'

master1    10.244.0.0/24
worker1    10.244.1.0/24
worker2    10.244.2.0/24

Capacité par nœud

Un sous-réseau /24 offre théoriquement jusqu’à 254 adresses IPv4 utilisables. En pratique, la capacité réelle en Pods dépend du plugin CNI (adresses réservées), de la configuration kubelet (maxPods) et des limites du nœud.

Qui attribue les IPs ?

Le plugin CNI est responsable de l’allocation IP via son composant IPAM :

Pod créé
    │
    ▼
kubelet appelle le runtime (CRI)
    │
    ▼
Runtime crée le namespace réseau
    │
    ▼
Runtime appelle le plugin CNI
    │
    ▼
CNI IPAM alloue une IP du CIDR du nœud
    │
    ▼
CNI configure l'interface veth + routes
    │
    ▼
Pod prêt avec son IP

Voir l’IP d’un Pod

# 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

Sur le même nœud

Quand deux Pods sont sur le même nœud, ils communiquent via un bridge virtuel :

┌─────────────────────────────────────────────────┐
│                     Node                         │
│                                                  │
│  ┌──────────┐              ┌──────────┐         │
│  │  Pod A   │              │  Pod B   │         │
│  │ 10.244.  │              │ 10.244.  │         │
│  │ 1.5      │              │  1.12    │         │
│  └────┬─────┘              └────┬─────┘         │
│       │ veth                    │ veth          │
│       │                         │               │
│       └───────────┬─────────────┘               │
│                   │                             │
│            ┌──────┴──────┐                      │
│            │ CNI bridge  │  (interface gérée   │
│            │ ou fabric   │   par le plugin)    │
│            └─────────────┘                      │
│                                                  │
└──────────────────────────────────────────────────┘

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 :

┌─────────────────────────────────────────────────────────────────┐
│ Paquet original                                                  │
│ Src: 10.244.1.5 (Pod A) → Dst: 10.244.2.7 (Pod C)              │
└─────────────────────────────────────────────────────────────────┘
                            │
                            ▼ Encapsulation VXLAN
┌─────────────────────────────────────────────────────────────────┐
│ Outer IP: Src 192.168.1.10 → Dst 192.168.1.11                   │
│ UDP Port 4789 (VXLAN)                                           │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ Inner: Src 10.244.1.5 → Dst 10.244.2.7                      │ │
│ └─────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘

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 :

┌─────────────────┐     BGP     ┌─────────────────┐
│    Node 1       │────────────▶│    Routeur      │
│ 10.244.1.0/24   │             │ (connaît les    │
└─────────────────┘             │  routes Pod)    │
                                └────────┬────────┘
┌─────────────────┐     BGP              │
│    Node 2       │◀─────────────────────┘
│ 10.244.2.0/24   │
└─────────────────┘

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 :

┌─────────────────────────────────────────────────────────────────┐
│ Outer IP: Src 192.168.1.10 → Dst 192.168.1.11 (Protocol 4)      │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ Inner IP: Src 10.244.1.5 → Dst 10.244.2.7                   │ │
│ └─────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘

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

Mode kube-proxy

Vérifiez le mode de kube-proxy avec :

kubectl get configmap kube-proxy -n kube-system -o yaml | grep mode

Selon la version de Kubernetes, kube-proxy peut fonctionner en mode :

• iptables : défaut courant, mature et stable
• nftables : backend moderne, GA prévu en 1.33
• ipvs : meilleure performance à grande échelle, mais déprécié en Kubernetes 1.35

Tester la connectivité Pod-to-Pod

Test basique

1. Créez deux Pods de test

   kubectl run test1 --image=busybox --command -- sleep infinity
   kubectl run test2 --image=busybox --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, Network Policies bloquant ICMP, ou filtrage ICMP sur l’infrastructure. Préférez wget/curl vers un service HTTP pour un test plus fiable.

4. Nettoyez

   kubectl delete pod test1 test2

Test avec wget/curl

# Créer un serveur nginx
kubectl run nginx --image=nginx
kubectl expose pod nginx --port=80

# Tester depuis un autre Pod
kubectl run test --rm -it --image=busybox -- wget -qO- nginx

Diagnostic avancé

# 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

Le Pod ne peut pas ping un autre Pod

Symptômes : ping timeout ou “Network unreachable”

Diagnostic :

# 1. Vérifier que le CNI est installé
kubectl get pods -n kube-system | grep -E 'calico|cilium|flannel'

# 2. Vérifier les logs CNI
kubectl logs -n kube-system -l k8s-app=calico-node

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

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

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

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

# 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)
kubectl exec <pod> -- nslookup kubernetes.default

# Vérifier le CNI
ls /etc/cni/net.d/
kubectl get pods -n kube-system | grep -E 'calico|cilium|flannel|ovn'

À 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

Prochaines étapes

Services Exposer les Pods via des Services

Network Policies Isoler le trafic réseau entre Pods

CNI, CSI, CRI Les interfaces d'extension Kubernetes

CoreDNS DNS interne pour la résolution de noms

×

📖 Voir la documentation →