eBPF : La technologie du noyau Linux qui redéfinit le cloud networking et la sécurité

Il existe une technologie qui fonctionne silencieusement dans le noyau Linux chez Google, Meta, Netflix et Cloudflare. Elle n’a pas été conçue pour être à la mode. Elle a été conçue pour être rapide, sûre et invisible. Elle s’appelle eBPF — extended Berkeley Packet Filter — et elle est en train de réécrire discrètement les règles du cloud networking, de l’observabilité et de la sécurité.

Si vous gérez des clusters Kubernetes en 2026 et que vous n’avez pas encore entendu parler d’eBPF, vous êtes sur le point de comprendre pourquoi votre prochain upgrade infrastructure l’impliquera.

Du filtre de paquets à la super-puissance du noyau

Le Berkeley Packet Filter original (BPF) a été introduit en 1992. Son objectif était modeste : permettre aux programmes de filtrer les paquets réseau dans le noyau sans les copier vers l’espace utilisateur. Il était efficace, mais limité dans sa portée.

La version « étendue » — eBPF — est arrivée dans Linux 3.18 en 2014 et n’a cessé d’évoluer depuis. Le saut conceptuel a été immense : eBPF permet aux développeurs d’exécuter des programmes personnalisés et sandbox directement dans le noyau Linux, attachés à pratiquement n’importe quel événement noyau — paquets réseau, appels système, points d’entrée et de sortie de fonctions, compteurs matériels.

C’est crucial car traverser la frontière entre l’espace utilisateur et l’espace noyau est coûteux. Chaque appel système, chaque changement de contexte consomme des cycles CPU. eBPF élimine cette frontière pour une classe soigneusement contrainte d’opérations. Vous obtenez des performances au niveau du noyau sans écrire un module noyau — et sans le risque de faire planter le système.

Comment fonctionne eBPF : bytecode, vérificateur, JIT

Lorsqu’un développeur écrit un programme eBPF (typiquement dans un sous-ensemble restreint du C), il est compilé en bytecode BPF — une représentation intermédiaire portable. Avant que ce bytecode soit autorisé à approcher le noyau, il passe par le vérificateur eBPF.

Le vérificateur est la garantie de sécurité. Il analyse statiquement chaque chemin d’exécution possible du programme. Il vérifie que le programme se termine (pas de boucles infinies), qu’il n’accède jamais à de la mémoire hors limites, qu’il ne déréférence jamais des pointeurs nuls, et qu’il reste dans des limites de complexité définies. Seul un programme qui réussit tous les contrôles est chargé dans le noyau.

Une fois vérifié, le compilateur Just-In-Time (JIT) traduit le bytecode BPF en instructions machine natives pour le CPU hôte. Le résultat s’exécute à une vitesse quasi-native, comme s’il faisait partie du noyau lui-même.

Les programmes communiquent avec l’espace utilisateur via des eBPF maps — des structures de données clé-valeur qui vivent en mémoire noyau mais sont accessibles depuis l’espace noyau et l’espace utilisateur. C’est ainsi que les métriques sont remontées, que la configuration est transmise, et que les événements sont streamés.

Les points d’attache — appelés hooks — vont des interfaces réseau (XDP, TC) aux entrées et sorties des appels système, en passant par les sondes de fonctions noyau (kprobes, tracepoints) et les sondes de fonctions espace utilisateur (uprobes). La richesse de ces hooks est ce qui rend eBPF si polyvalent.

Cas d’usage 1 : le networking — Cilium remplace kube-proxy

Kubernetes a toujours eu besoin d’une couche réseau. Pendant des années, cette couche reposait sur iptables, géré par kube-proxy. iptables a été conçu pour une ère plus simple. Dans des clusters comportant des centaines de services, les tables de règles iptables se gonflent à des dizaines de milliers d’entrées. Chaque nouvelle connexion déclenche un scan séquentiel. Les performances se dégradent linéairement avec la taille du cluster.

Cilium, le projet diplômé CNCF soutenu par Isovalent (acquis par Cisco en 2023), remplace kube-proxy entièrement par eBPF. Au lieu de règles iptables, Cilium programme des décisions de routage au niveau noyau directement sur les paquets réseau. Le suivi des connexions, l’équilibrage de charge et l’application des politiques se font dans le noyau avant que les paquets n’atteignent l’espace utilisateur.

