Service Mesh

A service mesh moves cross-cutting network concerns — mTLS, retries, timeouts, traffic splitting, request-level observability — out of application code and into a shared sidecar proxy layer. That's a genuine architectural win once you have enough services that reimplementing retry logic in five languages is more expensive than running a mesh. It is also real infrastructure with its own control plane, its own failure modes, and a latency cost on every single request.

The mesh is worth it when the alternative is duplicating the same networking logic across many services; it's not worth it just because it's available. Adopt a mesh to solve a problem you already have, not one you're anticipating.

1. Justify the mesh against what NetworkPolicy and Ingress already give you

Plain Kubernetes already provides L3/L4 segmentation (NetworkPolicy) and L7 HTTP routing at the edge (Ingress). A mesh's value is specifically service-to-service L7: per-request retries, mTLS between every pod pair without app changes, and fine-grained traffic splitting for internal calls — if the actual need is "block namespace A from reaching namespace B," that's kubernetes-networking, not a mesh-sized solution.