Réseau Kubernetes — Modèle et primitives
| Fiche express | |
|---|---|
| Type | Modèle réseau natif de Kubernetes |
| Primitives | Pod network · Service · kube-proxy · CoreDNS |
| Règle de base | IP par Pod, joignable sans NAT |
| Voir aussi | CNI — Panorama et choix · NetworkPolicies · Ingress et Gateway API · SDN datacenter vs overlay CNI |
Le modèle réseau de Kubernetes et ses primitives : réseau des Pods, Services, kube-proxy, CoreDNS. Socle indispensable avant d'aborder les CNI, les NetworkPolicies et le service mesh.
Le modèle réseau
Kubernetes impose trois règles, sans dicter l'implémentation (déléguée au CNI) :
- Chaque Pod a sa propre IP (réseau plat, IP-per-pod).
- Tout Pod peut joindre tout autre Pod sans NAT, sur tout nœud.
- Un agent sur le nœud (kubelet, démons système) peut joindre les Pods du nœud.
Conséquence : pas de translation de ports au niveau conteneur ; le réseau est « plat » du point de vue des Pods.
Primitives
<mermaid> flowchart TD
C[Client] -->|DNS: svc.ns.svc.cluster.local| DNS[CoreDNS] DNS -->|ClusterIP virtuelle| SVC[Service ClusterIP] SVC -->|kube-proxy: iptables/IPVS/eBPF| EP[Endpoints] EP --> P1[Pod A] EP --> P2[Pod B]
</mermaid>
Pod network
Espace d'adressage plat attribué par le CNI (overlay VXLAN/Geneve, ou routage natif — voir SDN datacenter vs overlay CNI). L'IP d'un Pod est éphémère : elle disparaît avec le Pod. D'où le besoin des Services.
Service
Abstraction stable devant un ensemble de Pods (sélectionnés par labels), avec une IP virtuelle durable. Types :
| Type | Exposition | Usage |
|---|---|---|
| ClusterIP | IP interne au cluster (défaut) | Communication est-ouest interne |
| NodePort | Port sur chaque nœud | Exposition basique/externe, rarement en prod telle quelle |
| LoadBalancer | IP externe via LB | Exposition nord-sud (cloud, ou MetalLB/Cilium on-prem) |
| ExternalName | CNAME DNS | Alias vers un service externe |
Pour l'exposition HTTP mutualisée, on préfère un Ingress ou la Gateway API plutôt qu'un LoadBalancer par service.
kube-proxy
Composant qui programme le nœud pour router le trafic d'une ClusterIP vers un endpoint Pod sain. Trois modes :
- iptables — historique, règles linéaires (coût croissant avec le nombre de services).
- IPVS — hachage noyau, meilleure montée en charge.
- eBPF (kube-proxy replacement) — remplacement complet par Cilium, via tables de hachage eBPF ; très faible latence à grande échelle.
CoreDNS
Serveur DNS interne du cluster. Résout les noms de Service en ClusterIP : <service>.<namespace>.svc.cluster.local. Point névralgique : une panne CoreDNS casse la découverte de services.