A service mesh can be a useful part of a Kubernetes platform when teams need consistent security, traffic management, and visibility between services. Istio, Linkerd, and Cilium all address these needs, but they take noticeably different approaches to how the mesh is built and operated.
The biggest change in recent years is that a service mesh no longer automatically means running a proxy alongside every application pod. Istio Ambient Mode and Cilium's eBPF-based approach both reduce or remove that traditional sidecar overhead, while Linkerd continues to focus on a lightweight proxy-based model.
So how do you decide between them? The answer depends less on a feature checklist and more on your existing Kubernetes setup, operational requirements, performance expectations, and how much complexity your platform team is prepared to manage. This guide breaks down those differences and where each approach makes the most sense.
What a Service Mesh Actually Does
A service mesh handles three things that would otherwise be built into every service by hand: mutual TLS between services so traffic is encrypted without the application managing certificates, traffic management like retries and circuit breaking, and observability into how services actually talk to each other.
For most of the last eight years, delivering this meant a sidecar: a proxy container running alongside every application container in every pod. Istio used Envoy. Linkerd built its own lightweight proxy in Rust. Either way, every pod carried a second process, and every request between two services passed through two extra proxies instead of zero.
The Sidecar Tax
The sidecar model works, and it has run in production at real scale for years. The cost shows up in two places: memory and CPU consumed per pod, and latency added to every hop since traffic now passes through a proxy on the way out and another on the way in.
That cost scales linearly with pod count, which is exactly the problem. A cluster running a few dozen pods barely notices it. A cluster running thousands of pods pays for thousands of extra proxy processes running around the clock, most of them idle most of the time.
Istio Ambient Mode: Removing the Sidecar Without Leaving Istio
Istio's answer to the sidecar tax is Ambient Mode, which reached general availability in Istio 1.24 in November 2024. Ambient replaces the per-pod sidecar with two shared components instead: a per-node agent called ztunnel that handles basic Layer 4 encryption and routing for every pod on that node, and optional waypoint proxies deployed per namespace or per service account for Layer 7 features like traffic splitting or header-based routing..
According to Istio's own published benchmarks, ambient mode uses over 90 percent less memory for L4-only setups (ztunnel without waypoints), dropping to roughly 80 percent savings when waypoints are included for L7 traffic. It is not a new tool. It is the same Istio control plane and the same APIs, with the sidecar swapped out underneath. For a team that already has years invested in Istio configuration, that upgrade path matters more than it sounds like it should.
Cilium: A Mesh Built Into the CNI, Not Bolted On
Cilium approaches the problem from a different direction entirely. It started as an eBPF-based CNI plugin, meaning it was already handling basic pod-to-pod networking at the kernel level before it became a service mesh at all. Extending that into mTLS and traffic management did not require adding a proxy anywhere. eBPF programs run directly inside the Linux kernel, and Cilium uses WireGuard to handle encryption at Layer 4. The Cilium agent, which manages those programs, runs as a DaemonSet per node, but it functions as the CNI itself rather than an additional proxy layer. For L4 mTLS and basic traffic management, no separate proxy process is added to the request path.
Adoption has grown quickly. By late 2025, Cilium reported thousands of production deployments, including at companies like Adobe and Bell Canada. For a team building a new cluster and already planning to use Cilium as the CNI, running the service mesh on the same eBPF foundation avoids operating two separate networking systems side by side.
It is also worth noting that Isovalent, the original creator of Cilium, was acquired by Cisco. While the codebase and CNCF governance remain independent, the commercial backer has changed.
The honest caveat here is that faster is not automatic. Benchmarks published in late 2025 at enterprise scale found Istio Ambient delivering more throughput per core than Cilium in high-pod-count environments.". Kernel-level eBPF has a real theoretical advantage, but real-world performance still depends on workload shape, and the newest architecture is not guaranteed to win every benchmark.
Linkerd: Simpler, But Increasingly Commercial
Linkerd built its reputation on being the lightweight option: a smaller Rust-based proxy, a simpler control plane, and the fastest time to a working mesh for teams that did not need Istio's full feature set.
What changed is the licensing model, not the technology. As of February 2024, the open source Linkerd project stopped publishing free stable release artifacts. Organizations with 50 or more employees now need a paid subscription from Buoyant, the company behind the project, to run production-grade stable releases. Free edge releases still ship roughly weekly and remain fully open source, but without the same reliability guarantees a production cluster usually wants.
This does not make Linkerd a bad technical choice. It changes the calculation for teams that picked it specifically because it was free and open source, since that is no longer the full picture for anyone running it at real scale.
| Mesh | Architecture | Reached this state | Best fit |
|---|---|---|---|
| Istio (sidecar) | Envoy proxy per pod | Original model since 2017 | Teams needing the deepest Layer 7 feature set today |
| Istio Ambient | Shared ztunnel per node, optional waypoints | GA in Istio 1.24, Nov 2024 | Existing Istio users cutting sidecar overhead without a rewrite |
| Cilium Service Mesh | eBPF plus WireGuard, no sidecar or per-node proxy | Thousands of production deployments reported by late 2025 | New clusters already using Cilium as the CNI |
| Linkerd | Rust proxy per pod | Free stable releases ended Feb 2024 | Small teams wanting simplicity, budgeted for the subscription |
So Which One Should You Actually Use?
If a cluster runs fewer than roughly 15 to 20 services talking to each other over plain HTTP, with no real compliance requirement forcing mutual TLS, skip the mesh for now. Kubernetes NetworkPolicy plus TLS at the ingress covers most of what is actually needed, and a mesh adds real operational weight for a problem that does not exist yet.
If Istio is already running and the sidecar overhead has become the actual complaint, Ambient mode is the answer. It keeps the configuration, the control plane, and the team's existing knowledge, and removes the cost that is causing the pain.
If a cluster is being built fresh and Cilium is already the CNI of choice, using Cilium's own service mesh avoids running two networking stacks on top of each other. That combination is becoming the more common default for new Kubernetes platforms going into 2026.
If the priority is genuine simplicity and a small, dedicated team, Linkerd still delivers that, as long as the subscription cost is planned for from the start rather than discovered later.
Where Sidecarless Still Has to Prove Itself
Ambient mode and Cilium's mesh are both newer than the sidecar model they are replacing. Sidecars have run in mission-critical, multi-cluster, high-compliance environments for the better part of a decade. Ambient and Cilium have not had that much runway yet.
For multi-cluster deployments and environments with strict isolation requirements, some platform teams are still choosing sidecars deliberately, not out of habit, because the operational maturity and the isolation guarantees are better understood after years of production use. That gap will close as ambient and eBPF-based meshes accumulate more time in production, but it is not closed today, and any comparison that skips this point is not being fully honest about where things stand.
The Real Question for 2026
The shift worth paying attention to is not which mesh wins a feature comparison. It is that the sidecar itself, the thing that defined service mesh architecture for eight years, is no longer a fixed requirement. Ambient mode proved Istio could remove it without becoming a different product. Cilium proved a mesh could be built into the networking layer from the start instead of added on top of it.
Before picking a mesh, the better first question is whether one is needed at all. After that, the real choice is not a brand name. It is whether the workload can benefit from a newer sidecarless architecture today, or whether it genuinely needs the years of production hardening that only comes from the model that has already been tested at scale.
