Understanding the Kubernetes cluster components.
component-wise deep-dive into Kubernetes cluster architecture
I’ve been developing and deploying applications on Kubernetes for more than 3 years now and started knowing about it more as a consumer of the platform for deploying my applications. Slowly I was intrigued by its ease of use in deploying heavy client-server applications and wanted to explore the intricacies of the platform. This led me to know more about the architecture of the Kubernetes(K8s) cluster and after understanding it in-depth and building a cluster from scratch all by myself I thought to share the brief role of each cluster component via the above architecture diagram.
Each cluster, as shown above, has one master node and one or many worker nodes where the application pods are deployed in a Kubernetes cluster. For ease of understanding, I have shown only one worker node in the above diagram but in a real-time scenario, multiple worker nodes are spun up for a cluster supporting heavy data-intense applications and the underlying hardware of the cluster is also chosen accordingly.
The first four components described below form the part of the master node of any k8s cluster followed by the remaining three to be part of each worker node on every k8s cluster.
ETCD cluster —
etcd datastore stores info about the cluster such as nodes, pods, configs, secrets, service accounts, role-bindings, and other Kubernetes resources. Basically, every info for a “kubectl get command” comes from the etcd server and is therefore rightly termed as the brain of any kubernetes cluster.
KUBE-API server —
Kube API server is at the center authenticates a kubectl request and sends the response back from etcd server. This component lies at the center of all the tasks that needs to be performed in a cluster and is the only component that interacts with the etcd datastore.
KUBE Controller Manager —
This component on the master node of a k8s cluster manages the various controllers and is usually bundled as a single binary containing all controllers into a single package and run as a single process for easy use. Almost every k8s object has a controller associated with it for eg. Node controllers, replication controllers, job controllers, service account controllers, etc.
KUBE Scheduler —
It is only responsible to decide which pod goes on which node. It doesn’t actually place the pod on the nodes as that is done by the kubelet. The scheduler decides pod placement basis its CPU/MEMORY requirements mentioned in yaml file and thus place it on the matching node.
Scheduler schedules the pods on the worker nodes in two phases:-
i. Filter Nodes — Filters the nodes which don’t fit the criteria of pods’ cpu/memory requirementts.
ii. Rank Nodes — Ranks the nodes on the basis of the resource requests and limits mentioned in the application pods using a priority function
KUBELET —
This component on the worker node registers the node within the Kubernetes cluster whenever it receives a request from scheduler to load a pod/container on the node. It then requests the CRE(Container Runtime Engine) to download the app image and run an instance.
Kubelet also monitors the state of the pod and the containers in it and sends a timely report to the kube-api server.
KUBE Proxy —
All pods within the clusters need to communicate with each other and that is possible via a pod network. This component on the worker node registers the node within the Kubernetes cluster whenever it receives a request from scheduler to load a pod/container on the node. It then requests the CRE(Container Runtime Engine) to download the app image and run an instance.
Kubelet also monitors the state of the pod and the containers in it and sends a timely report to the kube-api server.
Container Runtime Engine (CRE) —
The last and final component from the above architecture diagram is that of the container runtime engine which is the software required for running containers. Kubernetes supports container runtimes such as containerd, CRI-O , etc other than the widely used Docker Container Runtime.
Conclusion-
All of these above components form the basis of a complete working Kubernetes cluster and are required to set up communication between master and worker nodes. This blog aims to establish a basic brief understanding of the responsibilities of each of the cluster components and if one wishes to read and comprehend more on any of the individual components or how it is installed can be always checked up on the official documentation here. Drop me any comment as feedback for this post and I will be happy to respond!
