Kubernetes is one of the most dazzling attractions in the current circus of IT tools. Once developed by Google, it is now under the aegis of the Cloud Native Computing Foundation (CNCF) and has therefore become a genuine community project.

However, Kubernetes (aka K8s, because of the eight letters between the K and the s) also seems to have driven a wedge into the normally closed ranks of administrators. Container advocates often can't imagine IT without containers and the right choice of orchestrator, whereas others have had little reason to consider Kubernetes until recently, which sometimes leads to a defiant reaction. Old habits can die hard.

This behavior is understandable, because the Kubernetes universe is now dominated by a kind of tech-speak that outsiders need to learn before diving in. Because the solution is constantly evolving – with custom resource definitions, providers, and replica sets – even many die-hard admins of the early days of K8s have lost track of what's what, or what is used when and for what purpose.

In this article, I rush to the aid of Kubernetes newcomers, providing a basic introduction to the topic that assumes no prior knowledge. In addition to the most important terms from the K8s bubble, a brief architecture overview of Kubernetes is also on the agenda, as is an explanation of the solution's most important functions from the user's perspective. If you haven't yet dealt with K8s, you'll get the knowledge you need here.

A Word Up Front: Containers

Before I get to Kubernetes, a few things need to be clarified about containers. Many terms and, above all, acronyms are difficult to understand if you have no prior experience of the subject.

Already known by most is that Kubernetes is, at its core, a solution that orchestrates containers across physical system boundaries; that is, it rolls them out and operates them together such that a working symphony is created from individual containers. For Kubernetes to start and stop containers on the target systems, it needs the appropriate tools in place.

Kubernetes could, of course, implement the required infrastructure on the systems, but the tool sees fleet management as its core task. It looks to roll out containers locally on individual systems with the use of a local runtime environment. The problem is, several such environments now exist.

Most administrators should be familiar with the combination containerd and runc used in Docker; the docker command-line tool only acts as a front end for containerd, which calls runc in the background. Ultimately, runc creates containers and manages them. Consequently, runc is also the component that supports the Open Container Initiative (OCI) specifications (Figure 1).

Figure 1: Kubernetes launches containers on the target systems with the Kubelet node agent and uses the container runtime interface (CRI). © Tom Donohue, www.tutorialworks.com

Moreover, runc is not used just in the context of docker and containerd, but also in the context of Container Runtime Interface-O (CRI-O), which is a genuine Kubernetes-speak acronym. Until just a few years ago, Kubernetes used the containerd interface (i.e., the one from Docker), but at the behest of IBM and Red Hat, a separate solution emerged.

Kubernetes now follows a standard at the level of its own API that defines communication with external CRIs. The independent containerd and CRI-O projects compete, but both implement the CRI standard and can therefore be considered potential K8s back ends. Under the hood, both solutions use runc. The standard way to run Kubernetes today is based on CRI-O.

The competitor Podman, which replaces the docker and containerd tools, also requires some explanation. Podman calls runc directly in the background instead of dragging in another abstraction layer, as Docker does. This arrangement is especially interesting for admins who need to investigate why containers are not working on individual systems. At the end of the day, Podman is just another front end for runc.

Basic Technology

The K8s universe has a term you won't find in most Kubernetes architecture diagrams, although it describes Kubernetes's operating principles well: desired state management, or DSM, which describes the correct state of user resources. Kubernetes automatically takes care of achieving this state in the background. Therefore, a call to the Kubernetes cluster is not: Start container A on node 1, container B on node 2, and container C on node 3, and make sure the container data sets are replicas (i.e., they match). Instead, the statement would read: Create three replicas of the same container.

Kubernetes automatically assumes, according to its default configuration, that the three instances of the containers will need to run on different hosts. I go into detail about the concept of a replica later.

The Right Format

If you read the Kubernetes documentation or tutorials, you regularly come across files in YAML or JSON format that need to be passed into the running cluster. Against the background of DSM, the purpose of these files becomes obvious: They allow you to tell a running Kubernetes instance what the desired state looks like and are therefore formats for templates in which you describe the desired setup as precisely as possible. Kubernetes then evaluates this information and creates the resources as specified.

If you're familiar with cloud principles, you'll instinctively think of services such as CloudFormation in AWS, and you're right: DSM is a core principle of classic orchestration and therefore also core to the functionality of CloudFormation or other solutions such as OpenStack Heat.