Istio Components
In this tutorial, we are going to discuss about Istio components. Before that I’m going to provide additional information about service mesh using some analogy.
Example
Let’s assume I do have 3 managers. And each manager going to have a PA (Personal Assistant). Let’s assume there’s a CEO, CFO and Sales head.
Any communication being made to the CEO or from the CEO it will be routed through the personal assistant (PA). So the personal assistant knows to whom to communicate and how to take the message to the corresponding person.
Communication
CEO to CFO
Lets assumes CEO wants to send some information to CFO and CEO will send the message to the PA and the PA of CFO will receive the message and the PA will forward the message to the CFO. And CEO doesn’t need to know who is the sales head or who is the CFO. Directly the message will be handled by the PA.
CEO to Sales Head
The same way in case if any message needs to be sent to the sales head from the CEO. The message will be forwarded to the PA and PA will forward the message to the corresponding PA of sales head and they will forward the message to the sales head.
The actual managers doesn’t need to know how to send the message, to whom to send the message, when to send the message. So all that will be handled by the PA.
Now, for some reason there’s going to be a transition of the sales head. A new sales head going to come into picture and a few of the projects being handled by the new sales head. So any message being sent to the PA the PA will take care of what message to be sent to the backup sales head and what message to be sent to the actual sales head depending on the work distribution.
After the time limit gets over the actual sales head will get released and all the message will get routed to the new sales head and that will be taken care by the PA.
So all this transition doesn’t need to be published or need to be known by any other managers and the same thing is true with the external visitors as well. So if any new visitor coming in the first point of contact will be the PA.
Rename entities
Now, let me rename this entities. So this is going to be the pod and all the communication to the pod will be handled by the sidecar. It’s also called as Proxy. In Istio case we will be using envoy. So I can represent that as a sidecar, proxy or envoy.
I can have another layer of components which can control all this proxy. Let’s say I’m going to have a layer of entity. We call that as Istiod. That’s going to have n number of components like Pilot, Citadel and Galley.
After Istio version 1.5 all these three components have been merged and made as a single component called Istiod. Whenever I’m installing Istio as a part of Kubernetes, I will be having one single component called Istiod. That’s going to have all the functionalities of pilot, citadel and galley.
While discussing about the Istio architecture we will have detailed discussion about the roles and responsibility of these components.
So now all these components together that’s going to manage the sidecars.
Data plane and Control plane
So from a centralized location, I will be having control on this particular sidecar on what to do, what not to do and how to do. And this is what we call it as the data plane. And the one that’s going to control all the sidecar, we call that as a control plane.
Slowly I’m going to introduce the terminologies one after the other. Don’t worry about the internal architecture and the functionalities. We are going to have detailed discussion about each and every component in the future tutorials. So don’t worry.
This is a very high level overview to get a feel on what is Istio and how it’s going to play its role and what are all its responsibility.
So on a high level, if I get into the Kubernetes every pod that’s going to have the actual container that’s going to do its responsibility. And Istio will inject a proxy or a sidecar to each and every pod that is getting created within the namespace where I have enabled the Istio.
So the key word that we need to observe very carefully is what are all the namespace where the Istio needs to be enabled. And that will be enabled by adding a label to that particular namespace saying any pod that is getting created within that namespace should have this particular sidecar and the sidecar will be handled by the proxy thats called envoy. So this is the proxy Istio will be using.
I can go ahead and use other proxies but this is a very popular one thats made to do the actual job of proxy within this service mesh. And to achieve this particular requirement Istio was created.