Whether you're a software developer, system administrator, or an aspiring cloud enthusiast, understanding Kubernetes is becoming essential in the ever-evolving world of modern application deployment. In this beginner-friendly guide, I'll demystify Kubernetes, breaking down complex concepts into bite-sized pieces, and empowering you to harness the true capabilities of this open-source powerhouse.

What is Kubernetes?

Kubernetes, also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.

Kubernetes is like a helpful assistant for managing and organizing applications that are stored inside containers. If you don't know what are containers and how to build them, check out this blog.

Kubernetes was initially developed by Google in the early 2010s as an internal project called "Borg." Borg was Google's internal system for managing and orchestrating containers across its vast infrastructure. The experience and insights gained from Borg served as the foundation for Kubernetes.

Currently, Kubernetes is managed by Cloud Native Computing Foundation (CNCF).

Why K8s is needed?

You might think- "I can build containers and deploy them like I usually do on AWS or Azure etc. It works and why should I learn Kubernetes?".

Now, imagine you have many of these containers, and you want to make sure they're deployed, or set up, in the right way. You also want to be able to easily increase or decrease the number of containers based on the demand or the number of people you're serving.

That's where Kubernetes comes in. It's like a smart system that automatically takes care of deploying these containers, making sure they're running smoothly, and managing them as a group. It handles tasks like starting containers, making sure they have the resources they need, and even fixing them if they stop working. Basically, it automates the stuff that you would have to do manually.

Suppose it's new year sale and there is a sudden surge in traffic on your application. K8s automatically scales up/down your containers based on the needs.

Architecture

There are many components in K8s so don't worry if you don't understand everything at first. To make you understand better, I will be using an analogy to simplify these terms. Here it is:

Suppose you arrived at a wedding and there is delicious food at the venue! There are Chinese, Thai, Continental, Indian and some more types of cuisines available at various stalls. Each cuisine has a different stall and each stall has different counters. Suppose counter A represents snacks, counter B represents the main course etc. There might be 1 or more people at each counter and more people at the back of the stall cooking the food. Customers give the order at a stall and interact at the billing counter. All of this is managed by a food management service present at the wedding. It manages which cuisine stalls need extra cutlery, which needs more raw materials and things like that.

If you can relate to the above scenario then you will understand Kubernetes easily as the basic high-level architecture of Kubernetes can be related to this just to develop a basic understanding. If you cannot relate then too it's fine as you will get the idea as you further read this blog.

Let the food management service be the control plane Node, a cuisine stall as a worker node, each counter as a pod, a worker at a counter as a container and the billing counter as Kube-proxy. Let there be a manager at each stall (Kubelet) who interacts with the food management service head (API server).

Just look at the architecture and there's no hurry to understand it right now. I will make every component clear as you read the blog.

Let's first look at the control plane node!

Control plane node

As the name suggests, it has the control of the K8s cluster. The components that matter for now are:

• API server - You can imagine it like a brain of the Kubernetes cluster. When you interact with the cluster, all the API calls go to the API server. Whether you interact via a user interface or a CLI. There are two ways of interacting with it - an Imperative way and a Declarative way. The Imperative way is via a command (for example):

     kubectl run nginx-server --image=nginx
  

  The Declarative way is via YAML or JSON files(for example):

    apiVersion: v1
    kind: Pod
    metadata:
      creationTimestamp: null
      labels:
        run: nginx-server
      name: nginx-server
    spec:
      containers:
      - image: nginx
        name: nginx-server
        resources: {}
      dnsPolicy: ClusterFirst
      restartPolicy: Always
    status: {}
  

  Don't worry if you don't understand the command or YAML file. Now after these commands go to the API server, the API server does 3 things - Authentication, Authorization and admission.

  1. Authentication: The API server handles authentication, which verifies the identity of the user or client making the request. It ensures that only authorized individuals or systems can interact with the Kubernetes cluster. Authentication mechanisms can include usernames and passwords, client certificates, or integration with external identity providers.

  2. Authorization: Once the API server authenticates the request, it moves on to authorization. Authorization determines what actions the authenticated user or client is allowed to perform within the cluster. It checks the user's permissions and roles to ensure that they have the necessary rights to carry out the requested operation. RBAC(Role-based access control) comes into play here.

  3. Admission: After successful authentication and authorization, the API server applies admission control. Admission control enforces additional policies and rules to validate and mutate the requested objects, such as pods, deployments, or services.

