Service Mesh — cheat sheet
A one-page lookup for the concepts and tools used across this course. Grouped by task; the course pages
cover the why behind each one — this page is just the what.
Core model
| Task |
Reach for |
| Handling network traffic per-pod without touching app code |
a sidecar proxy injected into the pod |
| Configuring routing/security/telemetry fleet-wide |
the control plane (e.g. Istio's istiod) |
| The actual traffic-handling layer across the cluster |
the data plane — every sidecar, collectively |
Security and traffic
| Task |
Reach for |
| Encrypting + authenticating service-to-service traffic |
mTLS, issued/rotated by the control plane |
| Canary release, A/B, or header-based routing |
mesh traffic-management rules (e.g. VirtualService) |
| Surviving a transient failure or a hung call |
mesh-level retries / timeouts / circuit breaking |
| Avoiding a retry storm |
pick ONE layer (app or mesh) to own retries for a given call path |
Choosing a mesh
| Task |
Reach for |
| Need the broadest feature set / already Envoy-invested |
Istio (Envoy data plane + istiod) |
| Want the core benefits with minimal operational overhead |
Linkerd (own lightweight micro-proxy) |
| Just need "a proxy," not a full mesh |
Envoy alone — remember it isn't a mesh without a control plane |
Observability and cost
| Task |
Guidance |
| Getting uniform per-call metrics/traces for every service |
per-call observability is a mesh's telemetry benefit — feeds the module 17 stack |
| Deciding whether to adopt a mesh |
weigh it against latency (extra hop), resource overhead (sidecar per pod), and control-plane complexity |
| Good fit |
many services, real cross-service traffic-management or security needs |
| Poor fit |
a handful of simple, stable services with no such need |
How this connects
What a service mesh is (page 1) establishes the sidecar/control-plane/data-plane split; mTLS, traffic
management, and resilience (page 2) covers the three behaviors the mesh gives every service for free;
Istio, Linkerd, and Envoy (page 3) covers the two dominant meshes and the proxy underneath them;
observability and when a mesh is worth it (page 4) covers the telemetry payoff and the real cost that has to
justify adopting one.