I’ve recently been learning the fundamentals of kubernetes (hereby referred to as k8s) both for work and for building a home lab. I’ve no idea what shape the home lab will take; I’ve been bouncing back and forth between gradually building up a cluster of Raspberry Pis, and just buying some chunky servers to host virtual machines. It will require more thought.

For work, we host a platform internally and right now it is on Amazon’s Elastic Container Service (ECS) which can get very expensive, especially since we are using Fargate, which is their serverless container hosting offering (i.e. you don’t manage any servers).

We have an existing k8s cluster which is an absolute state, it was created with managed nodes, but has required some serious customisation. There’s two other team members who know about how it works, but they’re both out of work right now (bus factor = 2). Time to upskill.

Why I’m excited about K8s

I won’t be going over everything I’ve learned, that would take too long. I highly recommend Mischa van den Burg’s Kubernetes Masterclass course on Udemy: https://www.udemy.com/course/kubernetes-masterclass-for-beginners/

Not only does he provide a practical overview of the basics of Kubernetes, but he also provides tips to newcomers of the command-line for how to best navigate kubectl.

I’m excited for what k8s has to offer with regards to both DevOps and ownership.

DevOps

I’ll explain what I mean by this. I’m a huge fan of doing as few operational tasks as possible on your own bare-metal machine. This is especially true if you work as part of a team managing applications and (virtual) infrastructure.

The reason I will avoid it is simple: versions. There is no guarantee that the version of software you are using is the same as the one on your team member’s machine. Sure they may have the same version of OpenTofu, but there’s no guarantee they’ve not made some configuration change (that likely they’ve forgotten about) that changes their environment in a significant way compared to yours.

The only practical (and recommended) way to solve this issue is to run everything on a central configuration. This could be on a development VM that you remote into (which, sure but this is an archaic way of doing things), or by setting up automation to perform these tasks when you change the code on the server (through git).

This is all very abstract. Basically speaking, when you change code, you upload this code to a remote server, and that server performs all the tasks necesary to update applications and infrastructure to match your code.

This is where k8s comes to the rescue. Everything in k8s can be defined as code in a file. The code defines the desired state of the system, rather than a series of steps to get from A to B. The system is in state A, you want state B, you don’t have to tell it how to get there, k8s will figure that out and make the changes for you.

Ownership

OK I know you still don’t own the infrastructure underneath k8s, especially if you’re running it in something like AWS, but it gives you options.

With ECS, not only are you handing ownership of the infrastructure to Amazon, but you’re also locking in to a specific, non-transferable technology. You can’t easily lift and shift your applications to VSphere, Azure, or GCP. AWS is your only option.

When you use k8s, your cluster setup might differ between cloud providers or on-premises, but (as far as I understand) once you implement some key resources like networking, storage, and monitoring, you can effectively run your cluster the same no matter what platform you’re on. Your applications are deployed in the same way, and if you don’t like a cloud provider for any reason (like when AWS shut down access to all our accounts at once because of a billing issue no one was aware of), you can move elsewhere.

You own your options. You have leverage, and you can choose to own as much or as little of the whole as you want.

Additionally, it means your multi-cloud organisation and team can work together using the same language, rather than having to work across a myriad of different technologies with tonnes of different names that mean roughly the same thing except for some small significant differences.

What I’ll be using Kubernetes for

I’m a cyber security professional by trade. Specifically now I work as a threat intelligence engineer, a pretty niche area that is only now starting to mature. It’s also a much more agile environment that requires spinning up and testing new code and applications quickly and often. Then you need to move that code to production.

All this to say that it’s the perfect application for something like k8s.

Additionally, I want to set up a lot of applications in my home lab. Things like backup servers, CalDav, email infrastructure, my own security lab, monitoring and logging and everything else. Tonnes to explore and play around with.

Not only that, but previously, when I would run an application it would fail in some wa and I would be stuck with a broken server I had to log into in order to fix. K8s would allow my applications to self-heal (to an extent).

There’s much more and I’ll be slowly blogging and uploading my code for it to my GitHub: https://github.com/peritz.

Exciting days ahead.