Matheus

Posted on Feb 21 • Originally published at releaserun.com

What is eBPF? A Practical Guide for Kubernetes and DevOps Engineers

#kubernetes #devops #linux #security

eBPF (extended Berkeley Packet Filter) lets you run sandboxed programs inside the Linux kernel without changing kernel source code or loading traditional kernel modules. Originally designed for packet filtering, eBPF has evolved into a general-purpose in-kernel virtual machine used for observability, networking, and security across production infrastructure.

For Kubernetes and DevOps engineers, eBPF matters because it powers a growing number of critical tools: Cilium (the CNI plugin used by major cloud providers), Falco and Tetragon (runtime security), and Pixie (auto-instrumented observability).

How eBPF Works Under the Hood

Traditionally, adding functionality to the Linux kernel meant either modifying the kernel source (slow, impractical for production) or writing a kernel module (runs with full privileges, a bug can crash the system).

eBPF provides a third option: write a small program that the kernel verifies for safety before running it. Sandboxed, can't crash the kernel, near-native performance via JIT compilation.

The eBPF Pipeline

Write the program in a restricted subset of C, compiled to eBPF bytecode using LLVM/Clang. Higher-level tools like bpftrace let you use a simpler scripting language.
Load and verify - the eBPF verifier statically analyzes it: ensures termination (no infinite loops), no out-of-bounds memory access, no unprivileged operations.
JIT compile to native machine instructions (x86_64, ARM64) for maximum performance.
Attach to a hook point where it will execute.
Communicate via maps - key-value data structures accessible from both kernel and user space.

Hook Points: Where eBPF Programs Run

kprobes / kretprobes - Attach to any kernel function. Not part of the stable ABI, may change between versions.
tracepoints - Stable instrumentation points. Preferred for production use.
XDP (eXpress Data Path) - Earliest point in the network receive path. Millions of packets per second. Used for DDoS mitigation and load balancing.
TC (Traffic Control) - Ingress and egress network traffic. Used by Cilium for K8s network policy.
uprobes - Trace user-space functions in any compiled binary (Go, C, Rust) without modifying the application.
LSM (Linux Security Module) - Security-relevant decision points. Used by Tetragon.

eBPF vs Traditional Kernel Modules

Safety: eBPF programs are verified before execution and cannot crash the kernel. Kernel modules can cause a kernel panic.
Portability: CO-RE (Compile Once, Run Everywhere) means programs compiled for one kernel version can run on others.
No reboot: Load and unload dynamically at runtime.
Performance: JIT-compiled to native code, minimal overhead.
Iteration speed: Write, load, test, and unload in seconds.

Practical eBPF: bpftrace Examples

bpftrace is a high-level tracing language for eBPF. Here are practical examples you can run on any Linux system:

Trace File Opens

# Trace all openat() syscalls and print the filename
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("%s %s\n", comm, str(args.filename)); }'

Count Syscalls by Process

# Count syscalls per process over 5 seconds
bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); } interval:s:5 { exit(); }'

Histogram of Read Sizes

# Distribution of read() sizes
bpftrace -e 'tracepoint:syscalls:sys_enter_read { @bytes = hist(args.count); }'

Trace TCP Connections

# Trace new TCP connections
bpftrace -e 'kprobe:tcp_connect { printf("%s -> %s\n", comm, ntop(((struct sock*)arg0)->__sk_common.skc_daddr)); }'

eBPF in Kubernetes: The Tools That Matter

Cilium (Networking + Service Mesh)

Cilium replaces iptables-based Kubernetes networking with eBPF programs attached to TC hooks. Benefits:

No iptables rules. Network policy is enforced by eBPF programs directly, avoiding the O(n) scaling problem of iptables chains.
Service mesh without sidecars. Cilium can provide mTLS, L7 policy, and observability through kernel-level eBPF programs instead of Envoy sidecars.
Hubble for network flow visibility across the entire cluster.

Tetragon (Runtime Security)

Tetragon uses eBPF to enforce security policies at the kernel level. It can:

Monitor and block specific syscalls per workload
Detect file access patterns that indicate compromise
Track process execution trees with full parent-child relationships
Enforce network policies at L3/L4/L7 independently of Cilium

Falco (Threat Detection)

Falco uses eBPF to tap into kernel syscalls and detect anomalous behavior. The rule engine lets you define policies like "alert if any container runs a shell" or "alert if a process opens /etc/shadow."

Pixie (Auto-instrumented Observability)

Pixie uses eBPF uprobes and kprobes to automatically capture:

Full HTTP/gRPC request and response bodies
Database queries (MySQL, PostgreSQL, Cassandra, Redis)
DNS requests and responses
CPU and memory profiling data

No code changes or sidecar containers required.

The State of eBPF in 2026

BPF Arena and user-space memory mapping for complex data sharing
kfuncs expanding eBPF's access to kernel functionality
BPF tokens and delegation for container runtimes to grant specific eBPF capabilities
eBPF for Windows from Microsoft, bringing the model cross-platform
The eBPF Foundation (Linux Foundation) ensuring vendor neutrality

Getting Started with eBPF on Kubernetes

Start with Cilium as your CNI. GKE, EKS, and AKS all support it.
Add Hubble for network flow visibility.
Deploy Tetragon or Falco for security.
Explore bpftrace for ad-hoc debugging (run as a privileged pod).
Check kernel compatibility. Most features need Linux 4.15+, with significant improvements in 5.x and 6.x.

eBPF has fundamentally changed how observability, networking, and security work in Linux and Kubernetes. Understanding it, even at a conceptual level, is becoming essential for anyone operating K8s infrastructure.

DEV Community