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.
Discovering the Service Mesh
Objectives
After completing this lesson, you will be able to:
- Outline the core concepts of a service mesh.
- Break down the core benefits of a service mesh.
- Explain how a service mesh works in Kubernetes.
- Describe briefly the service mesh architecture.
Service Mesh: Usage Scenario
What is a Service Mesh?
Cloud-native applications are typically split into several distributed microservices, which will likely 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 because different teams can write microservices in other 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.
Benefits of a Service Mesh
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/request if the first one failed.
Let's take a closer look at these benefits:
Security
Using a service mesh in your cluster can secure the communication between the microservices out-of-the-box. The microservice developer doesn't have to implement security features like mutual TLS (mTLS) or encryption. The service mesh takes care of this. As another security benefit, a sidecar proxy provides the ability to authenticate requests for your service.
Observability
As shown in the figure above, all service requests go through the service mesh layer. The service mesh can collect all requests and provide additional functionality like tracing, logging, and metrics. This can help you understand your solution's behavior and how requests are processed.
Traffic Management
With traffic management, you can control the traffic flow between the services. You can use this feature to implement canary deployments, A/B testing, and more to make software release processes more reliable and faster.
Service Meshes in Kubernetes
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.
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 communicates between the service and the service mesh. The service container is responsible for the business logic of the service. Additionally, the sidecar proxy container will be automatically injected into the pod by the service mesh solution if the pod is labeled correctly. In project "Kyma", the sidecar injection can be activated on a namespace level. If activated, each pod will automatically get the sidecar proxy container injected when it is created.
A Note on Using Service Meshes
Service meshes are a great tool to improve the security and observability of your solution. However, they can also introduce additional complexity. You should carefully consider if you need a service mesh for your solution. If you are unsure, you can start with a simple solution and add a service mesh later if you need it.
Service Mesh architecture
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.
Summary
In this lesson, you discovered the core concepts of a service mesh. Now you know the core benefits of a service mesh and how a service mesh works in Kubernetes.
Further Reading
Log in to track your progress & complete quizzes