Did you know that you can run a Kubernetes cluster on a single regular PC? Yes, not just one node but a cluster of two or more nodes. Of course, this has to be done with a bunch of virtual machines and, built properly, can be an interesting setup for a homelab system where you can practice your K8s skills. Now, guess what? That's exactly what I did and, even better, made a guide series where I detailed the whole process!
About the guide series
My guide series is titled "Small homelab K8s cluster on Proxmox VE", it's all written in Markdown format and you can find it as a project on GitHub (link at the end of this article). There are in total fifty-seven guides in the series and cover a lot of ground together. In this and the following articles, I'll give you a bird's eye view of what's inside of each guide, while also explaining some things I didn't said (not explicitly at least) in them.
Chapter 01. A host is rising
The very first thing you need to solve is the host question. This machine is going to be the foundation of your whole setup, so what's the minimum hardware you need? What operative system or platform you have to deploy? How you have to configure the whole thing? Worry not, because this is just what I cover in the first sixteen guides.
G001 - Hardware setup
In the first guide of the series, I detail what hardware I've used to host the whole setup. You'll see that it's a rather humble and cheap one, but with important aspects that must be highlighted:
- The CPU has virtualization capabilities: this is a rather obvious must to run virtual machines!
- It has 8 GB of RAM: less would be too tight for all the software you'll deploy with the guides.
- It has an SSD: this is key, even mandatory nowadays, to achieve good performance with the cluster, especially in a regular PC.
- It has a decent storage space: you don't really need a huge storage for all that's deployed in the guide, at least not for just practicing with Kubernetes. But still, you'll need some good space for all the things you'll install or deploy.
- It has a UPS unit: it's always a good idea to have a UPS protecting your computers but, of course, not really necessary for practicing Kubernetes.
Depending on what your hardware has or has not, you'll have to adapt to your system (or just skip) what I explain in the following guides. On the other hand, if you happen to have a powerful enough system (such as a gaming rig, for instance), you could just run everything within a virtual machine that replicates the hardware configuration of the system used in the guides. But, if you go down this path, remember that you'll need to enable the virtualization capacity to the virtual machine you use.
G002 - Proxmox VE installation
This is a straightforward guide, in which I explain the requirements and installation procedure of Proxmox VE. Know that, although this guide was done with a 7.0-z version of Proxmox VE, is still valid for the 7.1-z and 7.2-z releases at least.
Host configuration
The next four guides are all about doing an initial configuration of the newly installed Proxmox VE system.
G003 - Host configuration 01 ~ Apt sources, updates and extra tools
Proxmox VE is a customized Debian system, and you'll need to update it right after you install it. The problem is that you have to change its default apt repository configuration since it comes with the Enterprise repository enabled by default. Unless you already have a license for that edition of Proxmox VE, you'll need to switch to the free No-Subscription repository. But not only do I cover this particular update process in this guide, but I also tell you about some extra tools you'll like to have in your system to help you in your administration and monitoring tasks.
G004 - Host configuration 02 ~ UPS management with NUT
If you don't have a UPS unit, you can safely skip this guide. But, if you do have a UPS, I think you'll find it rather interesting. This guide shows you how to use the NUT software to connect and (up to a point) manage a UPS unit directly connected to your host system.
G005 - Host configuration 03 ~ LVM storage
This guide is all about enabling Proxmox VE all the free space available in the storage drives. This implies organizing that space, something I've done here using the venerable but still effective LVM system. Again, if you have a different hardware configuration, you'll have to adapt or omit certain steps explained in this guide.
G006 - Host configuration 04 ~ Removing subscription warning
The Proxmox VE system shows a warning about not having a license, and for some, this can be a nuisance. There's a way to disable this warning, which I explain in this guide, although when certain core Proxmox VE package gets updated, the warning is restored. So you may very well skip this short guide altogether if you're not bothered by the warning anyway.
Host hardening
Usually, no newly installed system comes configured in a secure manner, and a recent deployment of Proxmox VE certainly is no exception. In the next eight guides, I explain to you several things you can do to harden your Proxmox VE setup. Of course, I'm not claiming this will make your system immune to any attack or anything like that, there's no such a thing in this world, but surely it will reduce your chances of having a security incident.
G007 - Host hardening 01 ~ TFA authentication
I was kind of surprised when I discovered that you could apply TFA authentication to shell or SSH logins on Linux. It's not hard to configure, but kind of an obscure procedure based on a Google authentication library and command for Linux. In the guide, I detail how to do this configuration, and also cover how to enable TFA on Proxmox VE.
G008 - Host hardening 02 ~ Alternative administrator user
The less you use the root user, the better. In Linux systems like Debian, it's always better to use an alternative administrator user that has sudo powers. An important detail here is that you also need to give it administrative powers on the Proxmox VE side. With this guide, you'll see how to create such a user properly.
G009 - Host hardening 03 ~ SSH key pairs and sshd service configuration
The default configuration of the sshd service running in the Proxmox VE system is not the safest one possible. This guide is about making it much more restrictive, in such a way that only users of a certain Linux group can access it through SSH. It also shows you how to generate very strong SSH RSA key pairs, although you could also generate keys with the more modern algorithm Ed25519 (as shown in this security stackexchange answer).
G010 - Host hardening 04 ~ Enabling Fail2Ban
To protect your system from brute-force attacks, there's the Fail2Ban system. It can restrict the number of failed login attempts allowed on a service, and apply a temporary ban on the IPs that go over that number of attempts. It does the trick by monitoring the services logs, and looking for a certain pattern. When Fail2Ban detects the pattern, it applies the ban on the IP in the system's firewall. In this guide, you'll see how to configure Fail2Ban to protect both your SSH service and the Proxmox VE web console.
G011 - Host hardening 05 ~ Proxmox VE services
The Proxmox VE platform uses its own collection of services to do its things, such as running virtual machines or keeping up the virtual networking among them. But in a small setup such as the one built in this guide series, some of those services can be disabled. By doing so, you not only save a bit of your RAM and CPU, you're also reducing the attack surface on your system. Hence, this guide helps you in identifying and disabling those unneeded services on your Proxmox VE server.
G012 - Host hardening 06 ~ Network hardening with sysctl
Another default configuration that you want to adjust is the one about your host's networking. This is set as sysctl values, and my corresponding guide tells you what attributes to touch and how to enable them properly. The highlight here is that you'll see how to disable the IPv6 networking altogether, apart from tuning other network-related values.
G013 - Host hardening 07 ~ Mitigating CPU vulnerabilities
As you surely know by now, is not just software that comes with vulnerabilities but also hardware. In particular, CPUs like the ones in your host. To mitigate its vulnerabilities, on Linux you have packages prepared for certain architectures. In this guide, you'll see how to identify the vulnerabilities and apply the corresponding package for patching them.
If you are running the Proxmox VE setup inside a virtual machine, you don't need to apply this mitigation. The virtualization engine won't allow the patch to act on the real CPU of your system.
G014 - Host hardening 08 ~ Firewalling
Proxmox VE comes with a firewall that is based on the legacy iptables system. This shouldn't bother you much since, for the most part, you'll use the web console to manage your firewall rules. Still, this guide will give you not only an insight on how to run the Proxmox VE firewall but also how to configure other firewalling aspects that you cannot manage from the Proxmox VE web console.
Host optimization
After applying all the previous guides, you get a configured and hardened Proxmox VE host system. This is fine and you could start using it right away, but you can still optimize it further. Check the following two guides to do so.
G015 - Host optimization 01 ~ Adjustments through sysctl
There are a number of sysctl parameters that you can tune to improve the performance of your Proxmox VE setup. In this guide, I show you certain parameters related to networking, memory and kernel concerns. Bear in mind that some of the values presented in the guide might not fit your system, so you should take care of understanding what each of them does and adjust them accordingly to your own circumstances.
G016 - Host optimization 02 ~ Disabling transparent hugepages
At face value, it might seem that transparent hugepages are a good idea but, for servers in particular, they can hurt performance. It's much better, and safer, to completely disable them in your host. This is a really short procedure that doesn't take long to perform.
In the next chapter
With the foundation well established, you can build your Kubernetes cluster in your Proxmox VE system. This implies creating Debian virtual machines, configuring and hardening each of them in a very similar way as with the Proxmox VE system and, finally, installing a lightweight Kubernetes distribution on those VMs. That distribution is Rancher's K3s and no, you won’t do the usual default example installation. Discover how I built this small K3s cluster is in my second article!