Les résultats de performance sont spectaculaires. Les benchmarks d’Isovalent montrent que Cilium gère le routage des requêtes HTTP avec une latence 30 à 40 % plus faible et un débit significativement plus élevé par rapport aux configurations basées sur iptables, en particulier à mesure que la taille du cluster augmente. GKE Dataplane V2 de Google, qui alimente des millions de nœuds Kubernetes, est construit sur Cilium.

Au-delà des performances, Cilium permet des politiques réseau basées sur l’identité. Au lieu de filtrer le trafic par adresse IP — qui change constamment dans les environnements cloud dynamiques — Cilium attribue des identités cryptographiques aux workloads et applique des politiques basées sur ces identités. C’est un modèle fondamentalement plus fiable pour la sécurité cloud-native.

Cas d’usage 2 : l’observabilité — Hubble, Pixie et Parca

Le second grand domaine transformé par eBPF est l’observabilité. La surveillance traditionnelle des performances applicatives nécessite de l’instrumentation : les développeurs doivent ajouter des bibliothèques de tracing, des SDK de métriques et des agents de logging à chaque service. Cela crée une surcharge, des maux de tête liés au versionnage, et des lacunes là où l’instrumentation est absente.

eBPF change le modèle. Parce que les hooks eBPF se trouvent au niveau du noyau, ils peuvent observer chaque connexion réseau, chaque appel système et chaque invocation de fonction — sans aucune modification du code applicatif. C’est ce qu’on appelle l’observabilité zéro-instrumentation.

Hubble, la couche d’observabilité construite sur Cilium, offre une visibilité en temps réel sur les flux réseau à travers un cluster Kubernetes. Il montre quels services communiquent avec quels autres, quelles requêtes DNS sont effectuées, où les connexions échouent — le tout remonté depuis les données eBPF sans toucher aucune application.

Pixie, développé chez New Relic et maintenant projet sandbox CNCF, va plus loin. Il utilise eBPF pour capturer automatiquement le trafic HTTP/2, gRPC, PostgreSQL, Redis et Kafka — donnant aux ingénieurs des traces de niveau applicatif sans aucun changement de code. Pour les équipes gérant des dizaines de microservices, c’est transformationnel.

Parca apporte le profiling continu au même paradigme. En utilisant un échantillonnage basé sur eBPF, il profile l’utilisation CPU au niveau des fonctions à travers chaque processus d’un hôte, sans nécessiter d’agent de profiling au niveau applicatif. Le résultat : des flame graphs à l’échelle de la flotte qui révèlent exactement où les cycles CPU sont dépensés en production.

Cas d’usage 3 : la sécurité — Falco et Tetragon

La surveillance de la sécurité s’est longtemps appuyée sur des logs d’audit, des modules noyau ou des containers sidecar — chaque approche entraînant des coûts de performance ou une fragilité. eBPF offre une meilleure fondation.

Falco, le projet de sécurité CNCF développé à l’origine par Sysdig, utilise eBPF pour surveiller les appels système en temps réel. Quand un container tente d’écrire dans un chemin sensible, de spawner un shell inattendu, ou d’ouvrir un socket réseau vers une destination non reconnue, Falco déclenche une alerte — instantanément, avec le contexte complet du processus.

Tetragon, le composant d’application de la sécurité développé par Isovalent aux côtés de Cilium, va au-delà de la détection. Tetragon peut appliquer des politiques de sécurité directement dans le noyau via eBPF. Il peut bloquer un appel système avant qu’il ne s’exécute, tuer un processus qui viole une politique, ou restreindre l’accès réseau — tout cela sans aucun sidecar ajoutant de la latence ou aller-retour vers l’espace utilisateur. C’est l’application de la sécurité à l’exécution à la vitesse du noyau.

L’importance de cela pour les workloads cloud ne saurait être surestimée. Les attaques d’évasion de container, les élévations de privilèges et les exfiltrations de données réussissent souvent parce que les systèmes de détection voient l’activité seulement après qu’elle s’est déjà produite dans l’espace utilisateur. Les outils de sécurité basés sur eBPF peuvent intercepter et bloquer au point d’exécution.

