eBPF in Kubernetes 2026: From Kernel Feature to Standard Infrastructure

eBPF has evolved in recent years from an exotic kernel feature into a central infrastructure technology for cloud-native environments. According to the CNCF Annual Cloud Native Survey 2026, 67 percent of Kubernetes teams already use at least one eBPF-based tool in production. At the same time, Cilium – the most well-known eBPF-based Container Network Interface (CNI) – has become the standard network plugin for the three major managed Kubernetes services GKE, EKS, and AKS. But what lies behind this development, and why should DevOps teams adopt eBPF now?

What eBPF actually is

eBPF (Extended Berkeley Packet Filter) is a virtual machine in the Linux kernel that allows sandboxed programs to run directly in the kernel – without having to write kernel modules or modify the kernel source code. The special feature: a kernel verifier checks every eBPF program for safety and correctness before execution. Only programs that are guaranteed not to crash or run in infinite loops are translated into native machine code via a JIT compiler and executed.

Communication between eBPF programs in the kernel and userspace tools occurs via so-called BPF maps – shared memory structures that both sides can read and write simultaneously. This architectural pattern enables observability and control of the kernel with nearly zero overhead.

Cilium: The most successful eBPF use case

The most well-known eBPF project is Cilium, which serves as a CNI for Kubernetes and is now shipped as a standard option or even as the default in GKE, EKS, and AKS. Cilium replaces kube-proxy with eBPF-based packet processing, achieving up to 100 times higher performance than iptables with thousands of services – because BPF maps use hash tables (O(1)), while iptables uses linear rule traversal.

But Cilium can do far more than pure packet forwarding:

Hubble is Cilium's integrated network observability layer. It shows in real time which traffic flows between which pods – without requiring applications to be instrumented. A single hubble observe --namespace production is enough to see connections, latencies, and dropped packets (policy violations).

CiliumNetworkPolicy extends standard Kubernetes NetworkPolicies with Layer 7 rules. Instead of only IP/port-based access control, HTTP methods, paths, and even headers can be specified in YAML:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-http-policy
spec:
  endpointSelector:
    matchLabels:
      app: backend-api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: GET
          path: "/api/.*"

Sidecar-less service mesh with Cilium 1.19

At KubeCon EU 2026 in Amsterdam, the Cilium team presented version 1.19 with native mTLS support – without sidecar containers. The architecture is revolutionary: instead of injecting an Envoy proxy (~50–100 MB RAM) per pod, an eBPF program runs per node, handling routing, mTLS, and observability for all pods on that node. For Layer 7 features, a single Envoy per node is used – not one per pod.

The savings are enormous: with 1,000 pods, 100 MB of sidecar overhead per pod totals 100 GB of RAM reserved exclusively for proxy infrastructure – without contributing to application functionality. Cilium's eBPF-native mTLS eliminates this overhead completely.

Zero-instrumentation observability with OpenTelemetry eBPF

Another milestone at KubeCon EU 2026 was the beta release of OpenTelemetry eBPF Instrumentation (OBI) by Splunk. OBI captures telemetry data directly from the Linux kernel – without code changes, without service restarts, without sidecar agents. This is especially valuable for legacy applications, Go binaries, Rust services, or C++ codebases where source code modifications are time-consuming or impossible.

OBI integrates with existing OpenTelemetry SDKs and fills observability gaps without duplicating data from already instrumented services. During the evaluation phase, teams typically uncover 15 to 40 percent of cluster traffic that was previously invisible to distributed tracing.

Runtime security with Tetragon

Tetragon – also from the Cilium ecosystem – goes a step further: it can not only detect security policies but also enforce them directly in the kernel. A TracingPolicy can, for example, detect the execution of /bin/bash or /bin/sh in pods without CAP_SYS_ADMIN and terminate the process via Sigkill – in real time, at the kernel level.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: detect-privilege-escalation
spec:
  kprobes:
  - call: "security_bprm_check"
    args:
    - index: 0
      type: "linux_binprm"
    selectors:
    - matchBinaries:
      - operator: "In"
        values:
        - "/usr/bin/sudo"
        - "/bin/su"
      matchActions:
      - action: Sigkill
      - action: Post
        rateLimit: "1m"

The eBPF stack in 2026

For a production cluster in 2026, the recommended eBPF stack looks like this:

Layer	Tool
CNI + Service Mesh	Cilium
Network Observability	Hubble
App Observability (automatic)	Pixie or Grafana Beyla
Runtime Security	Tetragon
Custom Traces	OpenTelemetry (via OBI)

Conclusion

eBPF has made the journey from a niche kernel topic to an essential infrastructure technology. Anyone running Kubernetes today cannot avoid eBPF. The advantages are clear: lower latency than iptables, no sidecar overheads, observability without code changes, and security enforcement at the kernel level.

KubeCon EU 2026 has shown that the technology has reached the enterprise tipping point. Cilium is available as a CNI at all major cloud providers, OpenTelemetry eBPF Instrumentation is in beta, and companies like Splunk offer commercial support. For DevOps teams, this means: now is the time to evaluate the eBPF stack and integrate it into your own Kubernetes strategy.