Container Freight Handler

On the Kubernetes controller services side, only one service is missing to complete the set of mandatory basic tools: the scheduler. The name says it all: The scheduler keeps track of all available nodes and their current workloads. When a user submits a DSM definition that requires the creation of new containers, the scheduler selects the appropriate targets when called by the controller manager. Controller decisions are not just directly related to containers; they can also include other virtual resources – but more on that later.

What Is Kubelet?

If you have not yet experienced Kubernetes hands-on, you might nevertheless be familiar with at least one term from the Kubernetes world: Kubelet. This Kubernetes component does not run on the Kubernetes controller cluster like all the others described thus far.

Instead, it is useful to think of Kubernetes's cluster-wide architecture as a server-agent architecture. When a user passes resource definitions to the cluster in a declarative language, Kubelet then converts it into a concrete infrastructure, such as containers, on the cluster's individual compute nodes.

As soon as the scheduler has selected the target system for resources, the Kubelet instance there runs and starts the desired resources. The service creates containers (e.g., with the CRI-O container interface mentioned earlier). By the way, the smallest resource unit that Kubelets handle is the pod. A pod groups an arbitrary number of related containers that always run on the same system.

Extending Kubernetes

In theory, all of the components that you need to convert your instructions into running Kubernetes instances have been described. Kubernetes's feature set is quite substantial – it has definitions for virtual networks, virtual storage volumes, and containers, and Kubernetes supports virtual load balancers, which are needed because Kubernetes normally creates containers with private IP addresses and then uses load balancers to set up port forwarding. However, a good amount of functionality can be implemented with plain vanilla Kubernetes, as a couple of examples clearly demonstrate.

In the Kubernetes API, the replica sets already mentioned act as a paraphrased definition for a resource that does not comprise just one pod, but several that need to be configured in a coordinated way. These resources can be databases (e.g., YugabyteDB [1]) that implement replication directly at the database level instead of offloading the task to the underlying storage.

On the downside, the basic set of Kubernetes functions is by no means capable of creating every function you can think of. For example, anyone who has sniffed the air in the OpenStack universe knows that software-defined storage (SDS) and software-defined networking (SDN) play a very important role. If you virtualize the entire data center network and rely on components such as the Cisco application-centric infrastructure (ACI) to do so, you will also want your container network to be integrated into this system. If you use storage appliances or rely on a Ceph cluster, you will want to connect Kubernetes somehow so that persistent storage volumes can also be used in the cluster.

However, it would be completely unthinkable for the Kubernetes developers themselves to develop and maintain these interfaces to external services. They do not have the knowledge, nor would it make sense from their point of view to deal constantly with several side issues instead of focusing on the main application. One early Kubernetes design goal was therefore to provide external interfaces for extensions. In the Kubernetes context, several terms and acronyms again require explanation.

One central concept is the plugin, which forms the de facto link between Kubernetes and external technologies, translating requirements from Kubernetes into machine code on the target systems. In Kubernetes, this concept is often further refined into various plugin groups. For example, K8s relies on plugins that follow the Container Network Interface (CNI) specification. The same applies to storage plugins.