Traffic Management Using a Service Mesh
Service Meshes and the Service Mesh Interface (SMI)
There are many guides and introductions to service meshes, such as the Service Mesh Manifesto.
Most guides to the service mesh concept start by describing a control plane and a data plane. Ignore both of these terms. Instead, focus on the proxy, which is typically auto-injected as a sidecar in your application pods.
CD-as-a-Service does not configure proxy sidecar injection.
This proxy intercepts all inbound and outbound network traffic and understands application-level protocols (think HTTP and gRPC). Because it understands application protocols, the proxy can implement application features: HTTP metrics, path-and-header-based routing, access control, or retries. The service mesh, as a whole — the previously ignored data and control plane — is a system to implement, configure, and observe these features. The magic of a mesh is that it’s possible to get consistent HTTP metrics (or retries, access control, etc.) across a set of heterogenous microservices without the wrangling or even buy-in of the service owners.
The Service Mesh Interface (SMI) is an abstraction of the features common among service mesh implementations; the abstraction takes the form of Kubernetes Custom Resource Definitions (CRDs).
SMI solves a common integration problem: n consumers want to integrate with m producers, each having its own interface, creating a miserable m ⋅ n integration matrix. Because of SMI, tools that want to integrate with service mesh providers — Linkerd, Istio, Consul — don’t need to integrate with each mesh individually. Instead, they can just integrate with SMI. Popular service meshes understand SMI natively or via adapters.
Supported service mesh products
What’s next
Feedback
Was this page helpful?
Thank you for letting us know!
Sorry to hear that. Please tell us how we can improve.
Last modified August 5, 2022: (f8573d7c)