Kubernetes Networking Overview

Explique les bases du Kubernetes networking, Pod CIDR, Service CIDR, kube-proxy, NetworkPolicy, et le rôle des plugins CNI comme Cilium dans la fourniture du réseau et de l’enforcement

Cet article explique comment fonctionne le Kubernetes networking et les attentes de la plateforme vis-à-vis des plugins Container Network Interface (CNI) tels que Cilium. Comprendre les primitives réseau de Kubernetes — Pod CIDR, Service CIDR, kube-proxy, et NetworkPolicy — permet de mieux comprendre ce que les CNI doivent fournir et comment les CNI basés sur eBPF (comme Cilium) peuvent remplacer ou améliorer le comportement de kube-proxy.

Adressage IP des Pods et le Pod CIDR¶

Lors de la création d’un cluster Kubernetes, vous définissez généralement un Pod CIDR (exemple : 172.16.0.0/16). Kubernetes attribue des adresses IP aux pods à partir de ce CIDR, de sorte que chaque pod possède une IP dans un espace d’adressage partagé.

Kubernetes suppose un espace d’adressage flat : tout pod doit pouvoir atteindre n’importe quel autre pod via son IP, независимо du nœud sur lequel ils s’exécutent ou de la topologie réseau sous-jacente.

Tant que les nœuds ont une connectivité IP entre eux, la communication pod-to-pod doit fonctionner sans modification du routage au niveau applicatif.

Note :

• Les IP des pods sont éphémères — un redémarrage entraîne généralement une nouvelle IP.
• Les processus host exécutés directement sur un nœud peuvent aussi accéder aux pods via leurs IPs.

Services et le Service CIDR¶

Comme les IP des pods sont éphémères, Kubernetes fournit des Services pour offrir :

• Une identité réseau stable
• Du load balancing entre pods

Lors de la création du cluster, vous définissez aussi un Service CIDR (exemple : 10.100.0.0/16). Chaque Service reçoit une ClusterIP stable depuis ce CIDR (exemple : 10.100.0.1).

Les pods clients envoient leur trafic vers cette ClusterIP, et le Service distribue le trafic vers les pods backend actifs.

Comment une ClusterIP atteint les pods backend :¶

• kube-proxy s’exécute sur chaque nœud et observe les objets Service et Endpoint
• Il programme des règles iptables ou IPVS
• Le trafic vers une Service IP est redirigé vers un pod backend

Certains CNI (notamment ceux basés sur eBPF comme Cilium) peuvent :

• Remplacer kube-proxy
• Ou améliorer son fonctionnement avec une gestion plus efficace

NetworkPolicy : déclarer qui peut communiquer avec qui¶

Par défaut, le réseau Kubernetes est permissif : tout pod peut communiquer avec n’importe quel autre.

Pour la production, il est nécessaire de restreindre les communications. Kubernetes NetworkPolicy est une API déclarative permettant d’exprimer ces règles.

Cependant, l’enforcement est assuré par le plugin CNI.

💡 Kubernetes définit l’API NetworkPolicy, mais son application dépend du CNI. Si le CNI ne supporte pas ces règles, elles ne seront pas appliquées.

Kubernetes ne fournit pas un data-plane réseau complet¶

Kubernetes ne fournit pas nativement :

• L’allocation d’IP pour les pods
• Le routing (overlay ou non)
• L’enforcement des NetworkPolicy

Sans plugin CNI :

• Les pods n’obtiennent pas d’IP depuis le Pod CIDR
• La communication pod-to-pod ne fonctionne pas

Le seul composant réseau inclus est kube-proxy. Tout le reste est fourni par un CNI tiers.

⚠️ Si un cluster est créé sans CNI conforme :

• Aucun IP n’est attribué aux pods
• Le réseau du cluster ne fonctionne pas
• Les NetworkPolicy ne sont pas appliquées

Choisir un plugin CNI conforme¶

Vous n’avez pas besoin d’implémenter le réseau vous-même. Installez un plugin CNI conforme qui fournit :

• Allocation d’IP pour les pods
• Routing (overlay ou basé sur routage)
• Intégration des services ou remplacement de kube-proxy
• Enforcement des NetworkPolicy

CNI populaires¶

• Cilium: Basé sur eBPF, fonctionnalités avancées réseau et sécurité
• Calico: Fonctionnalités de routing et de policies
• Flannel: Networking overlay simple

Référence rapide¶

Résumé¶

• Pod CIDR : source des IP des pods
• Service CIDR + kube-proxy (ou alternative CNI) : fournissent des ClusterIP stables et du load balancing
• NetworkPolicy : définit les règles réseau, mais dépend du CNI pour l’enforcement
• Kubernetes nécessite un CNI conforme pour activer le networking et la sécurité

Avec ces bases, vous serez mieux préparé pour comprendre ce que Cilium implémente et quelles parties du Kubernetes networking il remplace ou améliore.