1 min lesson
Istio vs. Linkerd vs. Cilium
Use two rows in "Istio vs. Linkerd vs. Cilium" to state the practical decision rules.
Step 1 of 2
Istio vs. Linkerd vs. Ciliumand the sidecar tax
The classic mesh injects a sidecar proxy next to every pod, which intercepts all traffic. That's where the features come from and also where the cost comes from: a proxy per pod means extra CPU, memory and a couple of hops of latency on every request. The newer move is sidecarless - push mTLS and policy into the kernel with eBPF, so there's no per-pod proxy on the hot path.
- Mesh
- Istio
- Model
- Sidecar (Envoy) or ambient/eBPF mode
- Trade
- Most features and traffic control; heaviest to run and tune
- Mesh
- Linkerd
- Model
- Sidecar (lightweight Rust micro-proxy)
- Trade
- Simple, low overhead, opinionated; fewer advanced knobs
- Mesh
- Cilium
- Model
- eBPF, largely sidecarless
- Trade
- Lowest per-request overhead via kernel; ties mesh to CNI/eBPF
| Mesh | Model | Trade |
|---|---|---|
| Istio | Sidecar (Envoy) or ambient/eBPF mode | Most features and traffic control; heaviest to run and tune |
| Linkerd | Sidecar (lightweight Rust micro-proxy) | Simple, low overhead, opinionated; fewer advanced knobs |
| Cilium | eBPF, largely sidecarless | Lowest per-request overhead via kernel; ties mesh to CNI/eBPF |
Sidecar = features and per-pod cost. eBPF/sidecarless = less latency and overhead, more kernel coupling.
Every sidecar hop adds tail latency and Cursor is latency-obsessed because completions and agent steps are interactive. A few milliseconds per in-cluster hop, multiplied across a request fan-out and concentrated in p99, is exactly the cost the eBPF/sidecarless approach exists to remove. Quantify it before you adopt a sidecar mesh.