In the first part, we have seen some important components in the K8s cluster. In this part lets talk about the components in the Architecture.
Let’s have a basic setup of one name node with two application Pods like below.
- One of the main components of K8s architecture is worker servers or nodes.
- Each node can have one or more application pods where containers will be placed. Nodes are the servers which actually does the work.
- Three important process must be installed in every nodes to manage Pods. Lets discuss these.
- Container-Runtime is a software that runs and manages the components required to run containers. This tool make it easier to securely execute and efficiently deploy containers, a key component of container management.
- Kubelet is the primary “node agent” that runs on each node. It is actually registering the node server to the K8s. Kubelets working with the configuration called PodSpec. PodsSpec is a Yaml or Json object which actually describes the Pod with all the details. Kubelet ensures that all the containers described in the PodSpec is running fine and healthy by interacting with nodes and containers, also takes care of assigning resources to the containers.
- The communication between the Pods handled by the Service component which is actually load balances and route the request to the specific Pods. The actual process responsible for forwarding requests from Service component to Pods is Kube-Proxy which should be installed in all the nodes. It also make sure that communication between Service and Pods is performant with low overhead.
Master nodes are completely different processes running inside, which controls and manages a set of worker nodes. 4 process should run in every master node to control the cluster state and worker nodes.
- API Server:
When we deploy new application in the K8s Cluster, We interact with the API Server through UI, Command Line tool or K8s API. This is like a gateway to the cluster to do all the changes in the cluster configurations.
Also acts as a Authentication gate keeper to allow only autheticated requests to the cluster. This is the only entry point to the K8s Cluster.
When we give request to schedule new Pod, the API Server will validate the request and sends the request to the Scheduler. Then Scheduler will start the Pod in one of the worker node. Scheduler will see the resources requested for the application Pod, have the intelligence to assign it to the best worker node based on the resources available. Scheduler will decide which node the application should go to, then Kubelet is the process will start the container Pod with the specifications given by the Scheduler.
- Controller Manager
Controller manager is responsible for re-schedule of the applications when crash happens. It detects the Cluster state changes. For example, if pod dies, controller manager will find this as soon as possible and sends the request to the Scheduler to re-schedule the specific Pod. Then the Scheduler will do the request to Kubelet to schedule the Pod.
It is a Key-Value store to the cluster state. All the changes happening in the cluster like new pod creation, Pod crash, Pod re-scheduling will be updated in this store. All the above three process API Server, Scheduler and Controller-Manager will use this key value store data to know the current state of the Cluster. So this etcd component can be called as Cluster Brain which as all the data about the K8s cluster. This store is only having cluster state data but not the application’s data which is running in the Pods.
Now, we seen important master processes and how crucial these especially etcd data. This data must be reliably stored means replicated. In practice, K8s cluster is made up of more than one master nodes. All the master nodes run its own processes where etcd data store is distributed across the master nodes.
These are some most important concepts in K8s cluster set-up. That’s it from my side now. ta ta. will see you soon.