Hi, in our recent few articles we are talking about basic Kubernetes and we talked about how Kube proxy works, what is a control plane, what is an etcd, and what are node components of Kubernetes. If you missed the articles you can find them below.
In this article, we are going to look into a hot topic, which most people still associate with Kubernetes but in fact, it exists before Kubernetes. So let’s start with what is service mesh.
What is a service mesh?
There are a lot of different ways people define service mesh. What I understand is service mesh is a component that understands traffic, takes care of routing and other decisions along with observability on each node. Please note each node is very important. This means that each of your nodes knows about where it has to send traffic and how to deal with the incoming traffic and monitor the traffic on each node.
In most cases, there will be an ambassador container [Note not a sidecar container, look at the article below for the difference between the two] which taps the traffic and then makes the decision based on its rules and monitor for observability.
For configurations and settings, these containers talk to a central component that provides rules and configurations to these containers that run with each node.
Does service-mesh works only on Kubernetes?
No. Well, I talked about containers so you must be confused that it works with Kubernetes. You can consider this container as a separate process running on each node that taps the traffic and does the processing as mentioned below. A service mesh provides the ability to make decisions control traffic and other such things as soon as it tries to go out of the node or as it enters the node. You don’t have to rely on something else in the middle to control that.
How traffic flows?
Let me take you through a very basic service mesh that you can think of.
Look at the diagram above. All the traffic going out or coming in will pass through a process or container in case of k8s. The process or the container takes the decision weather to allow the traffic, rate limit it, or other such decision. So every instance of app have a container which can take this decision and hence is aware of the whole network of service. Thats maybe why it is called service mesh.
Who keeps the configuration?
Now as we talk earlier that how the configuration of the whole service mesh comes. It is something like below.
Everyone has the same config and a wholesome config. Based on that each ambassador can take decision what to do with a particular traffic.
So this was very basic of how service mesh work. In next articles we will talk about few service mesh and how they relate to this model that we discussed today.
