I put Kubernetes in my house. For about a year it ran a grand total of maybe a dozen containers: a few web services, a couple of databases, the usual self-hosted suspects. To do that job, a job a single machine running Docker Compose would have done while barely waking up, I built and maintained a small cluster, and I learned an enormous amount, and I would mostly not recommend it.
Let me be fair to it first, because the honest version of this post isn't "Kubernetes bad". Kubernetes is genuinely excellent at the thing it's for. The problem is that the thing it's for is not, usually, hosting a dozen containers in your spare room.
what it cost
The headline cost is complexity, and it compounds. To run a container under Compose you write a stanza, you run docker-compose up, the container starts. To run a container under Kubernetes you write a Deployment, which references a Pod template, which you expose with a Service, which you reach through an Ingress, which needs an ingress controller, which you probably want behind cert-manager so it can do TLS, which needs its own CRDs and a working cluster issuer, and storage is its own adventure involving PersistentVolumes and PersistentVolumeClaims and a provisioner that actually understands your disks.
Every one of those layers is reasonable on its own. Together, for a homelab, they're a lot of moving parts standing between you and "the website is up". And each part has its own failure modes, its own version skew, its own way of being subtly broken in a manner that produces an event log full of things that are technically warnings.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
web-7d4f8c9b6d-x2k9p 0/1 CrashLoopBackOff 14 52m
CrashLoopBackOff. The two words that defined a meaningful fraction of my year. The container won't start, Kubernetes restarts it, it won't start, Kubernetes waits a bit longer and restarts it again, and you go digging through kubectl describe and kubectl logs --previous to find out that it's a permissions problem on a mounted volume, or an environment variable you set in the wrong of the four places you can set environment variables.
The other real cost is upgrades. A managed cluster in a cloud, somebody else worries about upgrading the control plane. At home, that's you. Kubernetes moves fast and deprecates APIs with the brisk confidence of a project that assumes you have a platform team. A homelab does not have a platform team. A homelab has one tired person and a weekend, and the manifests that worked three versions ago now warn that extensions/v1beta1 is going away and you should really sort that out.
where it was actually worth it
So why did I keep it for a year, and why am I not telling you to never do this? Two reasons, and they're the honest ones.
First, the learning was real and it transferred. The whole reason I did this was that I work with this stuff, and there is no substitute for running it badly in an environment where breaking it costs nothing. Every painful afternoon spent understanding why a Pod couldn't reach a Service taught me something I later used in anger at work, where the same confusion would have cost a great deal more than a Sunday. As a deliberately-built learning rig, the homelab cluster was worth every hour. That's a completely different justification from "it's a good way to host my services", and I think conflating the two is where a lot of people go wrong.
Second, there was exactly one workload where the platform earned its keep on its merits: the thing that genuinely benefited from being rescheduled when a node died. I had services I cared about staying up across a host reboot or a failed disk, and Kubernetes does that part beautifully. If a node went away, the Pods came back elsewhere, by themselves, while I was asleep. For that handful of workloads, the self-healing was real value, not just resume-driven complexity.
what I'd tell you to do instead
If your honest goal is to host your stuff reliably, with the least time spent on the infrastructure rather than the services, then for most homelabs the answer is duller and better:
- Docker Compose on one box. It does what you need, you can read the whole config on one screen, and when it breaks the failure is usually right in front of you. Add a sensible backup of the volumes and you're done.
- If you want resilience across hosts, look at something lighter than full Kubernetes before reaching for it. The lightweight distributions had started appearing by 2018 and they remove a lot of the operational weight whilst keeping the bits you actually wanted.
- If your real goal is to learn Kubernetes, then by all means run Kubernetes, but be honest that that's the goal. Build it knowing the cluster is the project and the services are just an excuse, and you'll have a much better time than the person who only wanted their stuff hosted and accidentally signed up to run a platform.
- Whatever you run, back up the data first and worry about the orchestrator second. The thing that actually matters in a homelab is your data, not the clever scheduler in front of it. I have lost a cluster and shrugged. I would not have shrugged about the databases. Get a boring, tested backup of your volumes working before you spend a single evening on the platform around them.
I took mine apart in the end, mostly. The services that just needed to be up moved back to a single machine and a Compose file, and they've been quietly boring ever since, which is the highest praise I have for self-hosted infrastructure. I kept a small cluster around purely to keep learning on, clearly labelled in my own head as a toy rather than a tool. That separation is the whole lesson, really. Kubernetes at home wasn't a mistake because Kubernetes is bad. It was a mistake because I asked it to be a hosting solution when what I'd actually built was a very elaborate, very educational, occasionally infuriating way to keep a dozen containers running. For the right reason it's a joy. For the wrong reason it's a second job you didn't apply for.