Kubernetes Architecture

 What is Kubernetes Architecture?

Kubernetes is an architecture that offers a loosely-coupled mechanism for service discovery across a cluster.

1. Clusters: 

A cluster is a collection of hosts (nodes) that provide computing, memory, storage, and networking resources. Kubernetes uses these resources to run the various workloads that comprise your system. Note that your entire system may consist of multiple clusters. 

A Kubernetes cluster has one or more control planes, and one or more compute nodes. Overall, the control plane is responsible for managing the overall cluster, exposing the application program interface (API), and scheduling the initiation and shutdown of compute nodes based on the desired configuration

2. Nodes: 

Each node is a single host that can be a bare metal server (on-premises or off-premises), virtual machines (VMs), or cloud-based virtual machines. Each of the compute nodes runs a container runtime like Docker along with an agent name KUBELET, which communicates with the control plane. There will be several Nodes inside one Cluster. Its job is to run pods.

Inside the Kubernetes, the node runs several Kubernetes components, such as KUBELET, THE CONTAINER RUNTIME, and KUBE-PROXY. Kubernetes Master will manage all the Nodes.

The nodes are the worker bees of Kubernetes and shoulder all the heavy lifting. In the past, they were called minions. If you read some old documentation or articles, don't get confused. Minions are just nodes.

3. Pods: 

Pods are where containerized applications run. They can include one or more containers and are the smallest unit of deployment for applications in a Kubernetes cluster. A pod is the unit of work in Kubernetes. Each pod contains one or more containers. Containers in pods are always scheduled together (always run on the same machine).

All the containers in a pod have the same IP address and port space; they can communicate using localhost or standard inter-process communication. In addition, all the containers in a pod can have access to shared local storage on the node hosting the pod. Containers don't get access to local storage or any other storage by default. Volumes of storage must be mounted into each container inside the pod explicitly. Pods are an important feature of Kubernetes. It is possible to run multiple  applications inside a single Docker container by having something like supervisors as the main Docker process that runs multiple processes, but this practice is often frowned upon for the following reasons:

• Transparency: Making the containers within the pod visible to the infrastructure enables the infrastructure to provide services to those containers, such as process management and resource monitoring. This facilitates a number of conveniences for users.

• Decoupling software dependencies: The individual containers may be versioned, rebuilt, and redeployed independently. Kubernetes may even support live updates of individual containers someday.

• Ease of use: Users don't need to run their own process managers, worry about signal and exit-code propagation, and so on.

• Efficiency: Because the infrastructure takes on more responsibility, containers can be more lightweight.

Pods provide a great solution for managing groups of closely related containers that depend on each other and need to cooperate on the same host to accomplish their purpose. It's important to remember that pods are considered ephemeral, throwaway entities that can be discarded and replaced at will. Any pod storage is destroyed with its pod. Each pod gets a unique ID (UID), so you can still distinguish between them if necessary.

4. The master

The master is the control plane of Kubernetes. It consists of several components, such as an API server, a scheduler, and a controller manager. The master is responsible for the global state of the cluster, cluster-level scheduling of pods, and handling of events. Usually, all the master components are set up on a single host. When considering high-availability scenarios or very large clusters, you will want to have master redundancy. 

5. Image Registry: Container images are kept in the registry and transferred to nodes by the control plane for execution in container pods.

What is Kubernetes node architecture?

Nodes are the machines, either VMs or physical servers, where Kubernetes place Pods to execute. Node components include:

kubelet: Every node has an agent called kubelet. It ensures that the container described in PodSpecs is up and running properly.

kube-proxy: A network proxy on each node that maintains network nodes that allow for the communication from Pods to network sessions, whether inside or outside the cluster, using operating system (OS) packet filtering if available.

container runtime: Software responsible for running the containerized applications. Although Docker is the most popular, Kubernetes supports any runtime that adheres to the Kubernetes CRI (Container Runtime Interface).