Hi let's have a better understanding on various core components of kubernetes cluster.
Already we had a quick discussion on various components involved, now I am going to explain
with an analogy as well as compare it with the cluster that we have installed. So that we will
have better understanding on how they are related to each other and what functionality
they are going to do and we are going to have a detailed discussion on each and every
component in future. When it comes to the core components there are two different categories
available that is controlled plane and runtime components. As a part of controlled plane
components that's going to make sure the kubernetes cluster is up and running
that's where I am going to have kube api server, kube controller manager, kube scheduler and
etcd database. As a part of run time components, I am going to have
kubelet, kube proxy and container runtime like docker rocketd or containerd. These
three components going to make sure the applications within the kubernetes is running
fine. Now let us have a quick analogy and relate these components. I'm going to explain with
an analogy and I'm going to map each and every component of this analogy to the real
component of kubernetes. I'm going to match the functionalities, so don't try to match as it is
for understanding purpose this analogy is made. Assume I do have a head office and n number
of branches operated in different locations. For understanding purpose I am going to have a
location say Chennai and another location in say New York and within head office I will be having
different departments, say one department going to take care of all the communications.
That is within the departments within head office as well as communications to the other
branches the communication department going to take care. The same way I will be having
another department that's going to make all the planning for the projects, how to execute the
current project and what are all the future projects, where to execute the future projects
basically all the planning will be done by the planning department and I will be having
HR department, they'll be taking care of the people and each branch office they will be
having a head, who is going to take care of that particular department or the branch. Let's call
him as branch manager. So each branch going to have a manager and the entire branch will be
under the control of the branch manager in terms of who are all working in that specific
branch whether everyone is getting the required resources or not and everyone is secure and
safe everyone adhere into the same policy, put in within that specific Branch or not. So the
entire branch will be under the control of the branch manager and the branch manager
will be having a secretary to coordinate the communication. So the entire communication
coming in or going out of the branch will be going through the secretary and all the details
about the head office the people who are working what project being managed the data
needs to be stored somewhere. So I'm going to have a data store and that needs to be very very
highly available so I may have a cluster of databases which is going to store all the data about the people what communication
is happening and what are all the reporting hierarchy every information will be stored within
this specific database and the branch manager will be reporting to the head office through the
communication channel and for external communication I will be having a reception. So
whoever wants to communicate they will be coming through this specific or the protocol
with which they will be communicating and that's the reception or the front desk. Now
I am going to replace each and every component related to the kubernetes. Branch
manager that's the kubelet and that's going to run in each and every worker machine and the
communication entire communication will be handled by the kube api server and
the front desk that is like kubectl tool and that will be used to make the communication and
that's going to leverage the kube api server to do all communication and project planning
that's called a scheduler kube scheduler and the HR that's called controller and the database
that is etcd database and that's going to work us a cluster or a quorum. Manager secretary is
the kube-proxy. Now let's assume I do have a cluster where there is no job happening and
how the reporting hierarchy and what is going to report to what. The kubelet that's going to be a
continuously running daemon and that will be made to get installed in each and every machine,
along with kubelet I will be having kube-proxy the reason because I may start n number of
pods and all the communication within the pods within the nodes as well as across the
nodes and going across the cluster needs to be taken care and that will be coordinated by the
kube proxy. The kube proxy will support n number of network provider to support the
network communications and kube scheduler that's going to find out which node can take
what type of work. Say for example I may have a different infrastructure, say for example this
particular machine will have SSD and graph processor, the similar way I may have another
node which is going to have SSD and graph processor. So what that means is any process
related to machine learning if it is executed using the graph processor the efficiency is
going to be much higher. So I need to have a planner which is going to place the container
so that the container is placed within this specific node, where the graph processor is
available. So in the similar way I may have different type of requirements like all
the front end containers needs to have the cache running along with the node. Say
I do have a front end container and it's going to use some cache for better performance.
So the cache should be co-located along with a front end so these type of scheduling
requirement will be required for the containers and the kube scheduler going to take care of
what container should be placed in which node. I may have some constraints that particular
node will not have enough space to accommodate the container
So the kube scheduler going to find out which node going to have the space and it's going to
prioritize which node can do that particular job in a better way, accordingly it will be scheduling
the requirement to put in the container and as per the schedule the kubelet will take care of
creating the container and make it up and running. Once the container is up and running
that will be controlled by the controller, in terms of which are all the group of containers going to
work together and serve the front end. Front end I'm just considering it as an application
a web application just for example. Now within the application I may have a requirement
I need to have two replica of front end and that should be getting executed where I do have the
SSD processor. So accordingly the scheduler will decide which node can do that job in a
better way once that is decided the container will get started. Once it is started that will be
controlled by the controller, in case if that particular node goes offline for some reason
and it couldn't serve the request, it will decide one particular instance or one particular replica
is not available and that needs to be scheduled in a different node. With the help of the
scheduler it will identify that is the controller will identify which node can satisfy
the requirement and accordingly the container will be placed in those nodes. So within
controller I am going to have multiple controllers like node controller in terms of
controlling the nodes replication controller in terms of controlling the replications and every
machine will be having the run time that is docker or rocket or containerd. Accordingly the
container would get created. So I do have a cluster up and running where I do have a master
and node 2 is the master and I do have n number of workers that is node 3 and node 4
I can get all the components as a part of the all namespaces, here I do have kubeapi server
kube controller, kube scheduler and the kube proxy that is running in each and every machine
to coordinate the communication and I am using calico network provider
so the calico pod is also installed. Now you might be wondering where the kubeadm tool
kubectl tool and kubelet. All these three components needs to be installed as a daemon
that's why while doing the installation we will be installing all these components as a daemon.
In this particular case we used kubeadm tool, so that's going to install the network provider
controller api server all as a pod. As a next session as a introduction I am going to revise
the different type of installations and what installation we did. So in a quick summary
we related various components with an analogy for better understanding
and to remember their functionalities.