Qui utilise eBPF à grande échelle

La liste des adopteurs ressemble à un registre des stars de l’infrastructure. Meta (Facebook) utilise des load balancers et une mitigation DDoS basés sur eBPF en production depuis 2017. Cloudflare utilise le hook XDP (eXpress Data Path) d’eBPF pour éliminer le trafic malveillant à la vitesse du câble — avant même qu’il entre dans la pile réseau du noyau — en gérant des térabits de trafic par seconde.

Netflix utilise eBPF pour le profiling en production et l’analyse de performance à travers son immense flotte de serveurs de streaming. Google fait tourner Cilium comme fondation de GKE Dataplane V2. Microsoft utilise eBPF dans la pile réseau d’Azure. La Linux Foundation a formalisé la communauté en 2021 en créant l’eBPF Foundation, avec Meta, Google, Microsoft, Netflix, Isovalent et d’autres comme membres fondateurs.

Limitations et exigences de version noyau

eBPF n’est pas sans contraintes. La barrière pratique la plus significative est la version du noyau. De nombreuses fonctionnalités eBPF nécessitent Linux kernel 5.x ou plus récent ; certaines capacités avancées (comme BTF — BPF Type Format — qui permet des programmes eBPF portables) requièrent la version 5.2+, et certaines fonctionnalités de Cilium nécessitent la 5.10 ou ultérieure. Les entreprises qui font tourner des distributions Linux plus anciennes peuvent se trouver bloquées ou limitées.

Le vérificateur eBPF, bien qu’essentiel pour la sécurité, impose également des limites de complexité. Les programmes trop volumineux ou trop complexes seront rejetés. Écrire du code eBPF correct et compatible avec le vérificateur nécessite une connaissance approfondie des internes du noyau Linux — une compétence qui reste rare.

La sécurité est une préoccupation dans les environnements multi-tenants. Bien que les programmes eBPF soient vérifiés avant chargement, l’acte de charger un programme nécessite des privilèges élevés. Dans des clusters Kubernetes partagés, permettre aux workloads de charger des programmes eBPF arbitraires serait dangereux. Les modèles de déploiement restreignent typiquement le chargement de programmes eBPF à des daemonsets privilégiés exécutés par des administrateurs de cluster.

Enfin, déboguer des programmes eBPF est significativement plus difficile que déboguer des applications conventionnelles. Des outils comme bpftool, bpftrace et la boîte à outils BCC aident, mais la courbe d’apprentissage est raide.

La route à venir

L’écosystème eBPF en 2026 mûrit rapidement. La communauté de développement noyau continue d’étendre l’ensemble des hooks disponibles, d’augmenter les limites de complexité des programmes, et d’améliorer la portabilité via CO-RE (Compile Once, Run Everywhere) — un mécanisme permettant à un seul binaire eBPF compilé de fonctionner sur différentes versions de noyau sans recompilation.

Les architectures service mesh sont en train d’être reconstruites autour d’eBPF. Ambient Mesh dans Istio, les expériences de dataplane eBPF de Linkerd, et l’offre service mesh de Cilium pointent tous vers un avenir où le plan de contrôle réseau réside entièrement dans le noyau, et non dans des containers sidecar.

Pour les ingénieurs cloud, la trajectoire est claire : eBPF n’est pas une curiosité de recherche de niche. C’est la fondation sur laquelle est construite la prochaine génération d’outils de cloud networking, d’observabilité et de sécurité. La comprendre — même à un niveau conceptuel — devient une exigence de base pour le travail sérieux en infrastructure.

Sources et lectures complémentaires

• Qu’est-ce qu’eBPF ? — eBPF.io (eBPF Foundation)
• Benchmark CNI : comprendre les performances réseau de Cilium — Blog Cilium
• Documentation Falco — CNCF / Sysdig
• Tetragon : application de la sécurité basée sur eBPF — Isovalent
• Outils de tracing eBPF et documentation — Brendan Gregg
• Pixie : observabilité Kubernetes avec eBPF — px.dev