Ramblings of an aging IT geek
← Ramblings of an aging IT geek
homelab

kubernetes at home was a mistake, mostly

I put a small Kubernetes cluster on my homelab to learn it, and learned mostly that I'd built a fragile way to run a handful of containers.

A small server rack with blinking lights

A few months back I decided the right way to learn Kubernetes was to run it at home, on real hardware, with real services I actually care about. The theory was sound: nothing teaches you a system like depending on it. The practice was that I turned "running about a dozen containers" into "operating a distributed control plane", and the second job is much bigger than the first.

This isn't a Kubernetes-is-bad post. At work, with a team and a reason, it's excellent. This is a homelab-of-one post, and the maths is different when you're the only operator and the workload is Plex, a couple of databases, some scrapers and a wiki.

Three mini PCs cabled together on a shelf

What I actually built was a three-node cluster on some mini PCs. kubeadm to bootstrap, flannel for networking, an NFS share for persistent volumes because I wasn't about to run Ceph at home as well. It worked. It genuinely worked, and the day a node died and the pods rescheduled themselves onto the survivors without me doing anything, I felt like a wizard.

The problem is everything in between those moments. etcd does not love a Raspberry-Pi-class disk, and it tells you so by going unhealthy at the worst times. A kubelet certificate quietly expired and took the cluster offline while I was on holiday, which is a special kind of homecoming. Upgrades between minor versions are not a thing you do casually with one cluster and no staging, and 1.4 only just landed so the upgrade story is still young. Every problem became a research project, and the research was about Kubernetes, not about the services I was supposedly hosting.

The honest accounting: I spent far more hours keeping the cluster alive than I ever spent on the apps running on it. That's fine if the cluster is the hobby. It's not fine if, like me, you mostly wanted your media server to come back up after a power cut without ceremony.

So I'm pulling back, mostly. The cluster stays as a deliberate lab, a place to break things and learn on purpose, with nothing on it I'd miss. The services I depend on are moving back to plain Docker on a single well-backed-up host with docker-compose and restart: unless-stopped, which restarts the lot after a reboot and asks nothing of me. Boring, legible, fixable at 2am.

The thing I actually learned is the thing I should have known: pick the smallest tool that solves the problem, then let the problem grow into bigger tools if it ever does. Mine never did. It was always a dozen containers. It just spent a summer pretending to be a cloud.