I spent a long weekend standing up Kubernetes on the homelab, and a fortnight later I tore most of it down. Not because it didn't work. It worked fine. It just turned out I'd built a cargo terminal to move three boxes across the room.
The pitch I'd sold myself was reasonable on paper. I run a handful of services at home, Plex, a couple of bits of monitoring, the usual sprawl, and they'd accreted as a heap of docker run commands and one increasingly load-bearing docker-compose.yml. Self-healing, declarative config, rolling updates: all the things I do at work and quite enjoy. Why not here?
Because the overhead is the whole thing, that's why. A single node kubeadm cluster spends a meaningful slice of a small machine just being Kubernetes: etcd, the API server, the kubelet, all humming away to schedule workloads onto the one place they could possibly go. When something broke it was never the app, it was an expired certificate, or DNS inside the cluster, or a CNI plugin sulking after a reboot. I was on first-name terms with kubectl describe for problems that compose never had.
The honest comparison is that compose already gave me ninety per cent of what I actually wanted: containers defined in a file, brought up with one command, restarted on failure. The remaining ten per cent, rolling deploys and proper scheduling, I do not need on a network where the only consumer downstream is me, and I'm usually the one who broke it.
So it's mostly gone. I kept the cluster on one node as a deliberate learning rig, somewhere to break things that mirror work, and that's genuinely useful. Everything I rely on day to day went back to compose. The lesson wasn't that Kubernetes is bad. It's that the homelab is for running services, not for running Kubernetes, and I'd quietly swapped the two.