Understanding Service Mesh

Once user traffic has arrived at your Kubernetes cluster, there are two directions in which communication needs to be managed: into and out of the cluster (north/south) via an API gateway, and between microservices within the cluster (east/west), managed by a service mesh.

Download the Fundamentals of Service Mesh ebook

What is service mesh?

A service mesh is an infrastructure layer that makes it possible for microservices, or pods, to communicate with, and sometimes across, each other.

The service mesh architecture enables pods within a cluster to coordinate in order to optimize user experience. For example, if the personalized recommendations feature in a video sharing app fails, the service mesh makes it possible for a list of generic recommendations to pop up for the user to click on, without affecting other functionality.

Watch the 2 Minute Explainer Video

In this video from our Getting Edgy explainer series, Richard Li explains API gateway vs service mesh

Why Do You Need a Service Mesh?

In Kubernetes, service mesh architecture can be customized and configured to handle a wide range of devops needs

Data planes & control planes

The data plane consists of one or more service proxies within a cluster, each of which typically runs next to a single service or microservice of an app, and is responsible for service discovery, resilience, observability, and security for the microservices. The control plane is responsible for defining policy and ensuring the data plane follows that policy.

Resilience

Resilience can be added to the distributed system in more than one way. For example, having each microservice’s code include calls to code libraries with resilience functions, or having special network proxies handle microservice requests and replies. The ultimate goal of resilience is to ensure that failures or degradations of particular microservice instances don’t cause cascading failures that cause downtime for the entire distributed system.

Observability & Security

Observability is being able to monitor an app’s state and to determine at a high level what’s happened when something goes wrong with the app. Service meshes can provide security by protecting the communications between pods by using Transport Layer Security (TLS), a cryptographic protocol. TLS uses cryptography to ensure that the information being communicated can’t be monitored or altered by others.


Read our Fundamentals of Service Mesh ebook here

Service Mesh Products

Envoy Proxy service mesh is a popular choice for use as a data plane. Originally developed by Lyft, Envoy Proxy is now a Cloud-Native Computing Foundation project, with hundreds of contributors from many companies such as AirBnb, Amazon, Microsoft, Google, Pinterest, and Salesforce.

Istio

Istio is an open source project from Google, IBM, and Lyft

Consul

Consul is an open source software project stewarded by HashiCorp

Linkerd

Linkerd is a non-Envoy-based service mesh that uses its own proxy, linked2-proxy. The Cloud Native Computing Foundation (CNCF) project hosts linkerd.

What Else Should You Know About Service Mesh?

There's more to explore, from basic fundamentals to traffic API examples.

Cloud-native apps

- Common cloud-native app architectures
- Cloud-native app benefits
- Fallacies of distributed computing
- Common challenges

Learn more

Resilience for distributed systems

- Resilience strategies
- Load balancing
- Timeouts and automatic retries
- Deadlines and circuit breakers

Learn more

Introduction to service mesh interface (SMI)

- Traffic specs API
- Traffic split API
- Traffic access control API
- Traffic metrics API

Learn more

Using service mesh to debug and mitigate app failures

- Service mesh status checks
- Service proxy status checks
- Service route metrics
- Service route configuration for issue mitigation

Learn more

Learn more about Service Mesh

Page 1 out of 2