Kubernetes architecture consists of two main components:

• Master Node

• Worker Node

Master Node

The master node also known as the control plane manages the cluster and controls workload components such as pods and worker nodes. It makes the global decision about the cluster.

The control plane consists of four components, each serving a specific purpose. The components are kube-apiserver, kube-scheduler, kube-controller and etcd.

1. Kube-apiserver

   • Kube-apiserver is responsible for orchestrating all operations within the cluster. It is the primary management component of kubernetes. It allows interaction from the outside world with our cluster.

   • API server acts as a gatekeeper for the whole cluster. It exposes API for every operation like add, update, delete, and display in the kubernetes object in the cluster. API Server validates the data and configures the api object such as pods, services, replication controller and deployment.

   • Interaction with API is done with a client called kubectl

2. Etcd

   • Etcd is a distributed reliable key-value lightweight database that stores the data used to manage the cluster. It is the single source of truth about the cluster.

   • It only interacts with kube-apiserver in the whole kubernetes architecture.

   • Whenever we run kubectl command, every information we see is from the etcd server. Every change made to the cluster, only once it is updated in the etcd server is considered to be complete.

   • Etcd is responsible for implementing locks within the cluster to ensure that there are no conflicts between the masters when there are multiple nodes and multiple masters in the cluster.

   • If the api server makes two requests simultaneously to the etcd then etcd decides which came first based on the order of the requests and flagged the other one as an error request.

   • When we run etcd, it starts a service listening on port 2379 by default.

3. Kube-Scheduler

   • The kubernetes scheduler is responsible for scheduling pods on the nodes.

   • It schedules the pods based on the constraints mentioned in the configuration file.

   • The scheduler is only responsible for deciding which pod goes on which node. It doesn’t place the pod on the nodes. It's kubelet who creates the pod.

4. Kube-Controller- Manager

• A controller is a process that continuously monitors the state of various components within the cluster. It makes sure that the current state of the cluster is equivalent to the desired functioning state.

• There are four controllers node controller, replication controller, end point controller and service account and token controller. The node controller is responsible for monitoring the status of the nodes.

• If a node is unreachable it removes the pod assigned to that node and provisions them on the healthy ones.

• The replication controller ensures that the desired number of PODs are available at all times. Hence, if a pod dies it creates another one.

Worker Node

Worker nodes consist of three components kubelet, kube-proxy and container runtime.

1. Kubelet

   • Kubelet is the primary agent that runs on each worker node. It is considered as the captain of the ship.

   • As mentioned above in the kube-scheduler section, kubelet creates the pod on the node based on the specification provided.

   • Kubelet is the point of contact between the control plane and the worker node. It interacts with kube-apiserver and provides health information to the master node.

2. Kube-Proxy

   • Kube-Proxy maintains the network configuration and rules on the nodes. It handles all network communications inside and outside of the cluster.

   • It exposes services to the outside world. It creates the appropriate rules on each node to forward traffic from those services to the backend pods.

3. Container Runtime

   Container Runtime is responsible for running containers. Kubernetes supports container runtimes that are compliant with Open Container Initiative, including CRI-O, containerd and rkt.

Conclusion

If there is a request to create a pod in the cluster then something like this will happen.

The API server will create a pod object but will not assign it to the node. It will update the information in the ETCD server. The scheduler continuously monitor the API server and will realize that there is a new pod with no node assigned.

The scheduler will then identify the right node for the pod and will communicate that back to the kube-api server. The API server will update the information in the ETCD server and pass that information to the kubelet in the appropriate worker node.

The kubelet will create the pod on the node instructing the container runtime engine to deploy the application image. Once done, the kubelet will update the status back to the API server and the API server then update it in the ETCD cluster.

References

For more detailed information check out the below links.

Official Documentation: https://kubernetes.io/docs/concepts/architecture/

KodeKloud: https://kodekloud.com

100 Days of Kuberenetes: https://www.youtube.com/@AnaisUrlichs