Posted 2020-07-12
Sometimes, I hear the question asked: what is kubernetes? And, sometimes I hear an answer like: it's basically containers.
Kubernetes is not basically containers, and should hardly be thought of as related to containers at all.
The hype for both containers, and kubernetes seems to be around promising something similar. That promise is something like: lightweight, sandboxed, VM-like environments for running complex systems as a cluster of fine-grained services.
This promise is neither here, nor there - and seems to side-step the contract that these technologies enable in favor of marketing der kundenwert.
I do believe that kubernetes is elegant technology for deploying microservices, and I have no doubt that docker is the right container technology to pair it with. Rather, my objection is in dismissing a technical learning opportunity by ending a conversation with a throw-away marketing line.
Skip this section if you're already familiar with Unix init.
When a *nix system starts up, a special process is launched by the kernel before any other processes. This process is called init.
On a technical level, init's job is to be the parent-most ancestor process for all user-space processes - including both user applications and critical service daemons. It also takes ownership (becomes the parent) of orphaned processes.
On a much more practical level, init is a critical component in stable linux systems. Its job is to act as a system orchestrator: launching, monitoring, restarting, and killing key services.
For better or for worse, modern linux systems use systemd as their init process. Systemd makes this init is system orchestration role a bit more clear:
A stable linux system relies heavily on its orchestrator. A stable application service relies heavily on its configuration for working with that orchestrator.
Understanding your orchestrator can be a massive operational value in software development. On numerous occasions, I won expensive story points with one-liner systemd configuration changes.
Kubernetes is an orchestrator for clusters of network hosts. It is init for disparate systems.
One can run 4GB CentOS docker images in a kubernetes cluster, and still get value out of the orchestrator for managing (at the very least) automatic restarts. Maximising value in using kubernetes requires one to deploy services that make use of common APIs (including perhaps k8s extensions running in the cluster). This is analogous to making better use of your systemd orchestrator on intra-host systems.
Like systemd, kubernetes has a declarative API, performance implications, and creates some vendor lock-in for consuming applications. Unlike systemd, kubernetes is still relatively infant. For example, declaring service dependencies requires hackery or utilising extensions. The extension interface is extensive but somewhat obtuse.
Good use of kubernetes is phenomenal. It provides an environment that throws away otherwise expensive, necessary, operational expertise for managing and scaling services. Be sure not to confuse this with kubernetes instantly solving all your scale and orchestration problems. It's a framework - and it's not particularly prescriptive.
Kubernetes is not a panacea, and neither is systemd - I still recommend understanding and using both.
Also, please stop telling people that kubernetes is basically containers.