DEV Community: vmtechhub

The theory of Kubernetes in 10 mins

vmtechhub — Fri, 22 Oct 2021 14:50:36 +0000

Containerization of an application is not the end of story.
For any serious application, it’s the beginning of a new world of orchestration.
We need to think about many things, such as:

It shouldn’t be down. If down or crashed, either restart or start a new one as soon as possible.
Is it performing as expected? How do we monitor resource consumption?
How to scale up/down with minimal efforts?
How to move it to a different machine in case the host encountered a problem?

It’s not as easy as it seems, even for a simple use case.
So, what can we do about this? That’s where an orchestrator comes into the picture.

What is Kubernetes?

The official documentation defines Kubernetes as:

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

Running containers on a single host or running a single container is not sufficient for a large-scale application.
We need a scalable solution like K8s which can handle the containers on scale and in fault-tolerant manner.

Kubernetes can run virtually anywhere — laptop, on-prem, cloud, bare-metal, VMs, etc.

The biggest advantage with K8s is that if an application can run in a container, it would(most probably) run on K8s irrespective of the underlying infrastructure.

K8s provides an abstraction over the underlying infrastructure which makes it possible.

Features

Here’s a brief list from the official documentation:

Service discovery and load balancing
Rolling updates and rollbacks
Self healing — kills and restarts unresponsive containers Scaling
Automatically mounting a wide variety of storage systems to store data
Secret and config management — to manage sensitive data and config separately from the containers
RBAC(Role Based Access Controls)

Kubernetes Cluster

A K8s cluster has two main parts — Master nodes and Worker nodes

Control Plane with Master nodes

Control plane with the help of master nodes, manages the state of a k8s cluster.
It is not recommended to run user applications on master nodes.

Worker nodes

Worker nodes run user/client applications.

Master Nodes

In a K8s cluster, control plane with master nodes manages the worker nodes, and the overall cluster.
Let’s see what is inside the control plane.

Components

1) API Server(kube-apiserver)

API server is the face of a K8s cluster. It exposes a set of APIs that are used by all the components. All the components talk to each other via API.
The main implementation of a Kubernetes API server is kube-apiserver which is designed to scale horizontally.

2) Scheduler(kube-scheduler)

It watches for the new tasks(newly created pods) submitted to K8s cluster, and selects a worker node that can run those pods.
To select a worker node, it considers the health of worker nodes, their load, affinity rules, any other software or hardware requirements.

3) Cluster store(etcd)

K8s uses etcd to store config and state of the cluster. etcd is strongly consistent and reliable distributed key-value store. Please note that the etcd is not used to store data of containers or user applications, it’s only for cluster state.

4) Controller manager(kube-controller-manager)

It manages and runs controllers, and responds to various events.
A controller’s main job is to monitor the shared state of the cluster and make every possible change to achieve the desired state if the current state is not the desired state, more on this later.

5) Cloud controller(cloud-controller-manager)

This is specific to the cloud on which a K8s cluster is running. If you’re not running K8s on a cloud, there will be no cloud controller manager.
From Kubernetes docs — the cloud controller manager lets you link your cluster into your cloud provider’s API, and separates out the components that interact with that cloud platform from components that only interact with your cluster.

Concept of Desired state and Current State

When we on-board a workload/app on k8s, we tell k8s what’s our expectations eg. We need 3 containers always up and running.

So, this becomes the desired state of our cluster. Generally, it is part of the different payloads like your Pod deployment config in which you may define the number of replicas.

K8s continuously monitors the current state of the system, and if there’s a different between desired and current state, it tries to achieve the expected state — it scales up/down automatically, restarts/terminates containers automatically, etc.

So, let’s say, we started with 3 replicas of our container.

Desired state = 3 replicas

After time T, one replica crashed.

Current state = 2 replicas
K8s controller manager noticed this event and found out that current state is no longer same as desired state.
K8s will take corrective actions and launch a new replica to match the desired state of 3 replicas.

And the good thing is — it will do it in an automated way.

Worker Nodes

A worker node is responsible for running a user application.
On a very high level, a worker node:

Gets a new task when scheduler(kube-scheduler) selects this node to “do something” via API server(kube-apiserver)
Executes the given task
Responds back to the master via API once the task is finished.

A worker node is a combination of:

Kubelet

Kubelet runs on a worker node. Kubelet is the main agent that does many critical things like — registering the node with cluster and reporting back to scheduler whether or not it would be able to run a task.

Kube-proxy

Kube-proxy is responsible for local cluster network

Container runtime

