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

kubernetes at home was a mistake (mostly)

What I actually learned from running a small Kubernetes cluster at home, and why most of my homelab services no longer live on it.

A small server rack with networking gear

I run Kubernetes at work, so running it at home felt like a sensible way to keep the muscle memory warm and self-host a handful of services. A year in, I've moved most of those services off it, and I want to be fair about why, because the answer isn't "Kubernetes is bad". It's "Kubernetes is solving a problem I don't have at home".

What it's good at, and I don't need

The whole point of Kubernetes is fleet management. Reconciliation loops, declarative desired state, surviving node failures, rolling out across dozens of machines without a human in the loop. That's a real problem when you have a fleet and a team and an on-call rota. At home I have three mini PCs and exactly one operator, who is me, and who knows precisely which machine is sulking because I can hear its fan from here.

So I was paying the full operational cost of a distributed control plane to get benefits that assume a scale I will never reach in a cupboard.

A homelab shelf with cables and small machines

Where the time actually went

The running joke that you spend more time maintaining the cluster than the apps turned out to be true for me. A sample of the recurring tax:

  • Storage. Persistent volumes across nodes meant either a network storage layer or pinning pods to where the disk was, which quietly defeats half the point of having a scheduler.
  • Ingress and certificates. Getting an ingress controller, cert-manager and DNS to agree took longer than standing up the services behind them.
  • Upgrades. A control-plane version bump on a long weekend, with deprecated APIs to chase, is not how I want to spend a Saturday I could have spent on the router I bricked yesterday.
  • Debugging. When something breaks, you're now debugging your app and the platform underneath it, and the platform has far more moving parts than the app does.

None of these are Kubernetes failing. They're Kubernetes working exactly as designed, for a job that's larger than mine.

What I run now

Most things are back on plain Docker Compose, version-controlled, with a tiny bit of glue for backups and updates. It's legible. When something breaks I read one YAML file and I'm done. If I need it on another box I copy a directory. The reconciliation loop is me, and at this scale I'm faster than a controller and I sleep better.

The "mostly"

I kept a small single-node k3s install, deliberately. It's where I try Helm charts and operators before they go near anything at work, and it's a genuinely useful sandbox for exactly the thing it's bad at being in production at home: a place to break Kubernetes on purpose. That's the honest split. As a learning environment it earned its keep. As the way I host my own services, it was a beautifully engineered answer to a question I wasn't asking.