• Scheduler - After the API server is done, the scheduler will find the best-fit node to run the pod. In K8s, anything that you run runs on a pod. It will take the resource and request and limit into consideration and then find the best-fit node among the worker nodes.

• Controller manager - runs the controller processes. The controller process is a loop that watches the shared state of the cluster through the API server and makes changes attempting to move from the current state towards the desired state. It is a type of binary that has different types of controller managers like Replicaset controller managers, deployment controller managers etc. (we will talk about this in further blogs)

• etcd - It is a key-value database for your k8s cluster. All the cluster states are stored here. API server writes to it.

• Cloud controller manager(CCM) - It handles cloud-specific functionalities within Kubernetes, such as managing load balancers, persistent volumes, and other resources provided by the cloud provider. It serves as a bridge between Kubernetes and the cloud infrastructure.

Worker node

Some components are:

• Kubelet - It is the component that keeps on polling the API server asking the API server if there's anything for Kubelet to run. When the scheduler assigns that a pod needs to run on a so-and-so worker node, the API server communicates the request to the Kubelet of that worker node.

• Container runtime interface - Kubelet then uses the CRI(now Containerd is used instead of Docker) to fetch the image from a container registry.

• Pods - In K8s anything that you run runs as a pod. A pod can run 1 container or it can run multiple containers.

• Kube-proxy - It maintains the network rules on nodes. These network rules allow network communication to your pods from the network sessions inside or outside of your cluster. Every time a pod is created, ip-tables are handled by kube-proxy

Setting up Kubernetes cluster locally with Minikube

minikube quickly sets up a local Kubernetes cluster on macOS, Linux, and Windows. It is just for practice and to get a feel. Using minikube does not mean you know the actual hows and whens of starting an actual cluster. But don't worry, I will cover them in the future blogs as well along with more tools.

Assuming that you have docker installed and running, set up your cluster after reading these docs.

Now go to your terminal or command line and run the following:

minikube start

Note: In minikube, a single node acts as the control plane and also the worker node as minikube is just for demo purposes.

This will start the local minikube cluster and the output will look something like this.

If it doesn't then there is something is wrong with Docker.

Now install Kubectl from here. kubectl is the Kubernetes command line tool.

Now let's deploy an Nginx web server on your minikube k8s cluster.

$ kubectl create deployment nginx-server --image=nginx                                                   ─╯

deployment.apps/nginx-server created

Now, it will take some time to pull the Nginx image and start running.

$ kubectl get pods
                                                                                       ─╯
NAME                                READY   STATUS    RESTARTS      AGE
nginx-server-586675bc87-xp7j8       1/1     Running   0             5m27s

A pod name of nginx-server-586675bc87-xp7j8 is assigned to the nginx-server deployment.

$ kubectl get pod nginx-server-586675bc87-xp7j8 -o wide    

NAME                            READY   STATUS    RESTARTS   AGE     IP             NODE       NOMINATED NODE   READINESS GATES
nginx-server-586675bc87-xp7j8   1/1     Running   0          9m31s   10.244.0.144   minikube   <none>           <none>

You then expose port 80 (Nginx runs on port 80 for HTTP)

$ kubectl expose pod nginx-server-586675bc87-xp7j8 --type=NodePort --port=80

service/nginx-server-586675bc87-xp7j8 exposed

Now we do port forwarding so that port 80 from inside the pod is mapped to port 8080 of our local host.

$ kubectl port-forward nginx-server-586675bc87-xp7j8 8080:80

Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 8

And hooray!! You just started a nginx server on your cluster and you can view it by visiting localhost:8080 :

This is it for this blog and I hope that you liked it. Thank you if you read it till the end!