KUBERNETES ARCHITECTURE

Master Node

Worker Node

Etcd

If you are curious to know, Why need of Kubernetes & Docker and their basic definations, then feel free to go through it---> https://dev.to/viveksahu26/kubernetes-for-beginners-basic-part-why-need-of-docker-k8-s-2bgf

MASTER NODE

What is a Node? Node refers to a computer or pc or virtual machine. You can consider the master node as a manager position of any company and worker node as a employee of that company. It's totally up to you assign nodes as a worker or master, but keep in mind that their must be only one master node & more than one worker node under master node or in a cluster.
Cluster is a set of worker machines, called nodes, that run containerized applications. Every cluster has at least one worker node.
It is responsible for managing the state of k8's cluster and it manages and control worker nodes. It also provides an environment for control panel.

COMPONENTS OF MASTER NODES:-

1)API Server

2)Scheduler

3)Controller Manager

4)Etcd

1)API Server:-

It is known as "kube-api server", a central control plane component running on the master node. Every components of master node communicate with it. The API Server is the only master node component to talk to the etcd data store, both to read from and to save Kubernetes cluster state information. During, processing it reads the current state of the worker nodes from etcd and matches it with the Desired state. For now assume etcd as a data storage, we will cover it in details later.

2)Scheduler (kube-scheduler):-

As soon as the new pods are created, Scheduler job is to assign new pods or non-schedule pods to a feasible Nodes. Every container in pods has different requirements for resources and every pod also has different requirements. So, according to these requirements scheduler searches for nodes existing in cluster fulfilling its requirements. And node which fulfilling its requirements or node meeting its requirements are knowns as feasible nodes. Questions arises, From where does the scheduler knows about the configuration of worker nodes? Etcd contains configuration of all worker Nodes existing in a cluster. Scheduler approaches to the api-server for configuration of nodes and api-server collects data from etcd and provides it to the scheduler.  Scheduler uses this Data(configuration of nodes) to schedule pod into a feasible Node.

NOTE:-

If scheduler doesn't find feasible nodes for pods, then they remain as it is till scheduler finds feasible node and these pods are known as non-schedule pods.

3)Controller Manager:-

Here is one example of a control loop: a thermostat in a room.

When you set the temperature, that's telling the thermostat about your desired state. The actual room temperature is the current state. The thermostat acts to bring the current state closer to the desired state, by turning equipment on or off.
Controllers are control loops or watch loops ( non-terminating loop that regulates the state of a system) which continuously running across worker nodes and notice the current state of each nodes and parallelly(at the same time) comparing the cluster's desired state (provided by objects' configuration data) with current state. Here, current state refers to the task worker nodes are performing or doing. And after noticing, it sends current state data of each worker node to the api-server and api-server store these data in etcd for future use. The controller(s) are responsible for making the current state come closer to that desired state.

4)Etcd:-

It's a key-value data storage for storing Kubernetes cluster state. It also stores configuration data of each nodes existing in cluster. New data is written to the data store only by appending to it, data is never replaced in the data store.
Note:- It is only accessible to kube-api server.

WORKER NODE

As the scheduler assign the feasible node(here refer to worker node) for a pod. Now, from here the role of worker node starts. Worker nodes knows its job very well that what to do next.

NOTE:-

Btw in Kubernetes, each component knows their job very well, there is no need to tell each components what to do next. For ex.:- As we have seen above that Master node don't have to tell scheduler about its role, to schedule pods to feasible nodes. Scheduler knows its role very well and start working as soon as it gets newly created pods or non-scheduled pods. Similarly, worker nodes knows their job as soon as they get pods. It provides running environment for client applications. These applications are encapsulated in Pods, controlled by the cluster control plane agents running on the master node.

A Pod is the smallest scheduling unit in Kubernetes or in another words Pods are collections of one or more container. And inside these containers your application runs.

WORKER NODE COMPONENTS

1) Container Runtime

2) Kubelet

3) Kube-proxy

1)Container Runtime

The container runtime is the software that is responsible for running containers. Although Kubernetes is described as a "container orchestration engine" or "container management engine", it does not have the capability to directly handle containers. In order to manage a container's lifecycle, Kubernetes requires a container runtime on the node where a Pod and its containers are to be scheduled. Kubernetes supports several container runtimes are:-

Docker

Although a container platform which uses containerd as a container runtime, it is the most popular container runtime used with Kubernetes.

CRI-O

A lightweight container runtime for Kubernetes, it also supports Docker image registries.

containerd

A simple and portable container runtime providing robustness.

frakti

A hypervisor-based container runtime for Kubernetes.

NOTE:-

In simple language, Kubernetes don't have capability to run container. So, it need tools to run these containers. And these tools are known as container runtime. Kubernetes job is to manage these containers.

2)Kubelet

The kubelet is an agent running on each node and communicates with the control plane components(i.e api-server) from the master node. It gets instructions from the api-server and interacts with the container runtime on the node to run containers associated with the pod.

NOTE:-

As the pods get scheduled by scheduler to a feasible node existing in a cluster. Then worker node components i.e. kubelet starts its job.

Kubelet also monitors the health of Pod's running container. It also connects the container runtime using container runtime interface(CRI).
CRI implements two services:-
1) Image Service:- Responsible for all the image-related
operations.
2) Runtime Service:- Responsible for all the pods and
container based operations.

3)Kube-Proxy

The Kubernetes network proxy runs on each node. It is responsible for dynamic updates and maintenance of all networking rules on the node.