For thirty years, changing what the Linux kernel does to a packet meant either kernel modules — powerful, dangerous, unmaintainable — or userspace detours that paid for safety with performance. eBPF dissolved that trade-off: small verified programs, loaded at runtime, running sandboxed inside the kernel at native speed. What began as a faster packet filter has become the dataplane of major clouds and the foundation of a new observability stack. In 2026 this is no longer early adoption — Cilium is a graduated CNCF project, Meta serves production traffic through its open-sourced XDP balancer Katran, and every mainstream distribution ships the kernel support you need.
The hype, though, obscures the engineering question that matters: what does eBPF actually replace in your stack, what does it not, and what does operating it cost?
Three hook families, three superpowers
- ▸XDP (eXpress Data Path): programs run in the network driver before the kernel even allocates socket buffers. This is where you drop DDoS floods and build load balancers handling millions of packets per second per core — work that previously required kernel bypass with DPDK and a dedicated team.
- ▸tc hooks: programs at traffic control ingress and egress see full packet context and can rewrite, redirect, and enforce policy. This is where Cilium implements Kubernetes networking, replacing long chains of iptables rules with lookups in hash maps.
- ▸Tracing hooks (kprobes, tracepoints, uprobes): attach to nearly any kernel or userspace function and stream events through ring buffers. This is the substrate of bpftrace and the continuous profilers that watch every syscall, TCP retransmit, or TLS handshake without touching application code.
Retiring the iptables era
The concrete production win is replacing rule-chain networking. A large Kubernetes cluster running kube-proxy in iptables mode evaluates rules linearly per connection, and every service change rewrites entire chains — churn that hurts precisely when you scale. Cilium's kube-proxy replacement turns service resolution into constant-time map lookups, and identity-based policy replaces IP-based rules that were always a poor fit for ephemeral pods. Socket-level programs can even short-circuit connections between pods on the same node, skipping most of the network stack. None of this requires your team to write a line of BPF — you consume it through a CNI — but understanding the mechanism matters the day you debug it.
Observability without sidecars
The second win is watching systems without instrumenting them. Sidecar proxies buy visibility with a per-pod tax of memory, latency, and upgrade coordination. eBPF-based tooling — Hubble for flow visibility, continuous profilers in the Parca mold, kernel-level HTTP and gRPC tracing — observes from beneath the application: every process is covered the moment it starts, in any language, with overhead in the low single digits. It also sees what applications cannot misreport: actual syscalls, actual retransmits, actual file access. That is why runtime security tools like Falco and Tetragon build on the same hooks, mapping kernel events to MITRE ATT&CK techniques as they happen.
The costs nobody puts on the slide
- ▸Kernel version coupling: features arrive by kernel release, and fleets on older enterprise kernels will hit missing hooks. CO-RE with BTF solved the worst portability pain, but only from roughly the 5.x era onward — inventory before you promise.
- ▸The verifier is a strict compiler with opinions: programs must provably terminate and stay within complexity bounds. Legitimate programs get rejected for reasons that take experience to read; writing custom BPF is a specialist skill.
- ▸Debugging is different: when packets vanish, tcpdump may not see them, because an XDP program dropped them before the capture point. Runbooks need bpftool and the drop-reason counters your tooling exposes.
- ▸Security surface: BPF is powerful enough that unprivileged use is disabled by default on modern distributions. Loading programs is a privileged operation to gate and audit like any other root capability.
An adoption roadmap
1. Start with read-only tracing: run bpftrace one-liners and an eBPF profiler in staging to build familiarity with zero dataplane risk. 2. Baseline your kernels: inventory versions and BTF availability across the fleet before committing to anything. 3. Adopt through projects, not custom code: Cilium, Hubble, Tetragon, or your vendor's agent — let them own the verifier fights and kernel matrices. 4. Migrate one cluster to a kube-proxy replacement, benchmark service latency and policy update time against the old path, and rehearse rollback. 5. Write custom BPF only when a measured need survives contact with existing tools — then treat it as kernel engineering, with the review bar that implies.
The business case compounds quietly. Retiring sidecars and rule chains reclaims real CPU and memory across the fleet; kernel-level visibility shortens incidents because the data already exists when the page fires; and DDoS mitigation at XDP speeds turns attacks that once demanded upstream scrubbing into local non-events. eBPF rewards teams that adopt it the boring way — through graduated projects, with rollback plans — and it is steadily becoming the assumed substrate of cloud-native infrastructure. Building fluency now is cheap; retrofitting it during an incident is not.