Service meshes give you traffic management at the network layer without app code: retries, timeouts, circuit breakers, mTLS, traffic shifting. The three production-mature meshes — Istio, Linkerd, Cilium — make different trade-offs between feature richness and operational simplicity.
Istio — the feature-rich one
Envoy sidecar per pod. Massive feature set: traffic management, security policy, telemetry, multi-cluster. Operational cost matches the feature set. Right for large orgs willing to staff dedicated mesh ops.
Linkerd — the simple one
Rust-based proxy (small, fast). Sane defaults. Limited features compared to Istio (deliberate). Right for: smaller teams wanting mesh benefits without the operational tax.
Cilium service mesh — sidecar-less
Uses eBPF for L7 features without sidecars. Lower per-pod overhead. Newer (mature ~2024). Right for: clusters already using Cilium for networking, willing to pioneer.
Without a mesh
App-layer libraries (resilience4j, polly, ribbon). Per-language. Don't get mTLS at L7 — handle it explicitly. Right for: small services, polyglot mismatches, or teams that can't afford the mesh tax. Many large companies run this way.
Choosing
Already on K8s with non-trivial scale (50+ services): mesh. Pick Linkerd unless you need an Istio-specific feature. Cilium if you're betting on eBPF. Below 20 services: skip the mesh; app-layer libraries suffice.