DevOps & Kubernetes (50 Qs)•Part 3: Production K8s Scaling, Reliability & SRE (26 - 35)
Service Mesh Architecture: When to adopt Istio vs. Linkerd, sidecar injection vs. Ambient Mesh, and mTLS.
Architecture & Trade-Offs
A Service Mesh is a dedicated infrastructure layer that provides traffic management, security (mutual TLS), and observability across microservices without modifying application code.
less
1. Sidecar Pattern (Traditional):
+------------------------------------+ +------------------------------------+
| Pod A | | Pod B |
| [ App Code ] <-> [ Envoy Sidecar ] | == | [ Envoy Sidecar ] <-> [ App Code ] |
+------------------------------------+ +------------------------------------+
Overhead: High memory consumption (1 Envoy per Pod); complex init-container routing.
2. Ambient Mesh (Sidecar-less):
[ Pod A ] --------------------------- mTLS ---------------------------> [ Pod B ]
| |
[ ztunnel (Node-level L4 proxy) ] [ ztunnel (Node-level L4 proxy) ]
Istio vs. Linkerd
| Feature | Istio | Linkerd |
|---|---|---|
| Proxy Technology | Envoy (C++) | Micro-proxy written in Rust (memory safe, ultra-low footprint). |
| Architecture | Feature-rich, highly configurable, heavier resource usage. | Lightweight, minimalistic, opinionated, "just works" ethos. |
| Sidecarless Option | Istio Ambient Mesh (ztunnel L4 + waypoint L7). | In development / evaluation. |
Core Service Mesh Capabilities
- Automatic Mutual TLS (mTLS): Enforces end-to-end cryptographic encryption and cryptographic identity (SPIFFE) between Pods with zero code changes.
- Traffic Shifting & Fault Injection: Route 5% traffic to a new canary version; inject 200ms latency or 5% HTTP 500 errors to test resilience.
- Distributed Tracing: Automatically injects and propagates W3C trace headers (
traceparent,tracestate) to track cross-service latency.