Cilium 1.18 transforme le CNI en plateforme de sécurité réseau pour Kubernetes
Sorti le 29 juillet 2025, Cilium 1.18 ajoute le Load Balancing redesign, le chiffrement overlay natif, le contrôle de bande passante entrant et le mTLS sans sidecar. Un an plus tard, cette version marque la bascule définitive du CNI vers une plateforme réseau complète.
29 juillet 2025. L’équipe Cilium publie la version 1.18 avec 3 298 commits, 955 contributeurs et une ambition claire : ne plus être un simple plugin CNI. Load Balancing redesign, chiffrement overlay natif, contrôle de bande passante entrant, Gateway API v1.3.0 et Mutual Authentication (mTLS) natif sans sidecar — la release coche toutes les cases d’une plateforme réseau.
Juillet 2026. Cilium est le CNI par défaut de GKE, AKS et EKS. Istio pousse son mode Ambient sans sidecar, Calico mise sur l’IA pour les opérations. Mais avec la 1.18, Cilium a posé un jalon qui dépasse la concurrence : il ne gère plus seulement le routage des paquets — il devient le plan de contrôle réseau et sécurité du cluster.
Ce que Cilium 1.18 apporte de réellement nouveau
La release est massive. Voici les cinq chantiers qui changent la donne.
Le Load Balancing repensé
Le plan de contrôle du load-balancing dans l’agent Cilium a été intégralement réécrit. Résultat direct : 45 % de temps en moins pour appliquer les politiques et les services dans les environnements à haute densité. La consommation mémoire de l’agent baisse significativement, ce qui libère des ressources sur les nœuds pour les charges applicatives.
Cette refonte est le fruit d’un travail de fond mené par Jussi Mäki et Damian Sawicki (Isovalent/Cisco), documenté dans la PR #38469. L’architecture est pensée pour être extensible : les futures évolutions du load-balancing s’intégreront sans nouvelle réécriture.
Le chiffrement overlay natif (VinE)
Cilium 1.18 introduit VXLAN in IPsec (VinE) — le chiffrement transparent du trafic overlay sans tunnel supplémentaire. Concrètement, le trafic inter-nœuds encapsulé en VXLAN est automatiquement chiffré par IPsec au niveau kernel, sans conteneur sidecar, sans proxy utilisateur. Le tout avec les performances eBPF qu’on attend de Cilium.
Cette brique est critique pour les clusters multi-tenant ou les déploiements sur des réseaux non fiables (cloud public, edge). Elle s’ajoute aux modes de chiffrement existants : WireGuard transparent et IPsec classique.
Contrôle de bande passante entrant
Le bandwidth manager de Cilium gérait déjà la limitation du trafic sortant au niveau du pod. La 1.18 y ajoute le contrôle entrant (ingress rate limiting) — PR #36351. Les équipes plateforme peuvent désormais définir des limites de bande passante bidirectionnelles par pod, sans toucher au code applicatif, directement dans les politiques réseau.
Mutual Authentication (mTLS) sans sidecar
C’est l’angle le plus agressif vis-à-vis d’Istio. Cilium embarque depuis la 1.14 un support beta de Mutual Authentication basé sur SPIFFE/SPIRE. En 1.18, cette brique est consolidée : le handshake mTLS entre agents Cilium est stable, le cache d’authentification permet un handshake par identité plutôt que par connexion, et l’intégration avec CiliumNetworkPolicy est fonctionnelle.
La différence avec Istio ? Zéro sidecar. L’authentification mutuelle s’exécute dans le kernel via eBPF. Pas de proxy Envoy par pod, pas de ztunnel à déployer, pas de waypoint proxy à configurer pour les politiques L7. Le tout est natif au CNI.
À noter : la fonctionnalité reste en beta en 1.18 — l’intégration avec WireGuard, le handshake par connexion et l’audit de sécurité sont planifiés pour les versions ultérieures. La version 1.20 (prévue mi-2026) devrait promouvoir le mTLS en stable.
Hubble : l’observabilité réseau sans agent externe
Hubble n’est pas nouveau, mais la 1.18 lui apporte trois améliorations décisives :
- Noms de politiques dans les flux : le CLI Hubble affiche désormais quelle
CiliumNetworkPolicya autorisé ou bloqué un flux. Fini legrepdans les YAML pour retrouver la règle fautive. - Champ
loglibre : chaque politique peut embarquer un champ texte libre, exposé dans les flux Hubble. Un moteur de recherche intégré dans votre plan de contrôle réseau. - Décodage du trafic encapsulé : Hubble décode le trafic VXLAN et Geneve, offrant une visibilité complète même sur les overlays chiffrés.
IPv6, BGP, Gateway API : le socle s’élargit
La 1.18 n’est pas qu’une release sécurité. Le socle réseau s’élargit sur trois fronts :
- IPv6 : le mode tunnel supporte désormais un underlay IPv6, y compris avec chiffrement IPsec. Le kube-proxy replacement fonctionne sur underlay IPv6. Les politiques Egress Gateway matchent des plages IPv6.
- BGP : les CRD BGP passent en API stable (
v1). L’agrégation de routes fait son entrée, tout comme la génération de Router ID par MAC ou pool IP. - Gateway API v1.3.0 : support natif de la spec Gateway API montée en v1.3.0, avec l’objet
CiliumGatewayClassConfigqui permet de paramétrer finement lesGatewayClass(IP source ranges, type de service, etc.).
Cilium, Calico, Istio : comment choisir en 2026
En juillet 2026, le paysage des CNI et service meshes a considérablement évolué. Voici la photographie.
Cilium : la plateforme tout-en-un
Forces : CNI + politiques réseau L3/L4/L7 + service mesh + observabilité + chiffrement, le tout dans le kernel via eBPF. Latence P99 de 0,9 ms en 1.18 (benchmarks Calico v3.28 vs Cilium v1.18). Pas de sidecar, pas de proxy utilisateur par pod. C’est la solution la plus performante et la plus intégrée.
Limites : complexité eBPF (le debugging kernel n’est pas trivial), mTLS encore beta en 1.18, pas de fault injection ni de circuit breaking (présents chez Istio).
Istio Ambient : le spécialiste L7
Forces : écosystème Envoy mature, fonctionnalités L7 avancées (canary, fault injection, retries, circuit breaking), ztunnel par nœud plutôt que sidecar par pod. Le mode Ambient réduit drastiquement l’overhead mémoire par rapport au mode sidecar historique.
Limites : CNI externe obligatoire (Calico ou Cilium en dessous), deux couches à maintenir (ztunnel + waypoint), Windows non supporté.
Calico : la simplicité opérationnelle
Forces : simplicité de déploiement, politiques réseau standard Kubernetes NetworkPolicy sans CRD, AI Assistant (v3.31+) pour le troubleshooting en langage naturel, BGP natif.
Limites : pas de L7 sans CRD additionnelle, pas de service mesh intégré, latence supérieure à Cilium (iptables vs eBPF).
Verdict
Si votre cluster tourne déjà avec Cilium en version antérieure et que vous utilisez le load-balancing ou les politiques réseau à grande échelle, la migration vers la 1.18 est un no-brainer — le gain de performance sur l’application des politiques (45 %) et la réduction de consommation mémoire la justifient à eux seuls.
Si vous partez d’une feuille blanche et que la sécurité réseau est votre priorité numéro un, Cilium 1.18 vous donne un plan de contrôle réseau complet sans multiplier les briques : CNI, politiques, chiffrement, observabilité, Gateway API et mTLS dans un seul déploiement. C’est moins de YAML à maintenir qu’un stack Calico + Istio Ambient.
Si vous avez besoin de L7 avancé (fault injection, circuit breaking, retries complexes), Istio Ambient reste le meilleur choix — mais gardez Cilium comme CNI sous-jacent. Les deux ne sont pas mutuellement exclusifs : Cilium documente officiellement l’intégration avec Istio, y compris en mode Ambient.
Un an après sa sortie, Cilium 1.18 reste le marqueur d’un changement de catégorie. Ce n’est plus un CNI qu’on compare à Flannel ou Calico. C’est une plateforme réseau qui rivalise avec Istio sur le terrain du service mesh, avec Calico sur les politiques, et qui gagne sur les deux tableaux quand la performance kernel est critique.
Références
- Cilium 1.18.0 Release Notes — GitHub, 29 juillet 2025
- Cilium 1.18 Blog Post — Isovalent — Isovalent/Cisco, 7 août 2025
- Cilium Mutual Authentication Documentation — docs.cilium.io
- Service Mesh: Istio vs Cilium vs Linkerd 2026 — Luca Berton, 2026
- Cilium vs Calico: The 2026 Kubernetes CNI Showdown — Sanj, mars 2026
- Load Balancing Redesign — PR #38469 — cilium/cilium
- Ingress Rate Limiting — PR #36351 — cilium/cilium