10.1. Service Mesh Architecture
A mesh splits into two planes: a data plane of proxies that sit in the request path and actually move traffic, and a control plane that configures them. Understanding this split explains both the mesh’s power (change routing or security policy without redeploying a service) and its cost (every request now traverses an extra proxy). This chapter covers the Envoy data plane, the Istio and Linkerd control planes, the traffic-management and observability features they enable, and the sidecarless models that are rewriting the cost equation.
Topics Covered
Section titled “Topics Covered”- 10.1.1. Why Service Mesh Exists: L4 vs. L7 Problems: Motivates the mesh by the L4-versus-L7 problems that libraries in every language cannot solve uniformly.
- 10.1.2. Envoy Proxy: The Backbone of the Data Plane: Covers Envoy, the high-performance proxy that forms the data plane of most service meshes.
- 10.1.3. Istio: istiod and the Consolidated Control Plane: Explains Istio’s consolidated istiod control plane and how it configures the Envoy data plane.
- 10.1.4. Linkerd: A Lightweight Alternative with a Rust-Based Proxy: Covers Linkerd, a lightweight mesh built on a purpose-built Rust micro-proxy.
- 10.1.5. Traffic Management: Load Balancing, Retry, and Fault Injection: Explains mesh-level load balancing, retries, and fault injection configured without touching application code.
- 10.1.6. Observability at the Mesh Level: Automatic Telemetry: Covers the automatic golden-signal telemetry a mesh emits for every service without instrumentation.
- 10.1.7. Sidecarless Mesh: Istio Ambient Mode and Cilium Service Mesh: Explains sidecarless meshes — Istio Ambient’s ztunnel and waypoint split, and Cilium’s eBPF approach.