Understanding Kubernetes for Beginners

This article provides an overview of what we can achieve by using Kubernetes by providing simple explanations with examples. It is a good starting point for anyone beginning the journey towards a very widely used tool for managing and scaling containers.

What is container orchestration

Kubernetes is commonly described as a container orchestration tool. What does it actually mean.

Container orchestration is the process of managing, scaling and maintaining containerized applications.

Let us try to understand the above statement in detail.

Container management without Kubernetes

If you have already worked with containers, like, for example, docker containers, you would be aware that containers.

1. Provide application isolation

2. Are widely used package and containerize apps, so that they can be run anywhere

Containerized application example

Now let us try to understand how a containerized application would work. Suppose we have one container containing the application, another one with the database. The application and the database can connect to each other via the container ip address and port number. Similarly, let us assume we have another container with messaging service in between application and database containers. All these three containers will also be able to connect to each other similarly.

Let us now suppose that we have 20 such small independent applications, like a microservice, each having their own application frontend, messaging service and database servers that need to communicate with each other. The applications are interdependent, so that unavailability of one applications can lead to failed use cases for other applications as well.

Further, it is imperative that we have a failover for each server so that whenever one container crashes, another one is available. Now this makes 40 application containers, 40 messaging server containers and 40 database containers. These are just very simple numbers. In reality there could be hundreds or even thousands of containers. For our understanding, we will go ahead with 40 + 40 + 40 = 120 no. of containers. So we have 40 application frontend containers named APP1, APP2, APP3, … APP40. Similarly, we have 40 messaging service containers named MS1, MS2, MS3, … MS40. And then we have 40 database containers named DB1, DB2, DB3, … DB40.

Problem Statement

Now let us assume that the container containing APP2 failed. Then we are left with just one APP2 server. At the same time DB6 also failed. We have one failover for each container, so the applications keep running without any glitches. However, as there is no automated checking of the containers, the containers that have got crashed may not be immediately noticeable. In the meantime, if the failover APP2 server or DB6 server also crashes, the whole system might crash as the applications are interdependent on each other for executing business use cases. 

Hence we need to keep a ​track of the 

1) failing containers

2) load on each server which can help with the balancing load on each server.

In the absence of a container management tool, let us suppose that we are using scripts to monitor the containers. With scripts it usually takes time to notice a container failure and hence a delay in bringing up another container. To ensure that the applications are running smoothly, we should be able to bring up the failed containers immediately, so that at any point of time, the no. of containers stay the same as configured. Now let us see how Kubernetes addresses these.

How Kubernetes performs container orchestration

First, let us go through the terms that we will be using to explain how Kubernetes addresses these concerns. All the containers in Kubernetes reside inside a pod which is the smallest unit in Kubernetes. A pod can host one or more containers. There could be multiple pods in a node. Node is a physical or virtual machine hosting the pods. And there could be multiple nodes in a cluster. A Kubernetes cluster consists of such nodes which hosts pods also called worker nodes.

Components in a Kubernetes Master Node

The container orchestration functionality is performed by a set of nodes called master nodes. There will be more than one master node per Kubernetes cluster to ensure high availability.

The master node contains following components which manage the cluster.

1. Controller Manager – Keeps track of the cluster and takes decisions like if a pod needs to be repaired or a new pod needs to be brought up as and when required.

2. Scheduler – Keeps track of the workload on available nodes and decides on which worker node the next pod should be scheduled on based on the available and required server resources on the nodes.

3. etcd – Stores the information regarding master and worker nodes required to manage the clusters. It is a distributed key value store. Etcd is also responsible for implementing locks to ensure there are no conflicts.

4. API Server – API server is the component that serves as the entry point for kubernetes. Whether it is a command line interface or a UI or an API, all interact with kubernetes via the API Server.

Components in a Kubernetes Worker Node

The above process work together as master node components to manage the worker nodes which are actually running our applications.

A worker node will typically have

1. Kubelet – it keeps polling API server to check if it needs to run something.
2. Container runtime interface for example, docker, containerd etc.
3. Kubeproxy – Maintains network rules on nodes that allow network communication to the pods.

For example, when the API server gets a request from Scheduler to run a new pod on a particular worker node, API server will pass this request to the kubelet on that worker node. Kubelet will inform Container runtime interface (CRI) to run the pod. CRI will use the network rules maintained by kubeproxy to perform this task.

Summary

This post provides a very basic understanding of Kubernetes and how I performs container orchestration. The examples used are for understanding the concepts at a beginner level. From here, one can proceed to delve further into Kubernetes.