Photo by Murilo Viviani on Unsplash

Photo by Murilo Viviani on Unsplash

Kubernetes containers, fleet management, and applications

Training Guide

Article from ADMIN 71/2022
By
Kubernetes is all the rage, but many admins find themselves struggling to get started. We present the basic architecture and the most important components and terms.

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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Nested Kubernetes with Loft
    Kubernetes has limited support for multitenancy, so many admins prefer to build multiple standalone Kubernetes clusters that eat up resources and complicate management. As a solution, Loft launches any number of clusters within the same control plane.
  • Optimally combine Kubernetes and Ceph with Rook
    Ceph distributed storage and Kubernetes container orchestration come together with Rook.
  • VMware connections to the Kubernetes market
    VMware Tanzu comprises several tools and services that make it easy to build, run, and manage a Kubernetes environment from a single point of control.
  • Five Kubernetes alternatives
    Many admins consider Kubernetes the obvious choice for managing containers; however, don't ignore the highly efficient alternatives just because they are less prominent.
  • Monitoring container clusters with Prometheus
    In native cloud environments, classic monitoring tools reach their limits when monitoring transient objects such as containers. Prometheus closes this gap, which Kubernetes complements, thanks to its conceptual similarity, simple structure, and far-reaching automation.
comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs



Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>
	</a>

<hr>		    
			</div>
		    		</div>

		<div class=