The hater's guide to hating the hater's guide to Kubernetes

TL;DR: I found a “hater’s guide to Kubernetes” on the Internet, and disliked it so intensely for not being hater-y enough that I felt compelled to write about my feelings.

I recently stumbled upon “The hater’s guide to Kubernetes”, which starts out by telling the reader that the author themselves is guilty of taking “pithy jabs” at Kubernetes themselves - and that’s about the extent of “hate” Kubernetes receives for the entirety of the article. What follows instead is a detailed description on how and why they (or rather, their employer) is using Kubernetes, and how it’s good.

I can’t say why exactly, but this rubbed me the wrong way. If you call something a “hater’s guide”, please ensure that it’s actually that. With that said, I’d like to present to you what I’d call “the hater’s guide to hating the hater’s guide to Kubernetes”.

People often tend to forget, or ignore, where Kubernetes originated. It is inherently a product of work that started out as internal tooling for Google, specifically designed to scratch itches at Google. Which means that the at least some of the problems it was designed are ones that you (with the the utmost likelihood) don’t suffer from. That also means that to your problems it’s potentially a hammer where another tool would not just suffice, but be the better choice altogether. As an example, Kubernetes allows you to easily distribute your software over multiple nodes - but .. do you really need that?

Modern computers are pretty powerful, and most computers that you can rent on the Internet are surprisingly reliable. Yes, you’re going to be hard pressed to reliably achieve 100% uptime with your average hoster out there, but the 99.9x% of uptime most providers are willing to guarantee to you are usually enough. Especially if you’re just starting out.

Kubernetes also allows you to quickly build things from a pre-configured repository of settings / code. Yet, again, you don’t need Kubernetes for that. Be it configuration management with things like Puppet or Ansible, or containers that you fire up with docker-compose. Kubernetes doesn’t have a monopoly in that area.

But let’s assume you decided to go with Kubernetes. That means you just introduced an abstraction layer to your operations, which isn’t a bad thing per se. But since it’s a quite large, complex and complicated one, the overhead is going to be significant. Which leads a lot of companies to do what the author of the original hater’s guide says their employer is doing:

It’s also worth noting that we don’t administer Kubernetes ourselves — the main advantage of using Kubernetes is that we can outsource the infrastructure-level operation of it!

An abstraction layer that’s noticeably increasing monetary cost - yeah! According to the official price list, GKE (which, according to the article, is what they are using) sets you back six bucks per month, per virtual CPU. That gets expensive fast. Using a virtual server with 8 vCPUs, which isn’t unusual, means that you nearly 50$ per month on top of your regular hosting cost.

Initial investment into new software can absolutely cost money, especially when it makes your life easier. But an abstraction layer that introduces massive complexity in a situation where it’s quite often not warranted and continuously adds operating cost .. I really, really don’t know about that.

However, after being grumpy for the entirety of this post, let me be clear: I don’t actually hate Kubernetes, but any other word would have ruined my clever attempt at a title.

I can easily be convinced that there are situations, scenarios or setups where going with Kubernetes (or any of the other orchestration platforms, like Railway) makes perfect sense. But Kubernetes has a lot of issues, and potentially brings a lot of issues, while solving less issues than anticipated or solving issues that aren’t issues to begin with, or are issues that only popped up because of Kubernetes in the first place. Don’t (easily) do Kubernetes (without proper research and a thorough design process) kids.