eBPF (extended Berkeley Packet Filter) started as a kernel debugging tool and has become the foundational technology for a new generation of Kubernetes networking, observability, and security tools. Here's the actual explanation of what it does and why it's replacing older approaches.
What eBPF Does
eBPF lets you run sandboxed programs inside the Linux kernel without modifying kernel source code or loading kernel modules. The kernel verifies eBPF programs before execution — they can't crash the kernel, can't loop infinitely, and can only access memory they're permitted to access.
For networking, eBPF programs attach to hooks in the kernel's network stack:
Packet arrives → NIC → XDP hook (eBPF) → TC ingress hook (eBPF) → iptables → socket
Packet leaves → socket → iptables → TC egress hook (eBPF) → NIC
A CNI using eBPF can intercept packets at the TC (traffic control) layer, before iptables, and make forwarding decisions in microseconds. It can also bypass iptables entirely for known flows using socket-level load balancing.
Why Kubernetes Outgrew iptables
Traditional CNIs (Flannel, older Calico, kube-proxy) use iptables for pod-to-pod routing and kube-proxy for service load balancing. The iptables ruleset grows linearly with the number of services. At 10,000 services, iptables rule evaluation on every packet becomes a meaningful CPU overhead — and rule updates require locking and rewriting the entire chain.
A benchmark from a 500-node cluster with 5,000 services:
- kube-proxy (iptables): ~8ms p99 service lookup latency, ~12% kernel CPU
- Cilium (eBPF): ~0.8ms p99 service lookup latency, ~2% kernel CPU
The gap widens as cluster size grows.
Cilium: The Production-Ready Choice
Cilium is the most mature eBPF-based CNI, now a CNCF graduated project. Its key features:
eBPF-native kube-proxy replacement: Cilium can completely replace kube-proxy. Services are implemented as eBPF maps — O(1) lookup regardless of service count.
Identity-based security: Instead of IP-based network policies, Cilium uses security identities derived from pod labels. Policies survive pod restarts without IP rule updates.
Hubble: The built-in observability layer exposes per-flow metrics, DNS visibility, and HTTP-level monitoring using eBPF. No sidecar required.
# Real-time flow visibility with Hubble
hubble observe --namespace production --protocol http --verdict DROPPEDMigrating From Flannel or Calico
Migrating a running cluster's CNI is high-risk — there's no in-place migration path. The options:
- Blue/green cluster migration: Provision a new cluster with Cilium, migrate workloads.
- Drain and reprovision nodes: For managed node groups, replace nodes with new CNI config. Works if your workloads tolerate a node rolling replacement.
- New clusters only: Keep existing clusters on current CNI until next major version, use Cilium for all new clusters.
Option 3 is the most common production approach. Flannel clusters that are stable and not hitting scale limits don't need an emergency migration — plan it as part of the next major Kubernetes version upgrade.
The Observability Bonus
Even if you don't migrate your CNI, consider deploying Tetragon (Cilium's eBPF security observability agent) alongside your existing CNI. Tetragon traces system calls and network activity at the kernel level without sidecars — it's the most efficient way to get process-level visibility across all pods.