Kubernetes Architecture Simplified #2

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. You can also refer to this blog 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

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.

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.

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 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 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

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. 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 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 when you drop by. :D

Thanks for reading! :)