Cilium remplace vos règles iptables par du code kernel JIT-compilé — et c’est 100× plus rapide

iptables fête ses 25 ans en 2026. Le firewall intégré au kernel Linux depuis la version 2.4 (janvier 2001) est toujours le mécanisme par défaut de la plupart des CNI Kubernetes. Son problème n’est pas la sécurité — c’est l’architecture : chaque paquet traverse séquentiellement une chaîne de règles jusqu’à ce qu’une correspondance soit trouvée. À 10 000 règles, le coût est O(n) linéaire. À 50 000 règles, votre cluster commence à perdre des paquets.

eBPF résout ce problème à la racine. Au lieu d’inspecter chaque paquet à travers une liste de règles, il injecte un programme sandboxé directement dans le kernel — vérifié, JIT-compilé en code machine natif, exécuté en temps constant via des hash tables. Le résultat : un débit 100 fois supérieur à iptables pour un volume de règles équivalent, mesuré par Isovalent sur des benchmarks de 2025. Cilium, le CNI qui exploite eBPF, est devenu le projet le plus avancé de l’écosystème cloud natif — il remplace kube-proxy, iptables, et ajoute l’observabilité L7 avec Hubble et le chiffrement WireGuard transparent.

iptables a 25 ans — et c’est le problème

Le modèle iptables repose sur cinq tables (filter, nat, mangle, raw, security) et des chaînes (INPUT, OUTPUT, FORWARD, PREROUTING, POSTROUTING). Chaque règle est évaluée dans l’ordre, et chaque évaluation traverse une structure de données linéaire. Quand kube-proxy fonctionne en mode iptables, chaque nouveau Service Kubernetes, chaque nouveau Endpoint, chaque nouvelle NetworkPolicy ajoute des règles supplémentaires à ces chaînes.

Le résultat est bien documenté depuis 2017 :

• Latence de mise à jour. L’ajout d’un seul Service en mode iptables peut prendre plusieurs secondes sur un cluster de taille moyenne, parce que iptables-restore doit réécrire l’intégralité du ruleset à chaque changement.
• Dégradation du débit. À partir de 5 000 règles, la traversée séquentielle du ruleset devient visible sur les latences de connexion. À 20 000 règles, les timeouts TCP apparaissent.
• Défaut de conception fondamental. Chaque paquet du flux de données traverse le ruleset, même si la règle qui le concerne est la dernière de la liste.

Calico, le CNI historique, a longtemps partagé ce problème — son mode par défaut utilisait iptables pour l’application des politiques. Calico a depuis ajouté un mode eBPF, mais son adoption reste partielle et sa surface fonctionnelle moins large que celle de Cilium. Flannel, le CNI le plus simple de l’écosystème, ne fait que du routage overlay (VXLAN ou host-gw) et ne propose aucune NetworkPolicy — il incarne l’approche que Cilium rend obsolète.

eBPF — le kernel devient programmable

eBPF est né d’un détournement du Berkeley Packet Filter original. Là où le BPF classique (cBPF) se limitait au filtrage de paquets réseau, eBPF permet d’exécuter des programmes sandboxés à presque tous les points d’accroche du kernel Linux : appels système, fonctions kernel, événements réseau, tracepoints.

Le cycle de vie d’un programme eBPF est le suivant :

1. Compilation. Du code C restreint est compilé en bytecode eBPF via LLVM.
2. Chargement. Le bytecode est chargé via l’appel système bpf() et passe par le verifier — un validateur formel qui garantit l’absence de boucles infinies, de lectures mémoire hors limites, et de chemins d’exécution non terminés.
3. JIT. Le bytecode vérifié est compilé à la volée en instructions x86-64 ou ARM64 natives par le compilateur JIT du kernel.
4. Attachement. Le programme est attaché au hook choisi — XDP (eXpress Data Path) pour le traitement au niveau driver réseau, TC (Traffic Control) pour l’ingress/egress, ou un kprobe pour intercepter un appel système.

Pour le réseau, la différence avec iptables est radicale. Là où iptables évalue séquentiellement chaque règle, un programme eBPF utilise une hash table — la recherche est O(1) en temps constant, quel que soit le nombre d’entrées. Un map eBPF peut contenir des centaines de milliers d’entrées sans dégradation mesurable.

Cilium — le couteau suisse du réseau cloud natif

Cilium (v1.19 en avril 2026, distribué par Isovalent — acquis par Cisco en décembre 2023) est bien plus qu’un CNI. C’est une plateforme réseau complète qui exploite eBPF à chaque couche de la pile.

Remplacement de kube-proxy

Le premier cas d’usage qui justifie Cilium à lui seul. kube-proxy en mode iptables maintient une table de règles NAT pour chaque Service Kubernetes — ajouter un Service veut dire réécrire des milliers de règles iptables sur chaque nœud. Cilium remplace intégralement kube-proxy par un load balancer eBPF qui opère au niveau socket (connect()), pas au niveau paquet. Le backend est choisi au moment où la connexion est établie, sans réécriture d’adresse par paquet. Résultat :

# Remplacer kube-proxy par Cilium — une ligne
cilium install --kube-proxy-replacement=strict

En mode strict, Cilium prend en charge la totalité des services ClusterIP, NodePort, ExternalIPs et LoadBalancer sans une seule règle iptables. Les benchmarks internes d’Isovalent (2025) montrent une réduction de 90 % du temps d’ajout d’un nouveau Service sur un cluster de 100 nœuds.

Network Policies L7 — le firewall qui comprend HTTP

