Kubernetes 101 : A brief introdution to the Service Mesh
The kubernetes microservices deal directly with the service mesh, so they don't have to handle the conversion of protocols, the communication errors, the timeouts, ...,
All these are handled by the service mesh "agent".
In the "sidecar" service mesh, the service mesh is implemented separately and lives outside of the microservice.
The service mesh handles a lot of tasks, among these are:
- The conversion of protocols. It can convert a rest API http protocol to a TCP one for example, to facilitate the communication between two heterogeneous applications.
- It encrypts the communications between the microservices and handles authentication
- It does health checks, handles the timeout and the retries errors.
- Monitors the communications between the microservices.
- load-balances the traffic between the microservices.
The data plane and the control plane components of the mesh:
The service mesh has two components.
The data plane manages the conversion of protocols, deals with timeout errors, encryption, ...
The control plane gives for example to the data plane information about the type of encryption between the services, or protocols used for the communication - TCP, UDP, Rest API, ...
Service mesh types:
There are two types of service mesh, the "In process" and the "sidecar" type.
In the "In process" service mesh model, the service mesh is "embedded" within the microservice, and the microservices communicate with each other using the mesh directly.
The "In process" model is much faster than the "sidecar" model.
In the "sidecar" service mesh, the service mesh is implemented separately and lives outside of the microservice.
The sidecar service mesh can be easily implemented with different microservices since it is not a part of any microservice.
Below is a diagram of a "sidecar" service mesh:
The service mesh "agent" runs in a container in the same pod as the microservice.
Some examples of a service mesh are Istio and Linkerd.
Comments