Container runtime is responsible for creating and running containers. K8s can use any CRI compliant runtime e.g. Docker, containerd, etc.

The diagram summarizes the flow that we’ve seen up till now.

K8s Objects

Let’s now look at some of the most critical K8s objects.

Pods

Pod is a wrapper around a container. It is the smallest deployable unit in K8s.

So, when we provide a Docker image and ask K8s to run and manage a container, it creates a Pod for that application. The containerized application runs inside the Pod.

It’s recommended to have one-container-per-pod container, but a Pod can have multiple related containers.

A Pod has a template that’s generally defined in a YAML file which tells what kind of container a Pod should host.

When a Pod goes down, K8s creates a new Pod.

Each new Pod has a different IP.

If a Pod has more than containers — those containers will share the same Pod IP and other network resources.

The container inside a Pod can be in one of the three states -

Waiting
Running
Terminated

The container can also have a restart policy:

Always(default)
OnError
Never

ReplicaSet

A ReplicaSet is another K8s object that acts as a wrapper around Pod. It is managed by DeploymentSet.

A ReplicaSet’s purpose is to maintain a stable set of replica Pods running at any given time.

The ReplicaSet knows from its config the Pod to run and how many replicas are needed. It then uses the Pod template to create those many replicas of a Pod.
To scale the application, ReplicaSet creates new Pods.

Deployments

Kubernetes documentation defines Deployments as below:
You describe a desired state in a Deployment, and the Deployment Controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.

Deployment supports self-healing, scaling, Rolling updates, Rollbacks, etc.

StatefulSets

When a Pod goes down, K8s creates a new Pod with a new identity but from the same Pod template, and the new Pod will have a new IP. So, basically, the old Pod is lost.

StatefulSets can be used to manage the Pods when we need to retain the Pod identity.

StatefulSets are useful for stateful applications. They’re similar to Deployments but when a StatefulSet relaunches a container, it retains Pod’s identity, also called — sticky identity.

DaemonSet

This is straight from the official documentation:
A DaemonSet ensures that all (or some) Nodes run a copy of a Pod. As nodes are added to the cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are garbage collected. Deleting a DaemonSet will clean up the Pods it created.
Some typical uses of a DaemonSet are:

running a cluster storage daemon on every node
running a logs collection daemon on every node
running a node monitoring daemon on every node

So, the flow looks something like below:

Deployments — Scaling, Rolling updates, and Rollbacks

To run a user application, K8s uses Deployments to manage Pods. Deployment manages ReplicaSets, and ReplicaSet manages Pods.

Scaling and Self-healing

The sole purpose of a ReplicaSet is to maintain a stable set of replica Pods at any given time.

Scaling — Depending on the replicas defined in the YAML template, ReplicaSet can create that many new Pods to match the demand.
Self-healing — In the same way, when a Pod gets crashed, ReplicaSet notices the change in the cluster state, and tries to launch a new Pod to replace the dead one.

Rolling Updates and Rollbacks

Here’s how it works in K8s-
Let’s suppose, we have a Java application.

We created a Docker image V1
We created a Deployment using a YAML template which refers to the image — V1
Deployment creates a new ReplicaSet RS1
ReplicaSet creates a new set of Pods depending on the configured number of replicas
Now, let’s say, we changed something in the application — a bug fix, an enhancement, etc.
We create a new Docker image V2
We update the YAML and change the image reference to V2
The controller observes a change in the image i.e. V1 -> V2
K8s creates a new ReplicaSet RS2(for V2) in parallel without touching old ReplicaSet RS1
K8s starts creating new Pods in RS2 in parallel
At this time, Deployment is running both the ReplicaSets — RS1 and RS2
RS1 — with old image V1
RS2 — with new image V2
At the same time, K8s starts a new Pod in the new ReplicaSet and drops a Pod in the old ReplicaSet
Finally, old ReplicaSet becomes empty and new ReplicaSet becomes fully operational with new Pods, running image V2
At this point, K8s doesn’t remove old ReplicaSet which is empty
The empty ReplicaSet is used in Rollback process
To rollback, K8s just makes a switch to the empty ReplicaSet, and it starts the same process in opposite direction — RS2 to RS1

During this whole process, K8s keeps running the application, there’s no downtime.

Services

K8s documentation defines a Service like this-

A Service is an abstraction which defines a logical set of Pods and a policy by which to access them . The set of Pods targeted by a Service is usually determined by a selector.

A Service is a logical grouping of a set of Pods which also acts as a load balancer of that set.

Pods can talk to each other via Service.

