eBPF: The Kernel Superpower You’re Already Using

If you’ve used Cilium, Falco, Pixie, or the latest versions of kubectl-trace, you’ve used eBPF. It powers some of the most impressive infrastructure tooling of the last five years — and it’s only getting more central to how modern systems work.

eBPF (extended Berkeley Packet Filter) lets you run sandboxed programs inside the Linux kernel without modifying kernel source code or loading kernel modules. The security model is rigorous — every eBPF program is verified before execution — and the performance overhead is often sub-1%.

Photo by Alexandre Debiève on Unsplash

Why eBPF Matters for Platform Teams

Traditional observability tools — APM agents, sidecar proxies, kernel modules — all have problems:

• APM agents require language-specific instrumentation and miss system-level context
• Sidecar proxies (Envoy, etc.) add latency and resource overhead
• Kernel modules are dangerous, require recompilation, and can crash the host

eBPF sidesteps all of this. You get kernel-level visibility with:

• Zero application changes
• No sidecars
• Verified safety (can’t crash the kernel)
• Minimal overhead

The Four Domains of eBPF

1. Observability

eBPF programs can hook into any kernel function and collect metrics, traces, and logs with no application instrumentation.

# Trace all new processes on the system
bpftrace -e 'tracepoint:syscalls:sys_enter_execve { 
    printf("%s called execve\n", comm); 
}'

# Profile CPU usage by function
bpftrace -e 'profile:hz:99 { @[kstack] = count(); }'

Tools like Pixie use this to give you instant Kubernetes observability — CPU profiles, network flows, HTTP requests — without touching your application code.

2. Networking

Cilium is the canonical example. By implementing the Kubernetes CNI with eBPF instead of iptables, Cilium achieves:

• 2-10x throughput improvement over traditional kube-proxy
• L7 policy enforcement at wire speed
• Transparent encryption with WireGuard, zero app changes
• Network topology maps with automatic service discovery

The iptables replacement alone is worth it at scale. iptables is O(n) for rule lookups. eBPF maps are O(1).

# Cilium NetworkPolicy with L7 HTTP rules
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-l7-policy
spec:
  endpointSelector:
    matchLabels:
      app: api-server
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
      rules:
        http:
        - method: "GET"
          path: "/api/v1/.*"

3. Security

Falco and Tetragon use eBPF to enforce and detect security policies at the kernel level:

• Process execution monitoring
• File access auditing
• Network connection filtering
• Privilege escalation detection

Crucially, eBPF-based security can’t be evaded from userspace. Even if an attacker breaks out of a container, the eBPF program watching execve calls will catch them.

# Tetragon TracingPolicy: detect shell execution in containers
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "detect-shell-execution"
spec:
  kprobes:
  - call: "sys_execve"
    syscall: true
    args:
    - index: 0
      type: "string"
    selectors:
    - matchArgs:
      - index: 0
        operator: "Postfix"
        values:
        - "/sh"
        - "/bash"
        - "/zsh"
    return: false

4. Performance Tuning

eBPF programs can modify kernel behavior without patching — adjusting TCP congestion algorithms per-connection, bypassing the kernel network stack for latency-critical paths (XDP), or implementing custom CPU schedulers.

Facebook (Meta) built sched_ext using eBPF to implement a custom CPU scheduler that improved their workload performance by ~6% at their scale.

Getting Started: The eBPF Tool Ecosystem

Writing Your First Real eBPF Program

Here’s a simple program that tracks the latency of open() syscalls using libbpf in Go:

//go:generate go run github.com/cilium/ebpf/cmd/bpf2go -cc clang bpf opensnoop.c

package main

import (
    "fmt"
    "log"
    "github.com/cilium/ebpf/link"
    "github.com/cilium/ebpf/ringbuf"
)

func main() {
    objs := bpfObjects{}
    if err := loadBpfObjects(&objs, nil); err != nil {
        log.Fatal("Loading objects:", err)
    }
    defer objs.Close()

    // Attach to sys_enter_openat tracepoint
    tp, err := link.Tracepoint("syscalls", "sys_enter_openat", 
        objs.TraceEnterOpenat, nil)
    if err != nil {
        log.Fatal("Attaching tracepoint:", err)
    }
    defer tp.Close()

    rd, err := ringbuf.NewReader(objs.Events)
    if err != nil {
        log.Fatal("Creating ringbuf reader:", err)
    }
    defer rd.Close()

    fmt.Println("Waiting for events...")
    for {
        record, err := rd.Read()
        if err != nil {
            log.Fatal("Reading:", err)
        }
        fmt.Printf("Open event: %s\n", record.RawSample)
    }
}

The Future: eBPF Beyond Linux

Windows eBPF (ebpf-for-windows) is production-ready for networking and observability use cases. This means tools like Cilium can eventually run on mixed Linux/Windows Kubernetes clusters.

eBPF + AI is an emerging pattern: using eBPF to collect ultra-granular telemetry that feeds into anomaly detection models, enabling intelligent autoscaling and predictive incident detection.

Should You Learn eBPF?

Absolutely, especially if you work on:

• Kubernetes platform engineering
• Performance engineering
• Security tooling
• Network infrastructure

You don’t need to write raw eBPF programs. But understanding what Cilium, Falco, and Pixie are doing under the hood makes you dramatically better at operating and troubleshooting them.

The kernel is no longer a black box. eBPF unlocked it — and the tools built on top are just getting started.

Resources: ebpf.io, cilium.io, bpftrace.org

이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :)