For the better part of a decade, Kubernetes observability has been a story about sidecars. Inject a proxy next to every pod, route traffic through it, collect metrics, traces, and logs from the wire. It worked — sort of. It also doubled your memory footprint, multiplied your failure modes, and forced platform teams into the unenviable role of explaining to product engineers why their pod now ran with two containers instead of one. In 2026, that compromise is finally ending. The reason is a Linux kernel technology with a famously unfortunate name: eBPF.
Extended Berkeley Packet Filter — eBPF — is the same technology quietly powering Cilium’s networking layer at Google, Microsoft, AWS, and thousands of enterprises running Kubernetes at scale. Through 2024 and 2025, eBPF crossed the threshold from clever infrastructure trick to production default. By mid-2026, the question for platform teams is no longer “should we look at eBPF?” It’s “which parts of our observability stack still belong in userspace?”
At Devinity, we have spent the past eighteen months migrating client clusters off sidecar-heavy meshes and traditional APM agents onto eBPF-native stacks. The performance gains are real, the operational simplification is dramatic, and the migration is significantly less painful than most teams expect. This post breaks down what eBPF observability actually is, why the sidecar model lost, what the 2026 production stack looks like, and how to adopt it without setting your platform on fire.
The Sidecar Problem Nobody Wants to Talk About
The sidecar pattern, popularized by Istio and Linkerd around 2018, solved a genuine problem. If every service needed mTLS, retry logic, observability, and traffic shaping, the cleanest separation of concerns was to pull those responsibilities out of application code and into a proxy that lived alongside each pod. The application stayed simple. The proxy handled policy. Operators got a uniform control plane. The model was elegant on paper.
In production, the elegance frayed quickly. Every pod now carried an Envoy proxy with its own memory baseline — typically 150 to 300 megabytes of RAM and a non-trivial slice of CPU. On a cluster running 500 pods, that translated to over 75 gigabytes of memory just for sidecars, before any actual workload. Latency picked up an extra hop on every request. Pod startup time slowed. Crash loops got harder to debug because the question “which container failed?” suddenly had two valid answers. And every upgrade to the mesh control plane required rolling restarts of essentially every pod in the fleet.
The instrumentation story was equally messy. Traditional APM tools installed language-specific agents inside the application container, which meant a dozen different SDKs, version mismatches between languages, and relentless maintenance overhead. Want distributed tracing for Go? Add the OpenTelemetry SDK. Python? A different SDK. Node? Yet another. The mesh captured L4 traffic but couldn’t see L7 application semantics. Agents could see application semantics but couldn’t see between services. Teams ended up running both, doubling the complexity tax.
The dirty secret of sidecar-based observability is that the infrastructure layer designed to make services simpler ended up costing more memory than the services themselves.
By late 2024, the cost-benefit math no longer added up. Engineering leaders started asking why every observable signal required a userspace proxy when the kernel already saw every system call, every packet, and every socket. The answer, increasingly, was that it didn’t need to.
What eBPF Actually Does (Without the Jargon)
eBPF lets you run sandboxed programs inside the Linux kernel without recompiling the kernel or loading kernel modules. Think of it as a safe, verified runtime that lives in the kernel itself, hooked into the events you care about: a packet arriving on a network interface, a system call being made, a process being created, a TCP connection opening or closing.
When you attach an eBPF program to one of these hook points, it executes in-kernel at near-native speed. The kernel verifier statically checks the program before loading to guarantee it cannot crash the kernel or run unbounded. From an observability standpoint, this is transformative. A single eBPF program on each Kubernetes node can capture every TCP connection, every HTTP request, every gRPC call, every database query, and every DNS lookup — for every pod on that node — without touching the application or the pod definition.
The implications stack quickly. Because eBPF runs in the kernel, it sees traffic before encryption is applied on the way out and after decryption on the way in — meaning it can observe L7 protocols natively without terminating TLS. Because it’s programmable, it can decode HTTP/2, gRPC, PostgreSQL wire protocol, MySQL, Kafka, and Redis without per- application configuration. Because it runs once per node instead of once per pod, the overhead is paid a handful of times across a cluster rather than thousands.
Concrete numbers from production deployments tell the story. Across the clusters we have migrated, eBPF-based observability runs at under 1 percent CPU overhead per node and consumes roughly 24 megabytes of memory per node for the data path. For that same 500-pod cluster, the eBPF stack uses about 12 gigabytes of memory in total — an order of magnitude less than sidecars. Network latency overhead drops to nanoseconds because the data path is in-kernel rather than bouncing through userspace proxies.
The 2026 Production Stack
A mature eBPF observability and security stack today is a small handful of well-integrated projects rather than a single monolithic platform. Each component owns a slice of the visibility surface, and they compose cleanly. Here is the stack we recommend for new Kubernetes platforms in 2026.
- Cilium as the CNI and L4/L7 network policy engine. Cilium has become the default Kubernetes CNI in GKE, EKS, and AKS, and its mature 1.16 release line is what most production-grade deployments are running. It handles networking, identity-based policy, and load-balancing in eBPF with no kube-proxy required.
- Hubble for network and service observability. Hubble sits on top of Cilium and exposes a flow log, service map, and metrics for every pod-to-pod interaction. It answers “who is talking to whom, on which port, with which protocol, and is it succeeding?” without any pod configuration changes.
- Pixie for auto-instrumented application performance monitoring. Pixie deploys as a DaemonSet, captures full request bodies for the last 60 seconds in an in-memory rolling buffer per node, and aggregates statistics for longer-term retention. It produces flame graphs, latency histograms, and full SQL-like query interfaces over live cluster data with zero application changes.
- Tetragon for runtime security observability. Tetragon uses eBPF to enforce policy on syscalls, file access, and process execution, giving you a high-fidelity audit log of what every workload actually did at the kernel level. It is the modern answer to the question “was our cluster compromised, and what did the attacker touch?”
- Grafana Beyla as the bridge to OpenTelemetry. Beyla auto-instruments Go, Python, Java, Node.js, .NET, and Rust services using eBPF and emits OTLP traces, metrics, and logs to whatever backend you already use — Grafana Cloud, Tempo, Jaeger, Datadog, Honeycomb, or self-hosted Prometheus.
What unifies these projects is that none of them require application code changes, none require sidecars, and all of them ship data through kernel-level capture. That is the production pattern winning in 2026.
Service Mesh in the eBPF Era
The service mesh category is in the middle of a quiet but consequential consolidation. Cilium’s native service mesh capabilities — mTLS via SPIFFE identities, L7 routing, retries, timeouts, traffic mirroring — now cover roughly 80 percent of what most teams used Istio for, with substantially lower overhead. The Cilium mesh runs sidecarless by default, leveraging the per-node eBPF data plane that already exists for networking. Istio’s ambient mode, introduced as beta in 2023 and matured through 2024 and 2025, is also sidecarless, using its own per-node ztunnel and optional waypoint proxies.
For new platforms, our recommendation is straightforward. Default to Cilium as your CNI. Enable Hubble for observability on day one. If your mesh requirements are mTLS, identity-based policy, and L7 traffic management, use Cilium’s native mesh and skip Istio entirely. If you need Istio’s richer traffic management primitives — elaborate routing rules, complex retry budgets, advanced fault injection — adopt Istio ambient mode rather than the legacy sidecar architecture. Either way, the sidecar mesh is no longer the default choice in 2026.
Migration Reality Check
Migrations from sidecar-heavy observability to eBPF-native stacks are real engineering projects, but they are significantly less invasive than most teams fear. The most important thing to understand is that eBPF adoption does not require a flag day. You can run Cilium alongside your existing CNI in many configurations, run Pixie next to an existing APM agent for months, and graduate workloads off the sidecar mesh namespace-by-namespace rather than all at once.
The dependencies that matter are kernel version and cluster topology. Most eBPF features land on Linux 5.10 or newer, and the richer L7 decoding in Pixie and Cilium benefits from 5.15 or later. Managed Kubernetes services have all been on supported kernels for years. If you are running self-managed nodes on something older, plan a node image upgrade as a prerequisite. Beyond that, eBPF requires elevated privileges for the agent DaemonSets — usuallyCAP_BPF, CAP_PERFMON, and a handful of others — which most teams gate behind a dedicated namespace and a strict PodSecurity policy.
The migration sequence we run with clients usually looks like this. Start by deploying Hubble in observability-only mode against the existing CNI to start collecting flow data. Run it for two to four weeks to build confidence and catch any traffic patterns the existing mesh masked. Then deploy Pixie alongside the existing APM in a few non-critical services. Compare the data, confirm the eBPF stack is not missing anything material, and start expanding coverage. Only after both Hubble and Pixie have been observed in production for a month or two do you start migrating the actual network data plane and removing sidecars from the mesh.
Where eBPF Still Falls Short
eBPF is not a silver bullet, and any 2026 evaluation that treats it otherwise is selling something. There are real limitations to keep in mind. The verifier enforces strict bounds on program complexity and execution time, which means certain kinds of analysis simply cannot happen in the data path and must be offloaded to userspace. TLS interception, while possible through uprobes on common SSL libraries, depends on knowing the binary layout of OpenSSL or BoringSSL — statically-linked Go binaries that use crypto/tls were a long-standing blind spot, mostly closed by 2025 but still occasionally surprising on stripped binaries.
Multi-cluster observability remains a stitching exercise rather than a built-in feature. Hubble has a federation layer, and Pixie supports multi-cluster aggregation, but unifying flow logs and traces across a dozen clusters still requires meaningful glue work. The same is true of cross-account or cross-region correlation, where the data plane is cluster-local but the analysis you actually want is fleet-wide.
On the security side, eBPF visibility into encrypted east-west traffic in environments using application-layer encryption rather than mTLS at the transport layer is still imperfect. If your applications encrypt their own payloads end-to-end before the mesh sees them, no kernel hook will decode that for you without keys you presumably do not want to give a kernel-level program.
The Operational Win That Matters
Behind the performance numbers and architectural elegance, the reason we keep recommending the eBPF stack to clients is operational. The number of moving parts a platform team needs to babysit drops sharply. There are no per-application instrumentation libraries to keep current. No sidecar control plane to upgrade in lockstep with the data plane. No version skew between Envoy minor releases and Istio control plane patches that produced subtle, hard-to-debug failures at scale.
For the platform engineers who have spent years explaining to developers why their pods kept getting restarted because the mesh rolled out a security patch, that simplification alone is worth the migration. eBPF makes the platform invisible in the way good infrastructure is supposed to be invisible: working, performant, and out of the way.
Where AI Fits In
The natural follow-on question in 2026 is what role AI plays in this stack. The honest answer is that AI is most useful at the analysis layer, not the capture layer. eBPF gives you firehose-volume telemetry with extreme fidelity. AI-powered observability platforms then correlate, prioritize, and root-cause across that telemetry — predicting anomalies, surfacing the three signals out of ten thousand that actually matter for the current incident, and increasingly proposing remediation. The combination of high-fidelity, low-overhead kernel observability with AI-driven analysis is what people mean when they say AIOps in 2026, and it is finally credible rather than vendor marketing.
Recommendation for Engineering Leaders
If you are starting a new Kubernetes platform in 2026, the decision is easy: deploy Cilium as the CNI, enable Hubble, install Pixie, and skip sidecar-based meshes entirely. The reference architecture is well- documented, the production deployments are numerous, and the ergonomics are dramatically better than anything that existed three years ago.
If you are running an established platform with substantial sidecar investment, the answer is to begin a deliberate, multi-quarter migration. Start with observability, prove value, and graduate to the network data plane only after the team is fluent in the new tooling. Treat the migration the way you would treat any non-trivial infrastructure transition — with shadow deployments, careful comparisons, and a realistic timeline. The reward is a platform that costs less to run, is easier to debug, and frees your engineers from instrumentation drudgery.
At Devinity, our cloud and DevOps team has helped clients across fintech, healthcare, and SaaS migrate from sidecar-heavy stacks to eBPF-native observability. If you are evaluating the transition or already in the middle of one, we are happy to share what worked, what broke, and what we wish we had known earlier. The sidecar era is ending. The kernel was always the right layer for this. It just took a decade for the tooling to catch up.