What is Kubernetes and How It Rules the Container World?

For the past few years, the name Kubernetes became popular among many tech circles. For some, it is just a term they hear often but for others, it is the star of modern development and management. If you are in the first category, it is harmless to ask, "what is this Kubernetes exactly".

First, there was Docker

If you are interested in Kubernetes, knowing Docker (or more generally containerization) is a must. Because, if we are simplifying enough, one could say Kubernetes is a container manager.

In 2013 first version of Docker was released. Back then Docker was introduced as a tool for solving the "it works on my machine" problem. Docker achieved this by OS-level virtualization. This means Docker is packing the software with a platform that the software runs on. Since it is OS-level virtualization there is no virtualization overhead, so the software runs as fast as it runs on bare metal.

After Docker was released, it quickly created its community and culture and started to change the development, testing, and deployment of modern software.

Then Google created Kubernetes

Since Docker was taking over the market, infrastructure that depends on it has grown exponentially. That created a problem of management. How will two containers will communicate? Can I use load balancing for containers? How can I manage disk usage? How to manage different versions of the same container image? High availability?

There were many answers of course. Docker by default supported Docker swarm(now deprecated). Docker-compose came up and to this day still used. Some people manually created pipelines and services for solving their problems.

Then Kubernetes joined the game. It was different. It didn't just manage the containers, it managed the whole infrastructure and every possible interaction between containers. Most of the hand-created deployments, which usually required expertise, were already handled by Kubernetes.

Another natural question arises: How?

What is Kubernetes

Like said previously, Kubernetes is a container orchestration tool. The core unit of Kubernetes is a pod. You can think of a Pod as a single container(which is not necessarily true but let’s keep it simple). Kubernetes contains resources that manage the pods and their behavior. Let’s jump in:

Workloads

Workloads typically contain how replication of pods are managed and there are different approaches you can take:

Deployments:

Deployments make sure pods stay in the desired number. For example, let say you have deployment for a backend micro-service, and you calculated that 10 different containers should be enough processing power. Also, Deployments provide high availability. When one of them crashes, the others take the load.

StatefulSet:

This is appropriate for stateful applications. Stateful means when we interact with the app we cause state changes in the app itself. For example, Redis is an in-memory database, and if it crashes data in Redis gets deleted. So Redis lost its state. StatfulSet achieves this by numerically naming pods and keeping track of them.

DaemonSet:

DaemonSet provides a pod for every node in the system. Maybe we should clarify what a node is? A node is a physical(or virtual) computer/server that also a member of a Kubernetes cluster. So, when DaemonSet runs its replication count depends on how many nodes there are. Useful for things like monitoring tools, or network managers/proxies.

CronJob / Jobs:

Job workload defines a pod that when it finishes running pod exits and is forgotten. Similarly, CronJob works by running one and completing but also we schedule a running order for Cronjobs. For example, when you need a job that will run every day. You use cronjob. Uses crontab syntax for scheduling.

Services and Networking

Kubernetes networking provides many different mechanisms for communication. However, simply touching on Services and Ingress should suffice.

Service:

Services define how workloads will be exposed to the outside.

Ingress:

Ingress defines an HTTP layer for Kubernetes and handles name resolution in various ways.

Configuration

Kubernetes contains mainly two methods for storing configuration data outside of the pod. ConfigMaps and Secrets.

ConfigMaps

ConfigMaps contain non-confidential configuration data for numerous applications. Pods can access these files by environment variables or by reading a file.

Secrets

Similar to ConfigMaps, the only difference is, Secrets contain secret data that should not be easily accessed.

Storage

PersistentVolumes:

Pods are ephemeral. So does their disks. Since at least some applications use disk for something, Storage is critical for managing pods. Persistent Volumes mount spaces to pods themselves and provide like the name says persistent storage.

StorageClasses:

Storage Classes automatically manage the creation of persistent volumes when a pod has requested some space. Popular among the cloud-based clusters.

Extensibility

Kubernetes is extensible when it comes to resources, we can define our services, workload, or different storage mechanisms. Just like a plugin system.

Market share of Kubernetes

According to the 2019 Sysdig report, Kubernetes holds %77 of the container management market. Alternatives are OpenShift(holds %9), Swarm (holds %5, also deprecated), Mesos(%4), and others like Rancher less than the others. I would like to point out that is not even the whole picture, because OpenShift is actually a Kubernetes variant(like rancher). They are different from a product perspective but a software perspective pretty similar. Also, Swarm is deprecated and Mesos probably holds less share in 2021. So from a competitive perspective, Kubernetes holds the market.

Uses cases of Kubernetes

Since Kubernetes uses containerization, shifting from your on-prem microservices to Kubernetes is rather easy. Kubernetes gives you the ability to manage your infrastructure by declarative YAML files. So basically you tell Kubernetes state you want to be in and Kubernetes continuously tries to ensure this state is sustained. So ask yourself, do you want high availability, Infrastructure As Code, highly scalable services.

‍