Kubernetes Architecture.

Kubernetes Architecture.

There are two types of nodes or machines in Kubernetes architecture, master node (control plane) and a worker node.

Worker Node:

Each worker node has multiple pods running on it, there are 3 processes which needs to be installed on every worker node i.e are container runtime (Some of popular container runtimes are docker, containerD and cri-o), Kublet (Responsible for scheduling the Pods on the container runtimes, also kublet can communicate with container runtime and node), KubeProxy (Responsible for forwarding the requests while Pods trying to communicate to each other through a service).

Control Plane (Master Node):

There are four processes which runs on every control plane node.

API Server:

Whenever we tries to communicate to kubernetes cluster (be it from UI or command-line tool) the request first goes to api-server. So it acts as cluster gateway where it also additionally authenticate the request to determine its coming from valid user.

Schedular:

When we request to schedule a new Pod, request first comes to the API-Server where it validates the request and then forwards it to the schedular. Schedular is responsible for scheduling the Pod to the Node which can hold the new Pod by analysing various factors like CPU, Memory required by the Pod.(Basically by comparing the resources required by the application and the Node having those many resources). Schedular just decides on which Node the new Pod can be scheduled but the process which actually starts that Pod is the Kublet.

Controller Manager:

Suppose one of the Pod dies on any Node, so there should be some process to track these details and as soon as it detect that it should recreate a Pod so these details or a current state of the Pod is monitored by Controller Manager.

ETCD:

ETCD is a key-value store, we can actually called it cluster brain where it stores the current state of our cluster so even if our cluster crashes we can recover that state using ETCD. Every change we made to the clustered is stored in ETCD i.e. things like a new Pod created, Pod died etc however the application data is not stored in ETCD.

So with this cluster setup we can see how important control plane processes are so in real world we will be having more than one control plane where API-Server will be load balanced and ETCD will a distributed storage across all control planes.