kubernetes is not a system for deploying containerized applications

… it’s so much more!

But why do I write this? These are the first few results of a google search for “what is kubernetes” (all emphasis is mine):


Kubernetes, also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.

https://enterprisersproject.com/article/2017/10/how-explain-kubernetes-plain-english (I had to search for the money quote, there were many good definitions and quotes in there that really are going in the same direction I want to go in this article):

Kubernetes eases the burden of configuring, deploying, managing, and monitoring even the largest-scale containerized applications.


Kubernetes (also known as k8s or “kube”) is an open source container orchestration platform that automates many of the manual processes involved in deploying, managing, and scaling containerized applications.


With the widespread adoption of containers among organizations, Kubernetes, the container-centric management software, has become the de facto standard to deploy and operate containerized applications.


Kubernetes is an open-source container orchestration system for automating software deployment, scaling, and management.


Kubernetes is a popular open source platform for container orchestration — that is, for the management of applications built out of multiple, largely self-contained runtimes called containers.

Wikipedia has the best definition here, where “best” means the one nearest to my definition:

Kubernetes is a tool to start Linux1 processes on multiple hosts.

That’s a bit simplistic, isn’t it?

Yes. But I do not think it is more simplistic than calling kubernetes a platform for containerized applications. I admit that kubernetes can only start binaries from containers2, but “application” means something else than “arbitrary program” nowadays…

Ok, let’s run with this. Why should I care?

Because thinking about kubernetes in the abstract might give you ideas how to solve problems that you might miss otherwise. I was amazed when I saw the Piraeus-operator building kernel modules on the nodes and injecting them into the running kernel3. We constantly see network plugins install CNI binaries into /host/opt/cni without batting an eye. All this is way more than “applications”! It’s a way of managing hosts, installing software (including kernel modules!) and shaping the compute environment for the needs of our (yes!) applications. Kubernetes gives us tools to control exactly which other parts of the system our processes may see and/or change.

I have used this flexibility to create network interfaces (for overlays) in (newly created) network namespaces. I have used it to restart system services. When I have a number of hosts and I need to control any aspect of a group of them, I can usually put together a container image and let it loose on exactly the parts of the system that I need affected.

All that is made possible by kubernetes being a tool to start processes on multiple hosts. It even has labelSelector, nodeSelector and other nice options to control exactly where you are starting things.

  1. And Windows, of course
  2. If you do not count CNI plugins.
  3. Dockerfile, build, load