Observabilité sans instrumentation : comment eBPF a remplacé la flotte de sidecars
Engineering Team
67% des équipes Kubernetes sont passées à l’observabilité eBPF
Selon l’enquête annuelle CNCF 2026, 67% des équipes Kubernetes utilisent désormais des outils basés sur eBPF pour au moins un pilier d’observabilité (métriques, traces ou logs) — contre 29% en 2024 et 41% en 2025.
La raison est simple : l’observabilité traditionnelle basée sur les sidecars (proxys Envoy, sidecars OpenTelemetry Collector, agents Datadog) consomme d’énormes ressources, ajoute de la latence à chaque requête et nécessite des modifications de code ou de conteneur. eBPF fait tout depuis le noyau — sans aucune modification d’application.
Qu’est-ce qu’eBPF et pourquoi c’est important
eBPF (extended Berkeley Packet Filter) est une technologie qui permet d’exécuter des programmes sandboxés à l’intérieur du noyau Linux sans modifier le code source du noyau. Initialement conçu pour le filtrage de paquets réseau, eBPF est devenu un framework de programmabilité kernel à usage général.
Comment ça marche
- Écrire un petit programme en C ou Rust
- L’attacher à un point d’accrochage kernel — syscalls, événements réseau, tracepoints
- Le vérificateur eBPF du kernel vérifie la sécurité du programme
- Le compilateur JIT traduit le bytecode eBPF en instructions machine natives
- Le programme s’exécute au point d’accrochage avec des performances quasi-natives
// Programme eBPF simplifié pour tracer les requêtes HTTP
SEC("kprobe/tcp_v4_connect")
int trace_connect(struct pt_regs *ctx) {
struct sock *sk = (struct sock *)PT_REGS_PARM1(ctx);
u32 pid = bpf_get_current_pid_tgid() >> 32;
u16 dport = sk->__sk_common.skc_dport;
u32 daddr = sk->__sk_common.skc_daddr;
struct event_t event = {
.pid = pid,
.dport = ntohs(dport),
.daddr = daddr,
.timestamp = bpf_ktime_get_ns(),
};
bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU,
&event, sizeof(event));
return 0;
}
Pourquoi c’est important pour l’observabilité
L’observabilité traditionnelle nécessite l’instrumentation. Cette approche a trois problèmes fondamentaux :
- Surcharge de ressources — chaque sidecar consomme CPU et mémoire. Dans un cluster de 500 pods avec sidecars Envoy, les sidecars peuvent consommer 30-40% des ressources totales.
- Lacunes de couverture — vous ne pouvez observer que ce que vous instrumentez.
- Charge de maintenance — chaque langage et framework nécessite sa propre bibliothèque d’instrumentation.
eBPF résout les trois : il s’exécute dans le noyau (zéro surcharge applicative), voit tout ce que le noyau voit (pas de lacunes) et fonctionne indépendamment du langage.
Le stack d’observabilité eBPF en 2026
Cilium + Hubble : observabilité réseau
Cilium est le CNI de facto pour Kubernetes. Hubble fournit :
- Visibilité des flux L3/L4 — chaque connexion TCP/UDP entre pods
- Parsing des protocoles L7 — HTTP, gRPC, Kafka, DNS, PostgreSQL sans modification d’application
- Audit des politiques réseau — visualisation en temps réel du trafic autorisé/refusé
- Cartographie des dépendances — génération automatique du graphe de services
Pixie : monitoring de performance applicative
Pixie (projet sandbox CNCF) fournit un APM sans instrumentation :
- Tracing automatique des protocoles — HTTP/1.1, HTTP/2, gRPC, PostgreSQL, MySQL, Redis, Kafka, DNS
- Profilage CPU continu — flamegraphs depuis les stack traces eBPF
- Logging dynamique — ajout de points de trace sans redéploiement
- Capture complète requête/réponse — headers HTTP, requêtes SQL, payloads gRPC réels
Tetragon : sécurité runtime et audit
Tetragon (par Isovalent/Cilium) est un outil de sécurité et d’observabilité basé sur eBPF :
- Suivi d’exécution des processus — chaque événement exec, fork et exit
- Surveillance d’accès fichiers — suivi des lectures, écritures et changements de permissions
- Audit des connexions réseau — log de chaque connexion sortante avec contexte processus
- Application des politiques de sécurité — blocage d’activités suspectes en temps réel
Grafana Beyla : auto-instrumentation
Grafana Beyla est un agent d’auto-instrumentation basé sur eBPF :
- Détecte les requêtes HTTP, gRPC, SQL et Redis au niveau kernel
- Émet des spans OpenTelemetry avec propagation du contexte de trace
- S’intègre avec Grafana Cloud, Tempo, Mimir et tout backend OpenTelemetry
Performance : les chiffres qui comptent
Benchmarks réels d’un cluster Kubernetes de production de 500 pods :
Comparaison d’utilisation mémoire
| Composant | Approche sidecar | Approche eBPF | Économie |
|---|---|---|---|
| Sidecars Envoy (500 pods) | 50 GB | 0 (Cilium CNI) | 50 GB |
| Sidecars OTel Collector (500 pods) | 15 GB | 0 (Beyla DaemonSet) | 15 GB |
| Agents Cilium (20 nœuds) | N/A | 8 GB | -8 GB |
| Agents Beyla (20 nœuds) | N/A | 2 GB | -2 GB |
| Total | 75 GB | 12 GB | Réduction de 84% |
Surcharge CPU
| Métrique | Approche sidecar | Approche eBPF |
|---|---|---|
| Latence ajoutée par requête | 1-5ms | <0.1ms |
| Surcharge CPU par nœud | 8-12% | <1% |
| Impact latence de queue (p99) | +15-30ms | <1ms |
Guide de migration : des sidecars vers eBPF
Phase 1 : déployer les outils eBPF aux côtés des sidecars (semaines 1-2)
- Installer Cilium comme CNI
- Déployer Hubble pour l’observabilité réseau
- Déployer Beyla comme DaemonSet
- Exécuter les deux stacks en parallèle
Phase 2 : valider et ajuster (semaines 3-4)
- Vérifier que les outils eBPF capturent les mêmes signaux
- Ajuster la détection de protocoles de Beyla
- Configurer des tableaux de bord miroirs
Phase 3 : supprimer les sidecars progressivement (semaines 5-8)
- Commencer par les services non-critiques
- Surveiller les régressions de qualité de données
- Supprimer les sidecars Envoy des services qui n’en ont pas besoin
Phase 4 : stack eBPF complet (semaines 9-12)
- Supprimer les sidecars restants
- Déployer Tetragon pour la sécurité runtime
- Consolider les alertes sur les signaux eBPF
- Récupérer les ressources libérées
Questions fréquentes
L’observabilité eBPF fonctionne-t-elle avec les charges non-Kubernetes ?
Oui. eBPF s’exécute au niveau du noyau Linux, donc fonctionne avec toute charge de travail.
eBPF peut-il remplacer le tracing distribué ?
Pour de nombreuses équipes, oui. Mais les traces eBPF sont limitées aux frontières requête/réponse.
Qu’en est-il du trafic chiffré (TLS) ?
Les outils eBPF peuvent tracer le trafic TLS en s’attachant aux fonctions de la bibliothèque TLS.
eBPF est-il sûr ? Un programme eBPF défectueux peut-il crasher le noyau ?
Non. Le vérificateur eBPF vérifie chaque programme avant chargement. Un programme défectueux échouera au chargement.
Comment eBPF gère-t-il les services à haut débit (100K+ requêtes/seconde) ?
Par agrégation in-kernel et échantillonnage. Les programmes eBPF calculent des histogrammes dans les maps kernel.