eBPF matters because it changes not just one utility, but the level at which engineers can observe system behavior.
The chapter connects kernel programmability, the network stack, observability, and runtime protection into one platform story where deep visibility no longer requires the old cost of changing the kernel.
In design reviews and retrospectives, it helps you discuss hook points, the boundary between kernel space and user-space tools, and the operational cost of that visibility.
Practical value of this chapter
Design in practice
Turn guidance on eBPF evolution and kernel-level visibility into concrete operational decisions: alert interfaces, runbook boundaries, and rollback strategy.
Decision quality
Evaluate architecture via SLO, error budget, MTTR, and critical-path resilience rather than feature completeness alone.
Interview articulation
Frame answers around the reliability lifecycle: degradation signal, response, root-cause isolation, recovery, and prevention loop.
Trade-off framing
Make trade-offs explicit for eBPF evolution and kernel-level visibility: release speed, automation level, observability cost, and operational complexity.
eBPF: The Documentary
Unlocking The Kernel — the story of eBPF and kernel programmability
Source
Book cube
Film review from Alexander Polomodov
What is eBPF
Looking deep into a running system, or changing its behavior, used to mean touching the kernel — patching sources or loading a separate module, with the risk of crashing the machine. eBPF (extended Berkeley Packet Filter) removes that trade-off: small programs run safely in kernel context and extend operating-system behavior without changing kernel source code or loading a separate kernel module.
Safety here rests on verification, not trust. After loading, an eBPF program passes through the kernel verifier, which rejects unsafe operations and checks that execution terminates — a program with an infinite loop never gets to run. The program is then interpreted or JIT-compiled so it can run with low overhead.
The execution model is event-driven: a program attaches to a kernel hook point such as a system call, network event, or tracing point, and runs only when that event occurs.
This chapter treats eBPF as practical kernel programmability: a bridge between kernel space, user space, observability, profiling, and runtime protection.
eBPF timeline
Classic BPF
The original idea was narrow: safe packet filtering and fast selection of relevant network traffic inside the kernel.
A virtual machine inside the kernel
Alexei Starovoitov proposed the extended model: bytecode, a verifier, and safe program execution next to system events.
Tracing tools
bcc and bpftrace made eBPF practical for performance engineers through profiling, network diagnostics, and latency investigation workflows.
Platform layer
Cilium, Falco, and related tools turned eBPF into a foundation for network policy, observability, and runtime protection.
Related topic
Site Reliability Engineering
Reliability and observability practices from Google
Creation story
The idea
Alexei Starovoitov was working at PLUMgrid on software-defined networking when he proposed a safe virtual machine inside the Linux kernel. The key was eBPF bytecode plus a kernel verifier that checks each program before it runs.
The evolutionary path
Chris Wright from Red Hat suggested evolving the existing BPF subsystem instead of introducing a completely separate mechanism. That pragmatic path made extended Berkeley Packet Filter acceptable to the kernel community.
Tracing and profiling
The first focus was networking, but tracing and profiling quickly became the killer use cases. Brendan Gregg helped make eBPF practical through tools that became bcc and bpftrace.
Large-scale adoption
eBPF proved useful at Meta, Google, Netflix, and other hyperscalers because it provided deep visibility without heavy application instrumentation.
Ecosystem development
Cilium
Isovalent made Cilium one of the main bridges between eBPF and Kubernetes: networking, policy, load balancing, and observability became platform capabilities rather than separate agents.
Runtime protection
When an attack runs through system calls, in-process agents often miss it. eBPF moves system-call monitoring, anomaly detection, and process-behavior control down to the kernel — with no application code changes and no agent in every service.
Observability
Classic instrumentation means editing service code and paying overhead at every probe. eBPF-based tools expose kernel-level visibility into network events, latency, locks, and CPU profiles — at a lower cost for the running service and with no application changes.
Beyond Linux
eBPF was born in Linux, but the idea — extending the kernel without opening it up fully — turned out to be too useful to stay inside one system. Safe kernel programmability has become a reference point for other platforms too.
Key people
Alexei Starovoitov
Creator of eBPF. Worked at PLUMgrid and later at Facebook/Meta.
Brendan Gregg
Performance and profiling specialist, and a major force behind bcc and bpftrace adoption.
Chris Wright
CTO of Red Hat. He proposed the evolutionary integration path through the existing BPF subsystem.
Industry impact
Deep system analysis used to mean a risky kernel extension: hard, slow, expensive, and one mistake took down the whole machine. The core shift with eBPF is that you no longer pay that price per task — much of observability, network diagnostics, and protection can now be built faster, inside eBPF's safety model and verifier boundaries.
References
- eBPF: The Documentary - YouTube documentary
- Isovalent: The Story Behind The eBPF Documentary - creation story
- eBPF.io: What is eBPF? - technical introduction
- Linux Foundation: eBPF Foundation announcement - foundation context
- Cilium - eBPF-based networking, security, and observability
- bcc - BPF Compiler Collection
- bpftrace - high-level tracing language for eBPF
Related chapters
- Site Reliability Engineering - Covers reliability and observability foundations where eBPF gives kernel-level visibility into system behavior.
- Observability & Monitoring Design - Extends eBPF usage as a telemetry source for performance diagnostics and incident response.
- Linux - Provides the kernel, process, networking, and system-call context that eBPF attaches to.
- Kubernetes Fundamentals - Shows how eBPF-based tooling such as Cilium strengthens network policies and platform connectivity in Kubernetes.
- Security Engineering Overview - Connects eBPF to runtime protection, system-call monitoring, and anomaly detection workflows.