What is service mesh (Istio/Linkerd)?

A service mesh provides a dedicated infrastructure layer for service-to-service communication, handling: mutual TLS, load balancing, circuit breaking, observability, and traffic management — without application code changes. Architecture: data plane — sidecar proxy (Envoy for Istio, linkerd2-proxy for Linkerd) injected into each pod, intercepts all traffic; control plane — manages sidecar configuration, certificate rotation, observability data. Istio features: mTLS between all services (automatic certificate management); Traffic management — traffic splitting (canary), retries, timeouts, circuit breaking, fault injection; Observability — distributed traces (Jaeger), metrics (Prometheus), access logs; Security — fine-grained authorization policies (allow ServiceA to call ServiceB on /api only); Ingress/egress gateways. Istio traffic management: apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: my-service spec: hosts: [my-service] http: - match: [{headers: {x-canary: {exact: "true"}}}] route: [{destination: {host: my-service, subset: v2}}] - route: - destination: {host: my-service, subset: v1} weight: 90 - destination: {host: my-service, subset: v2} weight: 10. Linkerd: lighter weight, Rust-based proxy (lower latency), simpler to operate, strong security defaults. Less features than Istio. eBPF-based alternatives: Cilium Service Mesh — no sidecar overhead, network-level observability. Linkerd Ambient mode (sidecar-less, similar to Cilium). When to use service mesh: when you need mTLS between services, sophisticated traffic management, or need service-level observability at scale. Avoid for simple setups — adds operational complexity.