Discovering the Service Mesh

Your application is based on several microservices. These microservices communicate with each other inside the cluster. You want to secure the communication between the microservices. You have heard that a service mesh comes in handy for this task.

Cloud-native applications are typically split into several distributed microservices, which can communicate with each other. A service mesh is an infrastructure layer that handles communication between services and is decoupled from the application layer. Given the independence of the application layer, applications do not need to implement standard functionalities such as service discovery or security. With a service mesh, these tasks can be shifted out of the services and into the service mesh layer. So, networking is decoupled from the application logic. This is also important since different teams can write microservices in different languages. Relying on each team to implement standard functionality like service discovery or security is not feasible.

As your solution grows, the number of microservices increases. This leads to a higher complexity in the communication between the services. Requirements like security, load balancing, and service discovery are increasingly important. A service mesh can help you to solve these problems. It can secure the communication between the microservices and provide additional functionality like load balancing, service discovery, or tracing.

A service mesh can provide several benefits for your solution. They can be grouped into the following categories:

• Security: A service mesh can provide security features like secured service-to-service communication with mutual TLS (mTLS), request authentication and more.

• Observability: A service mesh can provide features like tracing, logging, and metrics. These features can help you to understand the behavior of your solution.
• Traffic Management: Traffic management lets you control traffic flow between the services.
• Resilience: A service mesh can provide features like circuit breaking, timeouts, and retries. These features can help you to improve the resilience of your solution. For example, you can define how often an Envoy proxy should retry a connection or request if the first attempt failed.

Let's take a closer look at these benefits:

For Kubernetes, there are several service mesh solutions available. One of the most popular service mesh solutions is the Istio service mesh.

Typically, the service mesh solution uses the sidecar proxy pattern. A proxy is deployed as a sidecar container next to each service. So, a Pod for a service has at least the service container and the sidecar proxy container.

The sidecar proxy container facilitates communication between the service and the service mesh. It is responsible for the business logic of the service. Additionally, the sidecar proxy container can be automatically injected into the Pod if you label it accordingly. In the project Kyma, the sidecar injection can be activated on the namespace level or the Deployment level. If activated, each Pod, which is included in the namespace or Deployment labeled accordingly, will automatically get the sidecar proxy container injected.

Service meshes typically comprise two main components: the control plane and the data plane.

The control plane is responsible for managing and configuring the proxies to route traffic.

The data plane represents the communication between services. Service networks use proxies to relay all incoming and outgoing traffic to and from services within the service network. It is also responsible for inbound (ingress) and outbound (egress) cluster traffic.