eBPF for Kubernetes Observability and Security in 2026

Key takeaway: eBPF lets you run safe programs inside the Linux kernel with 1–5% overhead. For Kubernetes, Cilium replaces iptables with eBPF for faster, scalable networking. Tetragon provides production-safe syscall and process monitoring that survives container escapes.

What Is eBPF?

eBPF (extended Berkeley Packet Filter) is a technology built into the Linux kernel that lets you run sandboxed programs in kernel space without modifying kernel source code or loading kernel modules. Originally designed for packet filtering, it has evolved into a general-purpose kernel programmability layer.

eBPF programs are loaded by userspace applications, verified by the kernel's verifier for safety (no infinite loops, valid memory access only, bounded complexity), then JIT-compiled to native machine code and attached to kernel hooks — system calls, network events, function calls, tracepoints, and more.

The key property: eBPF programs observe or modify kernel behavior at the point it happens, without the overhead of switching between kernel and userspace for every event. This makes kernel-level monitoring production-safe in a way that tools like strace are not.

Why eBPF for Kubernetes?

Kubernetes networking has historically relied on iptables for service load balancing and network policies. iptables was designed for firewall rules, not high-throughput service meshes — it performs a linear scan through rules, and at scale (hundreds of services, thousands of pods), rule tables grow to tens of thousands of entries with O(n) lookup time.

eBPF solves this with hash table lookups and XDP (eXpress Data Path) — processing packets before they reach the kernel networking stack, achieving O(1) lookups at line rate. Cilium, the most widely deployed eBPF CNI, can process millions of packets per second with CPU usage that does not grow with the number of services.

Beyond networking, eBPF enables a layer of visibility that was previously impossible without invasive application instrumentation: seeing every syscall, every file open, every process exec, and every network connection from every container — identified by their Kubernetes workload identity, not just by IP address.

Cilium: eBPF Networking

Cilium is the leading eBPF-based CNI for Kubernetes. It replaces kube-proxy and iptables entirely, using eBPF programs to handle:

• Service load balancing (ClusterIP, NodePort, LoadBalancer)
• Network policy enforcement based on Kubernetes labels (not IP addresses)
• Transparent encryption between nodes (WireGuard-backed)
• L7-aware network policies (HTTP, gRPC, Kafka)
• Hubble — a network observability layer built on Cilium's eBPF programs

# Install Cilium with Helm
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set kubeProxyReplacement=strict \
  --set k8sServiceHost=YOUR_API_SERVER_IP \
  --set k8sServicePort=6443

# Check Cilium status
cilium status

# View network policy enforcement
cilium monitor --type drop

# Hubble — live network flow visibility
cilium hubble port-forward &
hubble observe --follow

Hubble provides a real-time view of network flows between pods — which services are talking to which, which connections are being dropped by policy, and latency between workloads. This is the observability layer that service meshes like Istio provide, but implemented at the kernel level without per-pod sidecar overhead.

Tetragon: eBPF Security

Tetragon is a Cilium sub-project that provides security observability and runtime enforcement using eBPF. It hooks into the kernel at the syscall and LSM (Linux Security Module) level to observe and optionally block:

• Process execution (execve calls — who ran what command, with what arguments)
• File access (open, read, write on sensitive paths)
• Network connections (who connected to what IP/port)
• Privilege escalation attempts (setuid, capability changes)

# Install Tetragon
helm repo add cilium https://helm.cilium.io/
helm install tetragon cilium/tetragon \
  --namespace kube-system

# Watch process execution events across the cluster
kubectl exec -n kube-system ds/tetragon -c tetragon -- \
  tetra getevents -o compact --pods your-pod-name

# Watch for sensitive file access
kubectl exec -n kube-system ds/tetragon -c tetragon -- \
  tetra getevents -o compact | grep /etc/passwd

Sample Tetragon event (a container executing a shell):

{
  "process_exec": {
    "process": {
      "exec_id": "...",
      "pid": 1234,
      "binary": "/bin/sh",
      "arguments": "-c whoami",
      "pod": {
        "name": "nginx-deployment-abc123",
        "namespace": "production",
        "labels": {"app": "nginx"}
      }
    }
  }
}

The key security property: Tetragon runs in the kernel and cannot be evaded by a compromised container. Even after a container escape, the eBPF programs observe what the attacker does on the host. This is fundamentally different from userspace monitoring agents that stop working as soon as an attacker terminates their process.

Observability with bpftrace

For ad-hoc kernel-level investigation, bpftrace provides a high-level scripting language for eBPF programs:

# Install bpftrace
sudo apt install bpftrace

# Count syscalls per process (1-second interval)
sudo bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); } interval:s:1 { print(@); clear(@); }'

# Trace all file opens on the system
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("%s %s\n", comm, str(args->filename)); }'

# Monitor DNS queries from a specific process
sudo bpftrace -e 'tracepoint:net:net_dev_xmit /comm == "nginx"/ { printf("%d bytes\n", args->len); }'

# Disk I/O latency histogram
sudo bpftrace -e 'tracepoint:block:block_rq_issue { @start[args->dev, args->sector] = nsecs; }
tracepoint:block:block_rq_complete /@start[args->dev, args->sector]/
{ @usecs = hist((nsecs - @start[args->dev, args->sector]) / 1000); delete(@start[args->dev, args->sector]); }'

Identity-Based Network Policies

Traditional Kubernetes NetworkPolicy uses IP addresses and CIDR blocks. Cilium's CiliumNetworkPolicy extends this with label-based, workload-identity-aware policies that survive pod restarts (IP addresses change; labels do not):

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: payment-service-policy
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: payment-service

  # Only accept inbound traffic from the checkout service
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: checkout-service
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "POST"
                path: "/v1/process"

  # Only allow outbound to the database
  egress:
    - toEndpoints:
        - matchLabels:
            app: postgres
      toPorts:
        - ports:
            - port: "5432"
              protocol: TCP

This policy enforces at L7 — not just "checkout can talk to payment," but specifically "only HTTP POST to /v1/process." Violations are logged with full context (source pod, destination pod, rejected method/path).

Kernel Requirements

Most eBPF tools require Linux kernel 5.10 or newer for full feature support. Quick check:

uname -r
# Should show 5.10+ for full Cilium/Tetragon support

# Ubuntu 20.04 HWE kernel (5.15) — recommended
sudo apt install linux-generic-hwe-20.04

# Ubuntu 22.04 LTS — kernel 5.15, ideal baseline
# Ubuntu 24.04 LTS — kernel 6.8, all features supported

# Check eBPF capabilities
bpftool feature probe kernel

Getting Started

The practical entry point for most Kubernetes operators is Cilium as the CNI, with Hubble for network observability. The operational overhead is lower than a full service mesh, and the networking performance improvement is immediate. Tetragon for runtime security is the next layer — add it once Cilium is stable.

# Quick start: Cilium on an existing cluster
# 1. Check Cilium compatibility
cilium install --dry-run

# 2. Install (replace kube-proxy)
cilium install

# 3. Enable Hubble observability
cilium hubble enable

# 4. Verify
cilium status --wait
hubble observe --follow

Final Thoughts

eBPF is the most significant Linux kernel development in a decade, and its impact on infrastructure observability and security is still growing. For Kubernetes operators, Cilium and Tetragon provide capabilities that were previously only possible with invasive sidecar proxies or expensive commercial security tools — now implemented at the kernel level with near-zero overhead. If you are running Kubernetes in production without eBPF-based tooling, you are missing a visibility layer that increasingly defines the standard for modern cluster operations.