A call from outside of K8s cluster is intercepted by the Service which then forwards the request to a certain Pod from its set.

So, Service also acts as a network abstraction which hides all the networking complexities.

Main components of a Service

There are two main components of a Service:

Selector — Selector is used to select Pods which forms the logical group that is represented by the Service
Endpoints — It is a list of healthy Pods. Service keeps the list up-to-date by monitoring the changes in the Pods e.g. crashed Pod, new Pod joins the cluster, etc.

How does a Service form a group of Pods?

The service uses a label selector to select the Pods.

Labels are simply a set of key-value pairs that we can attach to certain K8s objects like Pod.

Let’s suppose, we have three Pods P1, P2, and P3. And, we have two labels — env and version
Here’s how these Pods are tagged with these labels:

P1 — env = prod and version = 1.0
P2 — env = prod and version = 1.1
P3 — env = prod and version = 1.0 Let’s also suppose that we have a Service with label selector defined as: > env = prod and version=1.0

So, based on this, Service will have two Pods in its set — P1 and P3
P2 won’t be selected by the Service because while its env label matches with value prod, but version is different — Service expects version=1.0 and P2 has version=1.1

Service Types

There are mainly three types of services:

Cluster IP — To access Pods from inside
NodePort — To access Pods from outside
LoadBalancer — To integrate cloud specific load balancer e.g. Azure and AWS would have different load balancers.

Volumes and ConfigMaps

Volumes

Volumes are used as a storage solution for a K8s cluster.

We use or mount volumes to store the application data permanently so that if a Pod is crashed and started, it would not loose its data.

K8s uses a plugin layer to handle the volumes so it is capable of working with different types of storage solutions.

For instance, we can use a Azure Disk, EBS, etc. as a storage solution.

Persistent Volume

It acts as a storage abstraction which provides APIs to access and manage persistent storage.

Persistent volume represents a storage, an application would link to a persistent volume via a plugin.

For instance, Azure storage would have its own plugin that can be used to link an Azure storage as Persistent Volume.

PersistentVolume Claims

These are storage requests made by the user. Users request for a Persistent Volume based on certain criteria, and if a persistent volume is found, it gets linked to the PersistentVolume Claims.

ConfigMaps

ConfigMap is a K8s object which is used to store non-sensitive Pod configurations. This is a key-value pair.

For sensitive data, it is recommended to use Secrets rather than ConfigMap.

ConfigMap is a great way to separate configs from the code.

ConfigMap can be injected into a container in three ways:

Environment variables
Command line args
As a file in volume

The only problem with first two is that these are static.

So, once an app gets started, and if there’s any change in the ConfigMap then it won’t be reflected until we restart the app because there’s no way to reload ConfigMap which was injected via environment variables or startup command.

Third option, using volumes, is the most flexible way where we create a volume for ConfigMap. Any change in the file will be reflected in the volume, and will be picked by the application.

Feel free to check out my page https://www.vmtechblog.com/search/label/kubernetes

Docker Quick Start

vmtechhub — Sun, 17 Oct 2021 14:14:50 +0000

Before talking about Docker, let’s first talk about Virtualization in general.

Virtualization

Virtualization is a way to utilize the underlying hardware more efficiently.

Do we really need virtualization?

In general, yes. If every single application requires a separate machine, chances are that most of the time that machine will be underutilized and we will be wasting the hardware resources like CPU, memory, etc.

With virtualization, many applications can share the same physical hardware.

A virtualization solution acts as a layer on top of actual hardware.

How does a system achieve virtualization?

It does so via a Hypervisor.

Hypervisor is a software through which we achieve desired virtualization.

There are two types of hypervisors:

Type-1 aka bare-metal because it runs directly on the hardware.
Type-2 runs as an application on the host operating system.

Virtual Machines(VMs)

Virtual machine as the name suggests, is a machine with its own OS. A VM emulates physical hardware.

An application running inside a VM doesn’t know if it’s running on the real machine or not, hence the name Virtual Machine.

Many VMs can run on the same machine without knowing each other.

A virtual machine runs on the Hypervisor and accesses the underlying hardware through the Hypervisor.

In this diagram, we see two different VMs running on the same machine using a Hypervisor.

VM1 has Linux and is running an application named App1.
VM2 has Windows and is running two applications — App2 and App3.

Containerization

Containerization or OS-level virtualization is an OS feature in which the kernel allows multiple isolated user-space instances, these instances are called containers.

A Container is like a box in which an application runs. The container provides virtualization to that application.

