My journey to Kubernetes happened quickly. When I was first getting back into writing code, the projects that I worked on were deeply, deeply lacking in code health. I was YOLOing keystrokes into .py files and hoping for the best. The code was stored only on my own computer. The script was only tested against production data.

But it mostly worked a lot of the time, so it seemed fine. And I was the only person writing the scripts or using them, so it was kind of okay. Until it wasn’t.

Keeping track of code

One of the first pain points I encountered was testing changes to my code. I would try to improve the script, and end up breaking things. Then I would forget what changes I made and spend hours trying to reconstruct something that worked at all.

This is where Version Control, specifically Git, came to save the day. Now, I could commit my changes and go back to the last version if something didn’t work without having to manage various copies and backups myself.

Running on a production-like system

Next, I realized that there were differences between my machine and the production servers. I didn’t have the same versions of Apache and PHP. Then I didn’t have the same versions of all the dependencies and plugins. It was a chore to try to keep everything in sync. And I was developing on Windows for a Linux production server, so it was never going to be a perfect match.

That’s when I learned about Vagrant. I could set up a VM that was much more like my production server. I only had to set up the base image once, then I could even spin up several development servers at the same time.

Making the environment reproducible

In addition to clumsily copying code back and forth between my desktop and a VM, those Vagrant images took up gigabytes of space and became difficult to work with. If I wanted to make a change to the environment, I had to make it in both places. When a coworker wanted to work on the same thing, it required another copy that could also get out of sync. Wouldn’t it be nice if there was something lighter and faster?

Enter Docker. Docker was taking the world of developers by storm around this time. It didn’t take me long to realize why. Suddenly, I could write code, build a Docker image in less than a minute, and see exactly how it would work. And if someone else wanted to see the same thing, they basically only needed Docker.

Scaling Up

Just doing a docker run was not a sustainable way of deploying code to production. Keeping track of what images were running was an issue, and so was coordinating what ports to expose. If the application crashed, there was not very good visibility. Many aspects of managing the running application left much convenience to be desired.

Luckily, Docker had a solution for these problems in Docker Compose. A flat file allowed launching multiple services at the same time. However, Docker Compose was basically limited to running on a single server. And it was a bit risky, because every time you made a change, you risked breaking something in a way that make take some time to recover. Plus, I only worked one place where they were bold enough to run Docker Compose for production services.

Finally, I learned about Kubernetes. Kubernetes built on all the previous principles and applied them over multiple servers. It introduced features like rolling updates, running multiple replicas of the same application, self-healing capabilities, traffic routing, and much more.

Criticisms of Kubernetes

The most common criticism I hear of Kubernetes is that it is too complex. And there is indeed a great deal of complexity. However, the basic concepts you need to get started can fit in a children’s book. Using Kubernetes has also proved to be an appropriately-leveled challenge for interns on our team to tackle in service of contributing to cloud-native applications. We’re past the days when you could know everything there is to know about Kubernetes. But that’s also true about Linux. The criticism that they are complex doesn’t make either piece of software less useful.

The other common sentiment is that, “you don’t need Kubernetes.” Most of these arguments also come back to complexity. I would argue that part of the value is that you can learn Kubernetes once, and then use it for projects big and small. You don’t have to learn a different method of launching applications every time.

Solved Problems

This is how I started running Kubernetes on my home lab (read: old computer where I self-host Immich). Once you have invested in learning to use Kubernetes, it’s incredibly useful to treat some aspects of deploying software as solved problems. I don’t have to come up with new any exciting ways to route traffic to the services that are running or deal with port conflicts. I don’t have to go in and restart nginx manually or renew certs on my own when they expire. I just do the thing I already know how to do and focus on the fun parts.

Perhaps most importantly, I use Kubernetes at work, so using it at home allows me to leverage what I have learned on the job to make my side projects easier, and get additional exposure at home to things that make me better at my job.

Do you need Kubernetes?

It depends. But if you’re trying to save effort by using the latest “easiest” application hosting trend (serverless, again?) and there’s a good chance you’ll end up on Kubernetes later…take the plunge. You probably do need Kubernetes.