Cilium 1.20 élargit le Gateway API, active l’IPv6 ENI sur AWS et ouvre le datapath aux plugins
Cilium 1.20, publié le 14 septembre 2026, fait du Gateway API sa couche de routage complète et comble le fossé IPv6 en mode ENI sur AWS. Les équipes qui doivent migrer d’ingress-nginx ou étendre leur CNI y trouveront une raison de franchir le pas.
14 septembre 2026. L’équipe Cilium publie la version 1.20, sa deuxième mouture majeure de l’année. Le Gateway API passe de la version 1.4 à 1.6 et gagne ExternalAuth, les routes TCP/UDP et les ListenerSets. L’IPv6 arrive enfin en mode ENI IPAM sur AWS. Pourquoi c’est important : le CNI que vous exécutez déjà peut désormais absorber votre couche de routage nord-sud, au moment précis où ingress-nginx entame sa retraite.
Le Gateway API devient une vraie couche de routage
Le saut le plus visible est celui du Gateway API. Cilium 1.20 passe de la v1.4 à la v1.6 et ajoute trois briques qui changent la donne pour les équipes plateforme. ExternalAuth déporte l’authentification et l’autorisation avant qu’une requête n’atteigne l’application — un traitement jusqu’ici confié à des contrôleurs d’ingress dédiés. Les filtres CORS et les ListenerSets rapprochent le Gateway API d’un vrai frontal d’entrée. Et surtout, les routes TCPRoute et UDPRoute étendent la gestion au trafic non-HTTP, là où ingress-nginx ne savait faire que du L7.
Le message est explicite dans la note de version : si vous exécutez encore Ingress NGINX, le CNI que vous faites déjà tourner peut reprendre ce trafic. C’est un enjeu de consolidation — une seule brique réseau au lieu de deux — mais aussi une question de calendrier. Nous avons couvert la retraite d’ingress-nginx sur ce blog : le projet n’est plus maintenu activement, et le Gateway API est la trajectoire de sortie.
L’IPv6 ENI sur AWS, quatre ans après la demande
La seconde annonce majeure est technique et attendue depuis longtemps. En mode ENI IPAM — le mode spécifique à AWS qui donne aux pods de vraies adresses de VPC — Cilium ne supportait que l’IPv4. Cilium 1.20 active l’IPv6 en bêta, quatre ans après la demande initiale. L’opérateur attache un préfixe /80 à l’ENI de chaque nœud via Prefix Delegation, et l’agent distribue les adresses aux pods.
La configuration tient en trois lignes :
ipam:
mode: eni
eni:
enabled: true
ipv6:
enabled: trueLes pods démarrent alors en dual-stack avec une IPv6 routable dans le VPC :
NAME IPS
dualstack-demo-7f8876746b-5xvnk 192.168.128.71,2a05:d01c:38d:4c02:909e::e771Le mérite revient à Datadog, qui a construit le support IPv6 ENI et refermé ce qui restait de l’écart de parité IPv4/IPv6 dans Cilium. Pour les plateformes EKS qui approchent de l’épuisement d’adresses IPv4 privées, c’est la porte de sortie sans migration vers un autre CNI.
Netkit en mode automatique : la performance sans le casse-tête
Cilium 1.20 ajoute aussi bpf.datapathMode=auto pour le netkit, le périphérique réseau pod qui remplace la paire veth et amène le débit au niveau de l’hôte. Le problème jusqu’ici : netkit exigeait un noyau 6.8 ou plus, ce qui obligeait les flottes hétérogènes à découper leurs nœuds par version de noyau. Avec le mode auto, chaque agent sonde son hôte au démarrage, utilise netkit quand le noyau le permet et retombe sur veth sinon.
$ cilium-dbg status | grep Device
Device Mode: netkit [Configured: auto]L’enjeu n’est pas théorique. Meta a déployé netkit sur des millions de conteneurs et ByteDance à une échelle comparable, avec un gain de 10 % mesuré dans ses tests. Une seule option à configurer sur une flotte mixte, et vous héritez de cette performance au fil du renouvellement des nœuds.
Datapath Plugins : Cilium devient un système d’exploitation réseau
L’annonce la plus structurante est celle des datapath plugins (bêta). Jusqu’à présent, étendre le datapath eBPF de Cilium se résumait à deux options : contribuer en amont, ou maintenir un fork. Google, qui maintenait son propre fork, a construit la troisième voie : un code tiers s’instrumente comme un plugin, tourne dans un processus séparé que Cilium interroge, et évolue sur son propre cycle de publication.
apiVersion: cilium.io/v2alpha1
kind: CiliumDatapathPlugin
metadata:
name: example
spec:
attachmentPolicy: Always
version: 0.0.1La métaphore des mainteneurs est assumée : Cilium ressemble moins à un appareil réseau scellé qu’à un système d’exploitation réseau, un noyau stable que les fournisseurs cloud étendent avec leurs propres programmes eBPF. Un plugin qui plante n’emporte pas l’agent avec lui, et son image se versionne indépendamment de Cilium.
Le reste : anti-spoofing fin, MCS stable et BGP
Deux autres changements méritent l’attention. La vérification d’IP source — qui empêche un pod compromis d’usurper l’adresse d’un voisin — devient désactivable par pod plutôt que pour tout le cluster. Les appliances NAT, pare-feu ou passerelles VPN/Tailscale peuvent émettre avec une source étrangère sans affaiblir l’anti-spoofing partout ailleurs. Côté standardisation, l’API Multi-Cluster Services passe en stable et ClusterNetworkPolicy s’aligne sur l’API Kubernetes : Cilium continue d’offrir ses CRD natives à côté des ressources portables.
Le BGP n’est pas en reste, avec un avertissement de migration : les sous-commandes on-agent cilium-dbg bgp et l’API REST BGP locale sont dépréciées au profit des équivalents cilium-dbg shell. L’interface utilisateur de cilium bgp ne change pas.
Verdict
Cilium 1.20 est la version qui transforme une mise à niveau de CNI en décision d’architecture. Si vous êtes encore sur ingress-nginx, le Gateway API v1.6 avec ExternalAuth et les routes TCP/UDP est une raison suffisante pour planifier la bascule — d’autant que le projet ingress-nginx est en retraite. Si vous exploitez EKS et frôlez l’épuisement d’IPv4, activez le mode ENI IPv6 en bêta plutôt que d’ajouter des NAT compliqués. Si vous êtes un fournisseur cloud ou une grande flotte, les datapath plugins suppriment le coût de maintenance d’un fork. Dans tous les cas, le passage reste progressif : le défaut reste veth, et rien ne change tant que vous n’activez pas les nouvelles options.