Pendant trois ans, le débat autour des service mesh ressemblait à une guerre de religion. Istio contre Linkerd contre Consul Connect. Proxies sidecar contre modèles par agent. Overhead de performance contre richesse fonctionnelle. En 2026, ce débat a un vainqueur — et il s’exécute dans le noyau Linux.
Cilium, le projet réseau natif eBPF diplômé de la Cloud Native Computing Foundation (CNCF) en octobre 2023, s’est imposé comme la couche réseau par défaut pour les déploiements Kubernetes sérieux. Il n’a pas gagné par le marketing. Il a gagné en rendant les proxies sidecar aussi archaïques qu’ils le sont réellement.
Le modèle sidecar : une bonne idée devenue un problème
Pour comprendre pourquoi Cilium s’impose, il faut comprendre ce que coûtent les proxies sidecar.
Le modèle de service mesh traditionnel injecte un conteneur proxy — généralement Envoy — aux côtés de chaque conteneur applicatif dans un pod Kubernetes. Ce proxy intercepte tout le trafic entrant et sortant, applique le mTLS, applique les politiques réseau et émet de la télémétrie. Ça fonctionne. Mais chaque sidecar est un processus séparé qui consomme de la mémoire et du CPU, ajoute de la latence à chaque appel réseau et complique les séquences de démarrage des pods.
À grande échelle, les chiffres deviennent inconfortables. Un cluster avec 500 services génère 500+ sidecars Envoy, chacun consommant environ 50 à 100 Mo de mémoire et ajoutant 1 à 3 ms de latence par saut. Pour une application microservices avec 10 à 15 appels internes par requête utilisateur, cette taxe de latence s’accumule rapidement. L’overhead n’est pas seulement financier — il introduit une complexité opérationnelle, une friction dans le débogage et des maux de tête en planification capacitaire qui ralentissent les équipes plateforme.
Les données de l’enquête CNCF montrent que 62 % des équipes citent « l’overhead de ressources » comme leur principale frustration avec les service mesh. Ce chiffre explique pourquoi les alternatives basées sur eBPF ont gagné du terrain aussi rapidement.
eBPF : faire remonter le mesh dans le noyau
eBPF (extended Berkeley Packet Filter) permet à des programmes de s’exécuter en toute sécurité dans le noyau Linux sans modifier le code source du noyau ni charger de modules noyau. Initialement utilisé pour le filtrage de paquets réseau, eBPF a évolué vers une couche de programmabilité noyau à usage général. Cilium utilise eBPF pour implémenter le réseau, les politiques de sécurité et l’observabilité au niveau du noyau — en contournant complètement le besoin de proxies sidecar.
La différence de performance est mesurable. Les benchmarks indépendants montrent systématiquement que Cilium délivre :
- 40 à 60 % de latence en moins par rapport à Istio avec des sidecars Envoy sur des charges de travail équivalentes
- 50 à 70 % de réduction de l’overhead mémoire par nœud
- Démarrage des pods plus rapide grâce à l’absence d’injection sidecar ou d’initialisation de proxy
Ce ne sont pas des améliorations marginales. Elles représentent la différence entre une taxe plateforme que les équipes tolèrent et une qui force des compromis architecturaux.
Cilium y parvient parce que les programmes eBPF s’exécutent dans l’espace noyau, éliminant les changements de contexte user-space/kernel-space requis par les approches traditionnelles basées sur des proxies. Les paquets réseau sont traités là où ils naissent — dans le noyau — plutôt que d’être routés à travers un processus Envoy en espace utilisateur.
L’ascension de Cilium : du CNI à la plateforme complète
Cilium a débuté comme un plugin Container Network Interface (CNI) — le composant responsable de l’attribution d’adresses IP aux pods et de leur connectivité de base. L’adoption précoce par Google Kubernetes Engine, Amazon EKS et Azure AKS comme CNI par défaut recommandé a donné à Cilium une portée de distribution considérable. Des millions de clusters dans le monde tournaient déjà avec Cilium avant que la plupart des organisations réalisent qu’elles disposaient d’un service mesh intégré.
Le projet a régulièrement élargi son périmètre. Cilium a ajouté l’application des politiques réseau Layer 7 (filtrage des protocoles HTTP, gRPC et Kafka), le mTLS sans sidecar, le filtrage d’égress basé sur les FQDN pour contrôler le trafic sortant par nom de domaine, et Hubble — une couche d’observabilité native offrant une visibilité au niveau des flux sur l’ensemble du cluster avec une cartographie des services en temps réel et des métriques compatibles Grafana.
Le mouvement stratégique clé a été l’adoption du standard Kubernetes Gateway API. En alignant l’API de service mesh de Cilium sur le même Gateway API qu’Istio, Envoy Gateway et d’autres ciblent, Cilium est devenu compatible en configuration avec l’écosystème plus large. Les équipes peuvent écrire des configurations d’infrastructure contre le Gateway API et changer d’implémentation sous-jacente sans réécrire les politiques.
Fin 2025, Cilium recensait plus de 5 000 déploiements en production et est devenu la fondation réseau de plateformes notables incluant Adobe, Bell Canada et plusieurs systèmes internes de hyperscalers.
Publicité
La réponse d’Istio : l’ambient mesh
Istio n’a pas capitulé. La réponse du projet à Cilium est l’ambient mesh — une architecture sans sidecar ayant atteint la disponibilité générale en 2025.
L’ambient mesh remplace les sidecars par pod par deux composants partagés :
- ztunnel — un agent par nœud gérant le mTLS Layer 4 (TCP) et le routage simple, partagé entre tous les pods du nœud
- waypoint proxies — des instances Envoy optionnelles par namespace ou par service, déployées uniquement quand les fonctionnalités Layer 7 sont nécessaires
Ce modèle hybride permet aux équipes de choisir leur compromis. Le ztunnel pur délivre une connectivité zero-trust basique avec un overhead minimal. Les waypoint proxies peuvent être ajoutés pour les namespaces nécessitant du traffic shifting, des retries, de la manipulation d’en-têtes ou des extensions WASM.
Les propres benchmarks d’Istio montrent que l’ambient mesh consomme 70 % moins de mémoire que le modèle sidecar. Le composant ztunnel s’exécute toujours en espace utilisateur, ce qui signifie qu’Istio ambient n’est pas aussi léger que l’approche purement noyau de Cilium. Mais pour les équipes ayant des années d’investissement dans la configuration Istio, les extensions WASM et les personnalisations Envoy, l’ambient mesh est une mise à niveau pragmatique plutôt qu’un remplacement de plateforme.
Linkerd : le champion de la simplicité sous pression
Linkerd, qui a pionnerisé la catégorie des « service mesh légers », traverse une période difficile. Son proxy Rust est réellement plus léger qu’Envoy, et la simplicité opérationnelle du projet l’a rendu populaire dans les organisations d’ingénierie de taille moyenne. Mais Linkerd reste un mesh basé sur des sidecars. Face au discours sans-sidecar de Cilium, l’argument du « sidecar plus léger » devient plus difficile à défendre.
Une controverse de gouvernance en 2024 — lorsque Buoyant, le bailleur de fonds commercial, a tenté de modifier la licence de Linkerd — a créé une incertitude communautaire et ralenti l’adoption de la version open source. Plusieurs organisations qui évaluaient Linkerd ont redirigé leur évaluation vers Cilium ou Istio ambient.
En 2026, la position réaliste de Linkerd est de servir les organisations qui priorisent la simplicité opérationnelle sur les performances brutes et qui ont des environnements de conformité où le code noyau eBPF soulève des préoccupations d’audit.
Ce que cela signifie pour les équipes plateforme
Pour les équipes gérant des clusters Kubernetes en 2026, le cadre de décision est devenu considérablement plus clair :
Nouveaux clusters : Adoptez Cilium comme CNI par défaut. Activez immédiatement Hubble pour l’observabilité. Évaluez si les capacités natives de service mesh de Cilium satisfont vos exigences avant d’adopter une couche de service mesh séparée. La majorité des équipes découvrent qu’elles n’ont pas besoin de la complexité supplémentaire.
Déploiements Istio existants : Évaluez la migration vers l’ambient mesh. La transition depuis le mode sidecar est bien documentée et la compatibilité Gateway API signifie que la plupart des politiques se transfèrent proprement. Exécuter Cilium comme CNI sous Istio est également un pattern viable.
Durcissement sécurité : Les politiques d’égress basées sur les FQDN de Cilium résolvent une lacune de longue date de Kubernetes. Contrôler quels endpoints externes les pods peuvent atteindre — par nom de domaine plutôt que par adresse IP instable — apporte une amélioration significative de la posture de sécurité.
Observabilité sans instrumentation : Hubble capture automatiquement les flux réseau à travers tout le cluster sans nécessiter d’instrumentation au niveau applicatif. Les équipes qui peinent à faire fonctionner le tracing distribué de manière cohérente dans un environnement microservices polyglotte trouvent souvent que Hubble délivre 80 % de la valeur pour une fraction du coût opérationnel.
Questions Fréquemment Posées
Qu’est-ce que service mesh in 2026 ?
Cet article couvre les aspects essentiels de ce sujet, en examinant les tendances actuelles, les acteurs clés et les implications pratiques pour les professionnels et les organisations en 2026.
Pourquoi service mesh in 2026 est-il important ?
Ce sujet est important car il a un impact direct sur la façon dont les organisations planifient leur stratégie technologique, allouent leurs ressources et se positionnent dans un paysage en évolution rapide.
Quels sont les points clés à retenir de cet article ?
L’article analyse les mécanismes clés, les cadres de référence et les exemples concrets qui permettent de comprendre le fonctionnement de ce domaine, en s’appuyant sur des données actuelles et des études de cas.
Sources et lectures complémentaires
- Cilium diplômé de la CNCF — Cilium Project Blog
- Istio Ambient Mesh atteint la disponibilité générale — Istio.io
- Enquête annuelle CNCF 2024 — Cloud Native Computing Foundation
- Qu’est-ce qu’eBPF ? — eBPF.io
- Cilium vs Istio : une comparaison technique — Isovalent
- Kubernetes Gateway API v1.1 — Kubernetes Blog
