eBPF-based meshes remove the per-pod proxy and the latency that came with it. They also move failure into the kernel. An honest trade-off analysis.
The sidecar model was always a compromise: inject a proxy next to every workload, accept the memory overhead and the extra network hop, and get mTLS and observability in return. At a few dozen pods that is invisible. At a few thousand it is a line item.
Sidecarless meshes move L4 concerns into the kernel via eBPF and handle L7 at a smaller number of shared waypoints. The resource saving is real, and so is the reduction in pod startup time — no more waiting for a proxy to become ready before your application can talk to anything.
The costs nobody puts in the pitch deck
- Your kernel version becomes a hard dependency, which constrains node image upgrades
- Debugging moves from 'exec into the sidecar' to kernel-level tracing tools your team may not know
- The blast radius of a mesh misconfiguration widens: a node-level component affects every pod on that node
- Mixed-mode operation during migration is genuinely complex, and most teams underestimate how long they will sit in it
Our position
If you are running a large, homogeneous estate with a platform team that can operate kernel-level tooling, sidecarless is the right direction. If you have fifteen services and one engineer on call, sidecars are boring and boring is a feature. Choose based on your operating model, not the benchmark.