Kubernetes: the helmsman

Let’s talk a little bit about Kubernetes.

For those of you experienced in this area, you’re forgiven if your eyes gloss over a bit. You probably already know this stuff, and hey – please reach out on socials if you actually read through this and I got anything wrong.

So what is Kubernetes? At it’s most basic, it’s a workload scheduler.

Sidebar: so, what is a workload?

A workload is anything that requires compute resources for any length of time. A long running service and a short one-time job are both workloads. The only requirement is that the workload is containerized, that is, bundled into it’s own isolated environment (called an image) with all of the dependencies it needs. This containerization allows Kubernetes to schedule workloads without concern for conflicts; e.g. two different programs requiring different versions of the same library (which also happen to be different than the version installed on the host node). Because the container has all of the necessary dependencies, we (and Kubernetes) can be confident that the workload will run on any node it is scheduled on. There are, of course, exceptions… but that’s another show.

You give Kubernetes a bunch of computers (nodes, in Kubernetes terminology). Kubernetes introspects those nodes and gains an understanding of the available compute resources. Then, you tell Kubernetes you want to run a workload. It looks at the nodes, compares the available resources against the requests of the workload, picks a node for the workload to run on, and launches the workload on that node.

“Great!” you say, while thinking in the back of your mind that that’s not all that difficult and that you do the same thing all the time. And you’re not wrong.

The real magic comes in when you need to take one of those nodes down for some reason, or it just fails on its own like those pesky nodes are known to do. Rather than you needing to take that workload, get everything installed on a different node and relaunch it manually, Kubernetes takes care of all of this for you. It monitors the nodes and the workloads, detects if they become unavailable, and automatically reschedules or restarts them. If it’s a planned maintenance, it will even make sure another replica of the service is up and ready and shift the traffic to it before taking down the old one. Pretty neat, eh?

Of course, this only scratches the surface of what modern Kubernetes can do, but for our, er, purposes, it’s the reason Kubernetes exists.

You see, kids…

cue dream fade

Way back in the day, this little company called Google (you’ve heard of them, right?) was having trouble managing all of the different services that made their little search engine tick. Managing all of those services manually was a huge drain on manpower, and try as they might, Google’s plucky SRE team just could not keep with manually trying to make efficient use of hardware resources and keep services alive.

Then came Borg. Like its Star Trek namesake, Borg assimilated all workloads, generalizing them down to their requirements and adding each workload to its collective. In the end, Borg managed nearly all workloads at Google. Realizing both the value of the system and the value that could be gained by bringing outside contributors into the mix, Google worked with the Linux Foundation to create the Cloud Native Computing Foundation, with Kubernetes, a sanitized version of Borg, as the seed technology. The first public release of Kubernetes was in 2014, ten years ago.

Since then, Kubernetes has grown by leaps and bounds, in no small part to its infinite extensibility; anyone can create API which can be added to a Kubernetes cluster and used to define and manage customized workload behavior. Aside from the extensibilty, so much has been added to the core itself; storage, networking, stateless and stateful workload abstractions.

Kubernetes does not have a short learning curve, but it is easily the single most impactful technology in the past decade in regards to deploying and managing cloud workloads.

Hopefully this background in Kubernetes has been useful. I’ll dive deeper into how I’m using it in later posts.