I ran Kubernetes at home for about a year and I've now torn most of it down, and I want to be clear up front that I don't regret either decision. Standing it up taught me things I genuinely use at work every week. Tearing it down taught me something quieter about matching the tool to the job, which is the bit I keep forgetting.
The setup was three small machines, kubeadm, MetalLB for load balancing because I had no cloud provider to hand me one, and a pile of YAML I was rather proud of. It worked. Things rescheduled when I unplugged a node to make a point to myself. I had ingress, I had persistent volumes, I had a little Prometheus watching it all. As a learning exercise it was superb, and if your reason for doing this is "I want to actually understand Kubernetes rather than nod along in meetings", I'd recommend it without hesitation. There is no substitute for having broken it yourself.
But for actually running the dozen small services I care about at home, it was the wrong tool, and the wrongness crept up on me. The control plane wants resources just to exist, before it's run a single thing I asked for. The failure modes are Kubernetes failure modes, which is to say abstract and several layers removed from the actual problem: a service is down, and the reason is a PersistentVolumeClaim stuck Pending because of a storage class detail, rather than anything to do with the service itself. At work, where a team carries that complexity together and the scale justifies it, that's a fair trade. At home, alone, at the weekend, it's a tax I was paying for capabilities I never used.
The honest test I should have applied sooner is this: do I have the problems Kubernetes solves? It solves scheduling across many machines, rolling deploys at scale, self-healing in a fleet, and declarative management of a large estate. My home has none of those problems. I have a dozen services that mostly sit still, on hardware that rarely fails, that I deploy by hand when I feel like it. I was using a fleet-management system to manage something that isn't a fleet.
So most of it is now plain Docker Compose on a single decent box, which is what the start of this little series was about. The few things that genuinely benefit from living across more than one machine, and there are one or two, I kept. But the YAML mountain is gone, and so is the low background hum of anxiety that came from knowing that when it broke I'd be debugging an orchestrator at midnight rather than a container.
The "(mostly)" in the title is doing real work. I'd do it again as a thing to learn, because the year of running it for real is exactly why I can now read a colleague's cluster problem and have a useful instinct about where to look. I just wouldn't do it again as a way to run my house. Learn the heavy tool on something that doesn't matter; run your actual life on the light one. Both halves of that sentence cost me a year to believe properly.