The Service Mesh Wars: A New Hope for Kubernetes
summary
Benchmarks run on 12–15 microservice demos under a 30‑minute 50‑user steady load and a two‑hour ramp (50 users added every 30 minutes) measure added latency, CPU and memory, and policy overhead for Kuma, Linkerd, Cilium, Istio and Ambient. Results show Cilium adds effectively 0 ms (it’s a CNI, not a mesh), Linkerd adds ~2.55 ms and its control plane uses ~700 MB, Ambient ~3.7 ms, Kuma ~5.6 ms, Istio ~6.4 ms; rate‑limit/timeout policies increase cost and Kuma shows CPU spikes. Test code and repos are available.
AI-written summary · about
chapters (8)
- 0:00Introduction and welcome
- 2:08Far far galaxy of service meshes
- 6:26Expected features in service mesh
- 10:46Service mesh design experiences
- 20:03Observability in service meshes
- 23:59Performance benchmarks results
- 33:31Final recommendations and conclusion
- 36:22Q&A session
related talks
39mService Mesh: There and Back Again
26mAn Introduction to Service Mesh in Action
01h 03mJust what is a "service mesh", and if I get one will it make everything OK?
52mService Mess to Service Mesh
20mThe Crazy Service Mesh Ecosystem
34mService Mess to Service Mesh
08mLightning Talk: A Practical Guide on How to Monitor and Compare Service Mesh...
58mUsing Service Meshes and Kubernetes to Solve Service-to-Service Communications...