Making the Kernel Smarter
The sidecar model works well, but at scale its costs become significant. A cluster with 5,000 pods runs 5,000 Envoy processes. Each Envoy instance consumes roughly 50–100 MB of memory and adds latency because traffic must cross the userspace/kernel boundary twice per hop (once leaving the app, once entering the proxy, and again in reverse on the receiving side).
A newer approach, championed by Cilium, uses eBPF (Extended Berkeley Packet Filter) to eliminate this overhead.
What is eBPF? eBPF is a Linux kernel feature that allows you to load small, safe, sandboxed programs into the kernel at runtime — without modifying kernel source code or loading kernel modules. These programs run at extremely high speed because they execute inside the kernel itself, before packets ever reach userspace.
How a sidecar-less mesh works with eBPF:
Instead of injecting a proxy into every pod, Cilium installs eBPF programs onto the host node's kernel. These programs intercept network traffic at the kernel level and apply mesh features — load balancing, encryption, policy enforcement, and telemetry collection — without the traffic ever leaving the kernel to visit a userspace proxy.
The result:
- No sidecar containers. Pods contain only your application.
- Lower latency. Kernel-level processing is faster than userspace proxy hops.
- Lower memory usage. One eBPF program per node instead of one proxy per pod.
- Simpler pod specs. No sidecar injection, no init containers, no iptables rules.
The trade-off is operational complexity at the infrastructure level. eBPF programs require a modern Linux kernel (5.10+ for full Cilium features), and debugging eBPF behavior requires different tooling than inspecting an Envoy config dump. The sidecar model's transparency — being able to exec into a proxy and inspect its state — is harder to replicate with eBPF.