In the last part of external-to-internal communication, we learned about Kubernetes Ingress, the resource that makes services work as a union and dispatches requests to target services. Does any similar idea jump into your mind? It sounds like a microservice, the application structure with several loosely coupled services. A complicated application would be distributed to multiple lighter services. Each service is developed independently while all of them can cover original functions. Numerous working units, such as Pods in Kubernetes, run volatile and can be dynamically scheduled on Services by the system controller. However, such a multi-layered structure increases the complexity of networking and also suffers potential overhead costs.
External load balancers are not aware the existence of Pods; they only balance the workload to hosts. A host without any served Pod running would then redirect the loading to other hosts. This situation comes out of a user's expectation for fair load balancing. Moreover, a Pod may crash accidentally, in which case it is difficult to do failover and complete the request.
To make up the shortcomings, the idea of a service mesh focus on the networking management of microservice was born, dedicated to delivering more reliable and performant communications on orchestration like Kubernetes:
The preceding diagram illustrates the main components in a service mesh. They work together to achieve features as follows:
- Service mesh ingress: Using applied Ingress rules to decide which Service should handle the incoming requests. It could also be a proxy that is able to check the runtime policies.
- Service mesh proxy: Proxies on every node not only direct the packets, but can also be used as an advisory agent reporting the overall status of the Services.
- Service mesh service discovery pool: Serving the central management for mesh and pushing controls over proxies. Its responsibility includes procedures of network capability, authentication, failover, and load balancing.
Although well-known service mesh implementations such as Linkerd (https://linkerd.io) and Istio (https://istio.io) are not mature enough for production usage, the idea of service mesh is not ignorable.