Saiyam Pathak avatar
By Saiyam Pathak
Director of Technical Evangelism


Learn and understand the various components forming the underlying architecture of Kubernetes.



In this video, we'll be going through Kubernetes architecture. Kubernetes is a container orchestration engine that manages all the containers and application workloads running but behind the scenes, it does a lot of stuff. So many pieces are running a lot of components in both the master node and the worker node. Kubernetes has a concept of a master node and a worker node. So, these are either the bare metal machines or VMs on any cloud instance.

Kubernetes Components

Let's discuss the components first and then see how they all connect. On the master node, the central brain of Kubernetes is the API server. So let's start the request of creating a pod. To create a pod, a user will run kubectl, a command-line tool. Then, run the pod name and the image. This request goes to the API server. Now when the request goes to the API server, there are three things: authentication, authorization, and admission.


Firstly, the request is authenticated with the headers that are passed, and then based on the RBAC rules, it is authorized whether that particular user is allowed to create a pod. Now, the scheduler will find the best fit node for the specific pod. The scheduler has all the information about the nodes, about the resources. So based on the resources, the taints, tolerations, and node affinity, it will try to find the best fit node within the cluster to run the pod. Now, it gives the node information back to the API server. Again, it tells me that this node has to run this particular workload. Now what happens is, on the worker node side, the main component is kubelet. Also, kubelet will keep asking the API server whether I have some workload to run. As soon as the scheduler says, "Okay, this workload has to run on node one, " the API server will inform "you need to run this workload." When the kubelet gets this information, it does all the fetching of images using the container runtime. So container runtime, like Containerd or Docker, will pull the image then run the pod with the right set of defined configurations. Then a pod will run with a single or multiple containers, whatever is defined in the pod specification.


Another component in worker nodes is Kube-proxy, the core network component of Kubernetes that manages all the networking and communication across the cluster. So your port-to-port communications, all the communication, all the rules are taken care of by Kube-proxy. And there is a controller manager component in the master node, which runs on the control plane. The controller manager is a set of controllers running a replication set controller. So if we create a deployment, then we define the number of replicas that we have to run, which is taken care of by the replication controller. If we make a DaemonSet object that needs this particular workload to run on all the nodes, the DaemonSet controller does that. So like this, there are different sets of controllers, and collectively it is called controller manager. It controls the Kubernetes cluster and the state within which they are running three replicas and all those things.


ETCD is a highly available key-value database for Kubernetes that stores all the information of all the resources and objects running in the cluster. Now, the API server is responsible for storing all that information in ETCD. So if any pod spec or anything there is changing, the cluster state stored in ETCD is maintained in ETCD. So the Kubernetes architecture is on a very high level. On the master node, you have an API server, which we can consider as the brain. Then, you have the scheduler that schedules the node and the controller manager having various sets of controllers that control the workloads across the cluster. Then the kubelet always communicates with the API server and keeps updating the workload status that it is running. It is also responsible for pulling the image using the container runtime and then running the pod, which is eventually the module container. Then the Kube-proxy is the networking component that makes the network communication within the cluster. And the nodes are the VMs or the bare metal machines.

In conclusion

So that's all in all Kubernetes architecture, master, worker nodes, and this is how your workload runs on Kubernetes. And these are the components responsible for different things within the cluster. That's it for this lecture. Thanks for reading. See you in the next one.

Don't stop now, check out your next lesson