Service mesh = control plane + data plane sidecars (with proxies)
- control plane: orchestration; determines how packets should be forwarded.
- data plane: communication between services.
Service mesh: a dedicated infrastructure layer:
- for handling service-to-service communication
- factors out common and global cross-cutting of concerns:
- Traffic Management
So service mesh includes functionalities of service discovery, load balancing, A/B testing, etc.
Developers can then focus on building the actual business logic.
- On Kubernetes, the proxy is deployed by a sidecar pattern to the microservices in the mesh.
- On Virtual Machines (VMs), the proxy is installed on the VM.
- Reliability features: Request retries, timeouts, canaries (traffic splitting/shifting), etc.
- Observability features: Aggregation of success rates, latencies, and request volumes for each service, or individual routes; drawing of service topology maps; etc.
- Security features: Mutual TLS, access control, etc.
- Istio: uses envoy as proxy.
- CNCF Incubating
- OpenUsage: https://openusage.org/
- CNCF Graduated
- HCP Consul: uses envoy as proxy.
Both Envoy and Linkerd are graduated CNCF projects.
Anthos Service Mesh is powered by Istio.
- Envoy is a flexible and general-purpose proxy. C++.
- Linkerd2-proxy is a “micro-proxy” designed specifically for the service mesh sidecar use case. Written in Rust.
"Unlike Envoy, Linkerd2-proxy is designed for only one use case: proxying requests to and from a single Kubernetes pod while receiving configuration from the Linkerd control plane. And unlike Envoy, Linkerd2-proxy is designed to be an implementation detail: it’s not user-facing, it’s not usable as a generic building block, and it has a boring name. There’s no user-facing YAML; instead, Linkerd2-proxy is configured automatically through a handful of environment variables set at injection time and by the Linkerd control plane at runtime."