Une NetworkPolicy n’a d’effet que si le CNI l’implémente, un point déjà souligné : ce que peu d’articles détaillent, c’est comment cette implémentation se fait réellement, et pourquoi ce détail devient critique passé une certaine taille de cluster. kube-proxy, le composant historique, traduit chaque Service Kubernetes en règles iptables ; Cilium, basé sur eBPF, remplace ce mécanisme entier par du code exécuté directement dans le kernel Linux.

Ce que kube-proxy fait réellement avec iptables

kube-proxy, dans son mode le plus courant, traduit chaque Service et chaque endpoint en une chaîne de règles iptables. Router un paquet vers le bon pod signifie évaluer ces règles séquentiellement, une par une, jusqu’à trouver la correspondance : un mécanisme dont le coût croît avec le nombre de Services et d’endpoints du cluster, pas de façon linéaire mais souvent pire.

# Chaque Service ajoute des règles évaluées
# séquentiellement, le coût grandit avec leur nombre
iptables -t nat -L KUBE-SERVICES | wc -l

Sur un cluster avec des centaines de Services et des milliers de pods, cette évaluation séquentielle devient un goulot d’étranglement mesurable : la latence de routage augmente avec la taille du cluster, un effet qui n’apparaît jamais sur un cluster de développement mais devient réel en production à l’échelle.

eBPF : du code qui s’exécute dans le kernel, sans ce détour

eBPF (extended Berkeley Packet Filter) permet d’exécuter du code personnalisé directement dans le kernel Linux, à des points d’accroche précis du chemin réseau, sans passer par les règles iptables traditionnelles. Cilium utilise ce mécanisme pour remplacer entièrement kube-proxy : le routage vers le bon pod se fait via une table de hachage en mémoire, une recherche à coût quasi constant, indépendante du nombre de Services dans le cluster.

# Cilium en remplacement complet de kube-proxy,
# le routage passe par eBPF, pas par des règles iptables
kubeProxyReplacement: true

Cette différence de mécanisme (recherche par hachage contre évaluation séquentielle) explique pourquoi Cilium annonce des gains de performance mesurables précisément sur les clusters à forte densité de Services, là où kube-proxy commence à montrer ses limites.

Ce que ça change pour l’observabilité réseau

eBPF ne se limite pas au routage : le même mécanisme permet à Cilium d’observer le trafic réseau au niveau kernel sans agent supplémentaire ni sidecar, avec une visibilité qui descend jusqu’au niveau du paquet et de l’appel système. Hubble, le composant d’observabilité de Cilium, exploite cette capacité pour offrir une visibilité sur les flux réseau (qui parle à qui, quels flux sont bloqués par une NetworkPolicy) sans instrumentation applicative.

# Visibilité sur les flux réseau au niveau kernel,
# sans agent supplémentaire à déployer par pod
hubble observe --namespace production

Le prix : une dépendance au kernel, pas au cluster

eBPF impose une contrainte que kube-proxy et iptables n’ont jamais eue : une version de kernel Linux suffisamment récente sur chaque nœud (généralement 4.19 ou plus récent selon les fonctionnalités utilisées). Un cluster sur un système d’exploitation ancien, ou un environnement géré qui ne permet pas de contrôler la version du kernel, peut se retrouver incapable d’exploiter pleinement les fonctionnalités eBPF les plus récentes, une vérification à faire avant d’adopter Cilium en remplacement complet de kube-proxy, pas après.

À retenir

kube-proxy traduit chaque Service en règles iptables évaluées séquentiellement, un mécanisme dont le coût grandit avec la taille du cluster. Cilium, basé sur eBPF, remplace ce mécanisme par des tables de hachage exécutées directement dans le kernel, à coût quasi constant, avec en prime une observabilité réseau native sans agent supplémentaire. Le prix est une dépendance à une version de kernel suffisamment récente, une vérification d’infrastructure à faire avant d’adopter Cilium, un des choix de couche réseau qui se posent dès la conception d’une migration Kubernetes à l’échelle.