Understanding Kubernetes. A dive into the basics and working of… | by Patryk Kobielak | Jan, 2022

A dive into the basics and working of Kubernetes

Patryk Kobielak
Photo by Verne Ho on Unsplash

In mid-2014 Google for the first time announced the development of the Kubernetes [2]. It was heavily influenced by Google’s Borg system (cluster management system that “admits, schedules, starts, restarts, and monitors the full range of applications that Google runs” [3]). Initially, it was aimed to orchestrate containers and work with Docker.

Containers we see today in short is a concept of building a package of a target application along with its dependencies and running it somewhere out of the box. The said “package” is in fact an image of an operating system (except for scratch containers) and “somewhere” is a container engine. So, if one says “container” we need to think about an instance of an image running on a container engine.

Container image

Fig. 2. 1 Container image building process
Fig. 2. 2 Example Dockerfile


After a container image is built and ready to run. It is deployed to a container engine and spins up on top of an existing host OS without hardware virtualization. In fact, it is calling the host OS kernel to mimic the underlying OS within the container. It is important to note that containers are not virtual machines. The comparison of both can be found in chapter 2.6.

Fig. 2. 4 Container components

Container runtime (a.k.a. container engine) is where containers are deployed to run (see Figure 2.5). These are several common container runtimes:

  • CRI-O [9],
  • Docker [10].
Fig. 2. 5 How to think of containers, containers engine and OS
  • check the stdout of the container,
  • get metrics (e. g. CPU usage, memory usage & limit),
  • check container configuration details (e. g. assigned IP address).
Fig. 2. 6 Linux Containers architecture breakdown

Container orchestrators are one layer higher in managing resources and lifecycles than container engines (see Figure 2.7). Whereas container engine enables running containers on a single node, the orchestrator allows synchronized scheduling of containers on multiple nodes despite the localization and node host OS configuration.

Fig. 2. 7 Orchestration layer in the Linux Containers architecture
Fig. 2. 8 Example Multi-Cloud Kubernetes Cluster [12]
Fig. 2. 9 Example Multi-region Kubernetes setup
Fig. 2. 10 Example Multi-architecture Kubernetes setup

Resource decomposition

One of the most revolutionary factors of containers orchestrators success in the industry is the ability for managing resources. When a cluster of nodes that will be orchestrated is assembled, its resources are being virtually decomposed (see Figure 2.11), which means that they are no longer seen as separate spaces where workloads can be deployed, but rather as a single pool of resources that is available to use.

Fig. 2. 11 Container orchestrator node resources decomposition

The container orchestrator that brings the attention of the most nowadays is Kubernetes (used by 78% of companies that took part in the CNCF survey) [13]. It is a sophisticated, and yet in continuous development, tool and engine to orchestrate both homo and heterogeneous environments consisting of containers and 3rd party custom operators. The Kubernetes cluster consists of a control-plane and a data-plane (see Figure 2.12). The core functionalities are provided by the components of a control-plane (master nodes):

  • scheduler,
  • API server,
  • controller manager.
  • kube-proxy,
  • container-runtime.
Fig. 2. 12 Kubernetes Architecture in short [14]

The control-plane

The control-plane’s responsibility is to manage the whole cluster with the use of the internal components.

The data-plane

The data plane’s responsibility is to maintain the connection with the master plane, provide low-level container management capabilities and observability for the currently running workloads.

Managed Kubernetes

“The big three” cloud providers — AWS (Amazon Web Services), GCP (Google Cloud Platform), and Azure (Microsoft) provides a service called Managed Kubernetes. Each has its own naming — EKS on AWS, GKE on GCP and AKS on Azure:

  • Microsoft’s Azure Kubernetes Service (AKS)
  • Google’s Kubernetes Engine (GKE).

Considering features of the container orchestrator and an insane amount of data flowing through the Kubernetes cluster, the number of fields that could be monitored is huge and includes:

  • network policies (f. e. deny hits),
  • network traffic utilization,
  • network traffic types,
  • application metrics,
  • and many more…

It is important to note the differences between Linux containers and virtual machines (VMs). Both are packaged computing environments that isolate various applications and their dependencies from the rest of the system. Core differences are in terms of scale and portability.

Fig. 2. 13 Architecture comparison: Virtualization vs Containers [19]
Fig. 2. 14 Example of Communication in Microservice, SOA, and Monolithic Architectures [20]

All links and sources in the article

Leave a Comment