Three. That is how many major cloud providers now ship eBPF-based networking as the default for new Kubernetes clusters, and the transition happened with almost no coverage.
eBPF, short for extended Berkeley Packet Filter, lets an operator run sandboxed programs inside the Linux kernel without modifying kernel source code or loading a kernel module Source. The kernel verifies the program before execution. A just-in-time compiler translates it to native instructions. The whole thing runs in a ring-buffer sandbox that cannot crash the kernel, cannot deadlock, and cannot allocate unbounded memory. It functions as a safe execution environment for code that needs kernel-level visibility, and the implications for infrastructure outrun the attention the technology has gotten.
Start with networking. Cilium, the eBPF-based container networking interface, has replaced kube-proxy in every major Kubernetes distribution. AWS EKS Anywhere ships Cilium as the default networking add-on Source. Google GKE Dataplane V2, built on eBPF and Cilium, is the default CNI for new Autopilot clusters and the recommended choice for Standard Source. Azure CNI Powered by Cilium is the default virtual network for AKS Automatic clusters Source. Kubernetes networking, one of the messiest subsystems in cloud infrastructure, is being quietly standardized on a single eBPF-based implementation.
Then there is security. Falco, the Cloud Native Computing Foundation's runtime security project, uses eBPF to monitor system calls in production without loading a kernel module Source. Instead of inserting a kernel module that can crash the machine, the traditional approach for system call interception, Falco loads an eBPF program that the kernel verifier checks before execution. The same approach powers Tetragon, the Cilium team's runtime security agent. In 2024, Cisco acquired Isovalent, the company behind Cilium and Tetragon, specifically for the eBPF intellectual property and the team that built it Source. Cisco does not acquire networking startups for fun. It acquires technology that becomes infrastructure.
The structural shift underneath these deals is an API change. Kernel modules require compiling against kernel headers, can crash the whole machine, and demand root access. eBPF programs are verified at load time, run in a sandbox, and require only specific capabilities rather than full root. The kernel is becoming programmable without becoming fragile. Vendors describing features as eBPF-powered are pointing at that distinction: they can ship kernel-level functionality without the operational risk that kernel modules create.
The governance formalized this year, too. The eBPF Foundation, hosted by the Linux Foundation, added Meta and Toyota as members alongside founding members Google, Microsoft, Netflix, and Isovalent Source. Toyota's membership signals that eBPF has crossed from a cloud-native networking curiosity to a technology bound for production embedded systems. Automotive systems run Linux and need deterministic, sandboxed kernel observability. The same technology that routes Kubernetes service traffic is being evaluated for the software-defined vehicle.
The CrowdStrike incident made the argument for eBPF's security model without anyone saying the word eBPF in the postmortems. The outage was caused by a kernel driver that performed an out-of-bounds memory read, crashing 8.5 million Windows machines globally Source. The XZ backdoor, discovered in March 2024, inserted malicious code into a widely deployed compression library through a sophisticated supply-chain attack Source. Both incidents trace to the same root cause: kernel-level code that was not verifiably safe before deployment. eBPF programs are verified before they execute. The verifier proves termination, bounds-checks every memory access, and rejects any program that could dereference a null pointer. An eBPF program that would cause a CrowdStrike-style crash is rejected at load time, not discovered at 4 a.m. in production.
The observability piece is one most engineers have already encountered without naming it. Debugging a Kubernetes cluster with Pixie, visualizing service mesh traffic with Hubble, or buying a vendor's zero-instrumentation observability pitch all run on eBPF underneath. The kernel runs a program that attaches to tracepoints and ships telemetry to userspace. The application code does not change. The sidecar does not exist. The agent is the kernel itself, monitored by a program the kernel verifier approved.
eBPF is becoming the kernel module API's replacement, and the old approach is becoming legacy by default. The Linux kernel maintainers have made clear that new functionality should target eBPF where possible rather than adding new kernel module interfaces. Cilium's replacement of kube-proxy, itself once a userspace proxy for Kubernetes service discovery, is the blueprint. The old way was a userspace daemon watching API server events and programming iptables rules. The new way is an eBPF program attached to the networking stack that handles service translation inline. Latency drops from milliseconds to microseconds.
Security, observability, and networking vendors still shipping kernel modules will lose the ability to run their agent on cloud-managed Kubernetes as the default CNI goes eBPF-only and security policies block kernel module loading by default. The window for kernel module-based products is closing. Three cloud providers have already made the call for everyone building on top of them.