Service Mesh

Last Updated: 2024-01-27

TL;DR:

Service mesh = control plane + data plane sidecars (with proxies)

• control plane: orchestration; determines how packets should be forwarded.
• data plane: communication between services.

A longer version of explanation

Service mesh: a dedicated infrastructure layer:

• for handling service-to-service communication
• factors out common and global cross-cutting of concerns:
  • Traffic Management
  • Security
  • Observability
  • Extensibility

So service mesh includes functionalities of service discovery, load balancing, A/B testing, etc.

Developers can then focus on building the actual business logic.

Traffic types

• east-west: connectivity within a project.
• north-south: to the external world.

Proxies

• 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.

Features

• 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.

Service Mesh Frameworks

• Istio: uses envoy as proxy.
  • istio.io
  • CNCF Incubating
  • OpenUsage: https://openusage.org/
• Linkerd
  • CNCF Graduated
• HCP Consul: uses envoy as proxy.

Both Envoy and Linkerd are graduated CNCF projects.

Anthos Service Mesh is powered by Istio.

Linkerd2-proxy vs Envoy

• 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.
  • https://github.com/linkerd/linkerd2-proxy

"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."