What I’ve learned about the dark art of Kubernetes

Kubernetes is having a moment. It’s one of those cool industry buzzwords that’s getting a lot of attention from developer-types for its supposedly magical properties. It’s also a tool that can be insanely difficult to understand “vendor-agnostic cluster, anyone?”, which pretty much guarantees more developers are saying it than using it right now.

But if you do want to dabble in magic, it’s always wise to know where the escape hatch is. That’s why Paul, one of our developers, recently took one for Team Fluent and decided to delve a little deeper into the dark art of Kubernetes. Here’s his refreshingly accessible take on all things Kubernetes (or K8s for all you uber-nerds out there).

What does Kubernetes do?

Kubernetes was designed by Google to overcome the problems traditionally associated with upgrading software in a system with lots of microservices running lots of separate pieces of software, which all talk to one another. Often just renaming a directory is enough for someone working on cloud-based Windows server to break the whole system.

But in the world of Kubernetes this wouldn’t happen - here’s why:

It defines the operating system

Kubernetes is a technology that puts a tiny virtual computer - and the software you want to run on it - in one package. Instead of saying “here’s a new version of my code”, it tells the cloud, “here’s an entire machine with my code on it”. All you need to do is plug it in and the system will run. And when it’s time to upgrade, you just chuck that computer away and get a new one.

Sometimes the problems you encounter during a release have nothing to do with the software - they’re related to the operating system. With Kubernetes you define the operating system within the plug itself, so you don’t have to worry about maintaining the system around it.

It manages multiple copies of software

Say you’ve got 100 copies of a piece of software that all need shutting down or upgrading. If just one of those copies has a fatal error and can’t continue, it can stop everything else from working too.

This is where Kubernetes cleverness comes in. Because it’s the bit that sits between your host machine and your docker containers, it knows how many versions of the software there should be. So, you can tell it there should be 100 copies of a piece of software and it will make sure the number stays at 100 by ‘poking’ each one every few seconds to see if it’s still alive. If one isn’t working - it will kill it off and start up another one. It's one less thing for your administrator to have to keep an eye on.

It deals with multiple requests

Identifying a request and delivering it to the right place (out of the hundreds being made) usually involves writing a new bit of software to manage the process each time. Kubernetes can group requests together and gives you a way of directing requests to the right place.

It has layers... and layers

Yes, Kubernetes is indeed clever and cool. But a word of caution about using it just because you’re working with lots of microservices. To use it properly requires a lot of unpacking of layers of resource types and conceptual jargon to understand the mental model.

Sure, you could skirt around the surface, type a command and find it works beautifully, but when it says “Cannot find a ready tiller pod” or “Back-off restarting failed container”, you’re going to need to know how the various bits of jargon are wired together to have any hope of working out how to fix it.

Should I use it?

The chances are most developers aren’t going to be using microservices anywhere near the scale of Google, so in some (most?) cases it’s probably a bit of overkill unless you like a challenge and are prepared to invest some serious time and energy on it. But if you are likely to face scaling and operational issues in a microservice world, then the engineers behind Kubernetes have probably solved your problems in a more robust and better-tested way than rolling your own. Just don’t expect a silver bullet without learning it for yourself.

Want more tips on digital product development from people at the cutting edge? Follow Fluent on LinkedIn and keep learning