eBPF: seeing inside Linux without touching your code

If you follow cloud-native tooling, you've seen "eBPF" everywhere. Cilium uses it for networking. Falco and Tetragon use it for security. Pixie, Grafana Beyla and others use it for observability. Cloud providers use it under the hood of their Kubernetes networking.

But what actually is it, and why does it matter for DevOps engineers who'll never write kernel code?

eBPF, simply

The Linux kernel sees everything: every network packet, every file opened, every process started, every system call. Traditionally, if you wanted to hook into that, you had two bad options: change the kernel itself (slow, risky, takes years to reach users) or write a kernel module (powerful, but one bug can crash the whole machine).

eBPF (originally "extended Berkeley Packet Filter", now just a name) is a third option. It lets you run small, sandboxed programs inside the kernel, safely, without changing kernel code or loading modules.

Before an eBPF program runs, the kernel's verifier checks it: it must terminate, it can't access memory it shouldn't, it can't crash the system. Then it's compiled to native code and runs extremely fast.

These programs attach to hooks: network events, system calls, function entries and exits in the kernel or even in applications. When the event happens, the program runs, collects data or makes a decision, and shares results with normal programs in user space.

eBPF turns the Linux kernel into a programmable platform, safely, without rebooting and without changing a line of your application.

Why it matters for DevOps

You probably won't write eBPF programs yourself. But you'll use tools built on it, and understanding what they do helps you choose and debug them.

The big advantages:

• No code changes. Observe applications in any language without adding libraries or agents to them.
• Low overhead. Runs in the kernel, very efficiently.
• Complete visibility. Sees everything happening on the node, including things applications don't log.
• Can enforce, not just observe. Drop packets, block system calls, kill processes.

The tools built on it

Networking: - Cilium: a Kubernetes CNI that uses eBPF instead of iptables for routing, load balancing and network policies. Faster and more scalable with many services, and adds features like identity-aware policies and transparent encryption. It's a CNCF graduated project and the default networking for several managed Kubernetes offerings. - Hubble: Cilium's observability layer, showing which services talk to which, with flow logs and a service map.

Security: - Falco: detects suspicious behaviour, like a shell opened inside a container or unexpected file access. - Tetragon: from the Cilium project, observes and can enforce security policies at the kernel level, for example killing a process that tries to read a sensitive file.

Observability: - Grafana Beyla: auto-instruments HTTP and gRPC services with eBPF and produces OpenTelemetry metrics and traces, without touching the application. (Its core has been contributed to the OpenTelemetry project as the eBPF instrumentation effort.) - Pixie: instant visibility into Kubernetes clusters, including request-level data, without instrumentation. - Parca and Pyroscope: continuous profiling using eBPF, showing which functions use CPU across all processes. - bpftrace and BCC tools: for hands-on Linux performance analysis.

Zero-instrumentation tracing

One of the most exciting uses: getting request metrics and basic traces from applications nobody wants to touch. Legacy services, third-party binaries, apps in languages without good OpenTelemetry support.

An eBPF-based tool watches network calls and certain functions, recognises HTTP and gRPC requests, and creates RED metrics (rate, errors, duration) and spans automatically. It's not as detailed as proper in-code instrumentation, but it gives you a solid baseline for everything, from day one.

Trying it yourself

The easiest way to feel eBPF's power on a Linux machine is bpftrace:

# Show every new process being started, system-wide
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_execve { printf("%s -> %s\n", comm, str(args->filename)); }'

Run it and open a terminal: you'll see every command as it starts. That's the kernel talking to you directly.

Limitations

• Kernel version matters. Modern features need reasonably recent kernels (5.x and newer, ideally 5.10+ or 6.x). Old enterprise Linux versions can be a problem.
• Privileges. eBPF tools usually need elevated permissions on the node. Trust the tools you install.
• Linux only, mostly. Windows has an eBPF implementation in progress, but the ecosystem is Linux-first.
• Encrypted traffic is harder to inspect, though tools can hook into TLS libraries in some cases.
• Debugging eBPF itself can be tricky when things go wrong.

So, should you care?

Yes, even if you never write a line of eBPF. It's quietly becoming the foundation of Kubernetes networking, runtime security and modern observability. Knowing what it is helps you understand why Cilium is faster, how Falco sees inside containers, and how tools can trace your apps without touching them.

My take: eBPF is the most important Linux technology most people never see. Learn what it does, and a lot of modern tooling suddenly makes sense.

— Desly