Kubernetes Architecture Simplified #2
Tags: kubernetes, devops, beginners, cloudnative
Published: 2021-08-06 22:49:28

So by now, I have heard a lot about **Kubernetes** and how people are finding it so cool. This really intrigued me and I wanted to get a deeper look at the **architecture**. 

Here is my attempt to put down my learnings in a simple language.

As we know, **Kubernetes** is a container orchestration tool that has revolutionized the deployment process. Everyone is talking about it and day by day, more and more companies are adopting it. Let's understand its structure.

If you have any doubt while going through the blog, feel free to refer to the **Kubernetes** [Official Documentation](https://kubernetes.io/docs/home/). You can also refer to this [blog](https://dev.to/lakshya806/introduction-to-kubernetes-1-3ik1) to get a brief **Introduction to Kubernetes**.

Before diving deep into the architecture let's first understand few concepts that will help understand the workflow of **K8s(Kubernetes)** better.

## Basic Concepts Behind Kubernetes

### 1. Declarative vs Imperative

Let's understand this with an example, suppose you were asked to drive a car at exactly 60km/hr. To attain this, you would probably try to speed up the car till you reach 60km/hr and if the car was over 60km/hr, you would try to slow it down. 

This is a **declarative model** where you describe the **desired state** without actually stating the actions required to reach there. 

On the other hand, if you were simply told to slow down or to speed up the car, that would be an **imperative model** where you were provided the list of actions that will create the **desired state**.

So it is important to understand that **Kubernetes** runs on a **declarative model** that saves us a lot of time and energy. We can just say "make sure that there are four pods running" instead of telling it spicifically "run this pod, run that pod". **K8s** will take care of everything else for us.

### 2. Control loop
![observe,diff and act control loop](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/r2p8qq12jynec5a5ryhj.png)

The **control loops** are one of the core features that make **Kubernetes** so special. Almost every structure in **Kubernetes** uses some sort of a control loop, where you describe the **state** of the objects you want and not the actual steps to get there. 

This is a loop that is constantly running and it includes the following processes:

1. **observe**: it observes the current state of the Kubernetes [cluster](https://kubernetes.io/docs/concepts/architecture/).

2. **diff**: compares the current state of the cluster to the desired state.

3. **act**: makes sure that the current state meets the desired state.

### 3. Reconciliation

If you understood the control loop and declarative statements, this is basically the implementation of the two. Reconciliation is a simple process that makes sure that the **actual state** is looking like the **desired state** via the observe, diff, and act control loop.

## Kubernetes Architecture

Now that we have understood about **states** and **control loops** in Kubernetes, this would be the right time to get introduced to the actual **architecture of Kubernetes**. 

![Kubernetes Architecture](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rgqkypxmlsnhyt1bzh6t.png)

Learning K8s can be overwhelming so I will try to provide a very high-level view of how it is structured. Do check out the [Official documentation](https://kubernetes.io/docs/tasks/tools/) for referencing. 

### 1. Master Node

On the left, we have the **Master node**, and connected to it are several **worker nodes**. The master node runs several important processes that are important to run Kubernetes. It also controls and manages the worker nodes. 

The master node is where the plan of action required to align the current state to the **desired state** is formed. Master node mainly consists of the following component:

1. **kube-apiserver**: This is the **most important** component responsible for handling all the internal and external requests. 
**Kube-apiserver** allows communication between the **master node** and the **worker nodes**.

2. **kube-schedular**: It basically creates new pods and decides which worker node to deploy it on. 
It also consists of all the resources to create and deploy **pods** on the **worker nodes** if an old pod dies. 

3. **kube-controller-manager**: This runs **controller processes** in the background that take care of the cluster. One of the controllers' function is to communicate to the **kube-schedular** when a pod dies and makes sure the **desired state** that we talked about, is reached.

4. **etcd**: It is a **key-value** store database that stores the state of the **Kubernetes** cluster like the number of pods, their state, etc.

### 2. Worker Node

On the right, we have the **worker node**. While the **master node** runs the tasks that are important for Kubernetes to function, it is the **worker node** that runs the tasks given by the user. 

There can be more than one worker nodes attached to a master node but at least one worker node is needed to run the cluster. 

Before looking at the components of the worker node, let's first understand what **pods** are. 

**Pods** are the smallest unit in Kubernetes. They are made up of one or many [containers](https://www.docker.com/resources/what-container#:~:text=A%20container%20is%20a%20standard,one%20computing%20environment%20to%20another.&text=Available%20for%20both%20Linux%20and,same%2C%20regardless%20of%20the%20infrastructure.) and act as a single instance of an application.

Now coming back to the **worker nodes**, they consists of:

1. **Container runtime engine**: This is an engine that runs the **containers** inside the **pod**. For example, we have **Docker** in the figure above. You can read more about Docker [here](https://docs.docker.com/get-started/)

2. **kubelet**: It interacts with the container runtime engine(Docker) and makes sure that the required containers are running inside the pods. It also facilitates communication between the worker node and the master node. 

3. **kube-proxy**: This enables internal as well as external networking among the **pods**.

## Conclusion

Yaay you reached the end! This was a brief overview of the **Kubernetes Architecture**. I hope you now have a clearer picture of the concepts behind it. 

There are few details that I have omitted in order to keep the explanation simple, but feel free to check out the [Documentation](https://kubernetes.io/docs/home/). I really hope you liked the blog and do let me know in the comments if you did. 

Feel free to **connect** with me on [**Twitter**](https://twitter.com/lakshya806) and say hi, I'll be more than happy to have a conversation. :) 

This blog is a part of my **#100DaysOfKubernetes** challenge. Do check out my journey on [**Twitter**](https://twitter.com/lakshya806) when you drop by. :D

Thanks for reading! :)