eBPF (extended Berkeley Packet Filter) became the foundational technology for a new generation of Linux observability and networking tools in 2021. It allows safe, programmable code to run in the Linux kernel without modifying kernel source or loading kernel modules.
What eBPF actually does
eBPF allows small programs to be loaded into the Linux kernel and attached to hooks, system calls, network events, function entry/exit points. The programs are verified by the kernel before loading to ensure they cannot crash the kernel or loop infinitely. Once loaded, they execute in kernel context with access to kernel data structures, at the point where events occur, with near-zero overhead compared to userspace tracing.
Cilium and kernel-bypass networking
Cilium uses eBPF to implement Kubernetes network policies and service mesh without sidecar proxies. Traditional Kubernetes networking uses iptables rules that are evaluated sequentially for every packet. eBPF replaces iptables with kernel-bypass code paths that operate at line rate. At cluster scale, the performance difference is significant: iptables does not scale linearly with rule count.
Pixie and zero-instrumentation observability
Pixie uses eBPF to collect telemetry from Kubernetes workloads without any application-level instrumentation. It captures HTTP/1, HTTP/2, gRPC, SQL, Redis, and Kafka traffic by intercepting system calls, producing request/response traces and latency metrics for all services automatically. For organisations that have not instrumented their applications, Pixie provides immediate visibility with no code changes.
The production consideration
eBPF programs run in kernel space. The verification step prevents crashes but a verified program can still produce high CPU overhead if poorly written. The tooling for debugging eBPF programs is less mature than userspace debugging. eBPF requires a recent Linux kernel (5.x for the most capable features) which limits adoption in organisations running older kernels on long-support distributions.