Service Mesh

A service mesh adds a transparent infrastructure layer to microservices for mTLS encryption, traffic management, observability, and policy enforcement — without modifying application code. Istio (CNCF, backed by Google/Red Hat/IBM) uses Envoy sidecars injected into every Pod; Linkerd uses a lighter-weight Rust-based microproxy for lower overhead. The control plane (istiod) pushes xDS configuration to all data-plane proxies dynamically.

Key Points

• Istio mTLS encrypts all service-to-service traffic within the mesh using short-lived certificates (~24 hours) issued by the Istio CA — enabling zero-trust inside the cluster.
• VirtualService and DestinationRule CRDs in Istio enable traffic splitting (e.g., 90% to v1, 10% to v2 for canary), request retries, timeouts, and circuit breaking — declaratively via YAML.
• Envoy sidecar overhead: ~20–50 MB memory per pod, ~1–2 ms added latency per hop — significant at scale; use ambient mesh (Istio 1.18+) or Linkerd for lower overhead.
• Istio's AuthorizationPolicy CRD enforces L7 access control (e.g., only ServiceAccount `payment-svc` can call `POST /payments`) — replacing network-level security groups.
• Linkerd data plane is written in Rust (linkerd2-proxy), adding ~10 MB per pod and <1 ms latency overhead — preferred for CPU/memory-constrained environments.
• Kiali (Istio observability UI) generates real-time service dependency graphs, error rate heat maps, and traffic flow visualisations from Envoy telemetry.
• Ambient mesh (Istio 1.18+, ztunnel + waypoint proxy) eliminates per-pod sidecars — reduces memory overhead by 90% but sacrifices per-pod L7 policy granularity without a waypoint.
• Service mesh federation (Istio east-west gateway) allows services across two separate clusters (or clouds) to communicate over mTLS using the mesh's certificate authority.