The application doesn’t know on which OS it is actually running, for that application container is everything.

It is the container’s job to provide libraries, dependencies, and everything else that an application needs for a successful execution.

The application runs within the boundaries of the container, hence it is less dependent on the host OS.
And for the same reasons, completely isolated from other containers running on the same machine.

What problems does a container solve?

Portability

Let’s suppose, we’re building an application from scratch.
So,

We find a machine.
We download all the required software, their dependencies.
Then we install and configure everything.

Configuring a software or tool generally involves changing some config file on the OS, or may be changing some network port, etc.
Finally, everything is up & running on your dev machine. Cool stuff!

Now, how would you move this application along with its configurations to another machine?

Without any containerization tool or technology, we would need to repeat everything that we did on our dev machine.
And, if everything is scattered and not properly documented, and managed, we may easily miss an important config on the new machine.

In that case, either the machine itself or some other application is screwed.

With the help of containers or VM, we can just copy the VM or the container to the new machine.

Because apps are configured to run inside a container and nothing is actually installed on the host machine directly, you move them as a package.

Packaging and Deployment

In extension of the previous point, as soon as you containerize your application, it is ready to be moved to any machine.

To create a container for your app, you tell the container everything about you app — configs, ports, file system dependencies, other s/w dependencies, etc.

The container becomes the runnable and deployable package.
Any machine which has the right container infrastructure will be able to run your container.

It is similar to Java classes, once compiled you can run the same class file on any machine as long as it has the right JVM.

Scaling

Containers promote microservices pattern. There should be one service per container.
Under heavy load, if you need another instance to share the load, you just need to add more containers, and your service is immediately scaled.

Dependency conflicts and clean removal of applications

Without containers, dependency conflicts may arise as multiple apps may require the different versions of the same dependency.

Let’s suppose, A needs x version of Sybase and B needs y version of Sybase.
Let’s consider another scenario — If you are uninstalling/removing an app from your system, chances are that you may forget to remove its dependencies which will remain there and eat the system’s space.

Dependencies like these not just make the working difficult but also pollute the machine when you don’t need them anymore.

In case of containers, an app and its dependencies are packaged as a bundle. So there is no dependency conflict.

Also, instead of removing an app, you remove the container. So, everything will be removed as a package which keeps a machine clean.

Docker

Let’s finally talk about Docker.
Docker website defines Docker as an open platform for developing, shipping, and running applications.

Docker is an application container which enables us to bundle an application and all its dependencies as a package so that it can be shipped anywhere and run on any machine.

It is written in Go language.

Under the hood, a Docker container is simply a Linux process that uses Linux features e.g. namespaces, cgroups, seccomp, etc.

Docker terminology

Docker client — Docker client is installed on the client machine. We run docker commands using docker client.
Docker daemon — Generally, installed on the same machine. It listens for Docker API requests and does everything required for a docker container to run.
Docker registry — A registry is a place where docker images are stored. For instance, GitHub is a registry where people manage their codebases. In the same way, docker images are stored in a docker registry. A registry could be public like Docker hub or private.
Docker image — An image is a read-only template with instructions for creating a Docker container.
Docker container — A container is a runnable instance of an image.

Difference between a Docker image and Docker container

Let’s take an example of a Java class. A class has some code which could be stored as a .java file on a local directory or as a github project. A class doesn’t do anything on its own.

But, when we compile and run a .class file, the same read-only class becomes a runtime object, an executable piece of code that does what it was coded for.

A docker image is just like a .java file that has some instructions on what to do when you want to run a container.
And when we run a docker image via docker client, docker creates a running container.

Just as we can create multiple objects of a single class, we can create multiple running containers from the single docker image.

High Level Working

There’s a nice diagram on Docker site which depicts the high level flow.

When we run a command to run a container from an image:

Docker checks if the image already exists on the system.
If yes, it uses the image to run a container.
If no, it goes to a registry to find and pull the image.
Docker downloads the image on the system
Docker runs the image and starts the container.

Useful Docker commands

Docker architecture and key components

Docker has a layered architecture. Some of the key components, in the order from low to high, are as below:

runc / libcontainer — https://github.com/opencontainers/runc/tree/master/libcontainer
containerd — https://github.com/containerd/containerd
Docker daemon — https://docs.docker.com/engine/reference/commandline/dockerd/
Orchestration — https://docs.docker.com/get-started/orchestration/

Here is a diagram which shows these components with a small description — what it is and what a component does.

What happens when we run a container?

Feel free to checkout my blog - https://www.vmtechblog.com/search/label/docker