Les Network Policies Kubernetes natives filtrent au niveau L3/L4 : IP source, IP destination, port. Cilium étend ce modèle au L7 — vous pouvez écrire des règles qui comprennent le protocole applicatif :

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "api-http-rules"
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/public/.*"
        - method: "POST"
          path: "/api/v2/.*"
          headers:
          - "Authorization: Bearer .*"

La politique ci-dessus autorise le frontend à faire des GET sur /public/ et des POST sur /api/v2/ avec un token Bearer. Tout le reste est bloqué — pas au niveau IP, pas au niveau port, mais en inspectant le contenu HTTP directement dans le kernel via eBPF. Aucun sidecar Envoy, aucun proxy L7 dédié.

Les règles DNS-based ajoutent une couche supplémentaire : au lieu d’autoriser une IP, vous autorisez un FQDN. Cilium intercepte la résolution DNS, extrait l’adresse IP retournée, et l’injecte dynamiquement dans la politique — sans redémarrage, sans recompilation.

Chiffrement WireGuard transparent

Cilium active le chiffrement WireGuard entre tous les nœuds du cluster d’une seule commande :

cilium install --encryption=wireguard

Chaque paquet entre pods traverse un tunnel WireGuard automatiquement négocié entre les nœuds. Les clés sont gérées par Cilium et stockées dans Kubernetes Secrets. Pas de configuration IPsec, pas de certificats, pas de daemon externe. Pour un cluster multi-cloud ou bare-metal, c’est le niveau de chiffrement que les régulateurs exigent — sans l’effort opérationnel qui va avec.

Cluster Mesh — un seul réseau sur plusieurs datacenters

Cluster Mesh fédère plusieurs clusters Kubernetes en un seul réseau logique. Les services d’un cluster GCP peuvent appeler directement les pods d’un cluster AWS, avec la même identité de sécurité, les mêmes Network Policies L7, et le même chiffrement WireGuard. Le tout repose sur du routage eBPF — pas de VPN externe, pas de load balancer inter-cluster.

Hubble — l’observabilité qui ne coûte rien

Hubble est la plateforme d’observabilité intégrée à Cilium. Elle exploite les mêmes hooks eBPF que le datapath réseau pour exposer, sans overhead mesurable, le graphe complet des flux entre services :

• Service map temps réel. Quels pods parlent à quels pods, avec quel protocole, à quelle fréquence.
• Métriques L7. Codes HTTP 5xx/4xx par service, latence P95/P99 entre endpoints, volume d’appels gRPC.
• Visibilité DNS. Quels domaines sont résolus, par quels pods, avec quel code de retour.
• Drop reasons. Pourquoi un paquet a été rejeté — politique L3, politique L7, échec DNS — avec le label exact de la règle qui a bloqué.

# Observer tous les flux HTTP entre deux namespaces
hubble observe --from-namespace frontend --to-namespace backend --protocol http

Là où un Service Mesh classique (Istio + Envoy) injecte un sidecar proxy par pod — chaque proxy consomme de la RAM, du CPU, et ajoute une latence de saut supplémentaire — Hubble instrumente directement le datapath kernel. Le contraste est brutal : 300 Mo de RAM et 15 % de CPU économisés par nœud sur un cluster de production typique, selon le benchmark Isovalent de 2024.

Cilium vs Calico vs Flannel — le verdict en production

Calico reste un excellent choix pour les déploiements qui n’ont pas besoin de politiques L7 ni d’observabilité intégrée. Son mode eBPF comble partiellement le retard sur Cilium, mais la maturité et la couverture fonctionnelle ne sont pas au même niveau. Flannel est le choix de la simplicité maximale — un lab, un cluster de développement, une démonstration. Mais le jour où vous avez besoin d’une NetworkPolicy, vous migrez.

Le verdict — quand passer à Cilium

iptables n’a pas été conçu pour le cloud natif. C’est un firewall de 2001 qu’on a étiré jusqu’à lui faire router des clusters Kubernetes de plusieurs milliers de pods. Le fait qu’il tienne encore est un hommage à l’ingénierie du kernel Linux — mais c’est aussi un signal qu’il est temps de passer à autre chose.

Passez à Cilium si votre cluster dépasse 50 nœuds ou 5 000 pods, si vous avez besoin de Network Policies L7, si votre compliance exige le chiffrement inter-pods, ou si vous voulez voir ce qui se passe sur votre réseau sans y consacrer un budget observabilité séparé. Le kube-proxy replacement seul justifie la migration.

Gardez Calico si votre cluster est plus petit, vos politiques sont purement L3/L4, et vous voulez une solution éprouvée avec moins de surface de configuration.

Gardez Flannel si vous êtes en phase de prototypage et que la simplicité prime sur toute autre considération.

eBPF est en train de devenir la couche réseau par défaut de Linux — le kernel 7.0 (sorti en mars 2026) en fait un composant de premier plan avec des hooks étendus pour le scheduling et le stockage. Cilium est aujourd’hui l’expression la plus aboutie de cette révolution. iptables ne va pas disparaître — mais le laisser router votre cluster Kubernetes en 2026, c’est piloter une Formule 1 avec un carburateur de 2CV.

Références

• Cilium 1.19 Documentation — Introduction — architecture, fonctionnalités, cas d’usage
• ebpf.io — What is eBPF? — introduction officielle de la eBPF Foundation
• Cilium — kube-proxy Replacement — benchmark et comparaison iptables vs eBPF
• Cilium — Network Policy — politiques L3-L7 et DNS-based
• Cilium — Hubble Observability — service map et métriques
• Cilium — WireGuard Encryption — chiffrement transparent inter-nœuds
• Cilium — Cluster Mesh — fédération multi-cluster
• Cilium GitHub — v1.19 Changelog — historique des versions
• Linux Kernel 7.0 — eBPF enhancements — hooks étendus dans le kernel 7.0