Emissary + Linkerd Resilience Patterns: Rate Limits, Retries & Timeouts
summary
Demo builds a tiny three‑service app behind Emissary (edge) and Linkerd (service mesh), with services intentionally failing 20% of requests and occasional >1s latencies; applying a single retry at the edge and Linkerd retries governed by a retry budget 20% removes many errors, adding timeouts prevents hanging clients, and a custom rate‑limit service using a leaky‑bucket 8 RPS (blowup ≈ 8.5 RPS) cuts exploding failures. Observability is essential to tune these knobs.
AI-written summary · about
chapters (11)
- 0:00Resilience and reliability intro
- 4:12Emissary Ingress overview
- 7:22Linkerd service mesh
- 8:47Demo architecture and initial state
- 11:58Retries with Emissary
- 13:47Retries with Linkerd
- 15:34Timeouts for reliability
- 17:42Rate limiting with Emissary & Linkerd
- 21:12Final adjustments
- 23:59Conclusion
- 28:12Q&A
related talks
01h 10mService Mesh Introduction
16mWhat Happens when Service Mesh Maintainers Get a Taste of Their Own Mesh?
34mService Mess to Service Mesh
19mSeeing the Invisible Observability with
35mIntro: Linkerd
35mDeep Dive: Linkerd
30mLinkerd Update: Gateway API, Client-Specific Policy, Federated Services, Multicluster, Rust, & More!
39mService Mesh: There and Back Again