I run about a dozen services at home: Pi-hole, a media server, some monitoring, a bit of home automation, the usual self-hosted suspects. For roughly a year I ran all of it on a Kubernetes cluster, and I am now slowly pulling most of it back off, so this is the postmortem.
The reasoning at the time was not completely daft. I work with Kubernetes professionally, and running it at home is the cheapest possible way to keep those skills warm. Break it at 9pm on a Tuesday with nothing on the line, learn the thing, carry the scars to work. That part genuinely paid off and I will defend it.
What did not pay off was using it as the actual platform for things my house relies on.
The problem with a cluster of one
Kubernetes is software for solving problems I do not have at home. It orchestrates many machines so that the failure of one does not matter, it schedules workloads across capacity I need to use efficiently, it lets a team deploy without stepping on each other. At home I have a handful of nodes, no team, and services where "it restarted and was down for ninety seconds" is completely acceptable. I bought a fleet of management for a problem the size of a postage stamp.
The cost showed up as a tax on everything. Standing up a new service was no longer "install it and edit a config file". It was a Deployment, a Service, an Ingress, a PersistentVolumeClaim, a ConfigMap, probably a Secret, and a small argument with the ingress controller about TLS. For a single-binary app that wanted a config file and a data directory, that is a lot of YAML to stand between me and a working Pi-hole.
And the failure modes were worse, not better. When the family-facing DNS goes down because a CrashLoopBackOff somewhere upstream wedged the cluster, you have not improved reliability, you have added a large, intricate dependency in front of a service that used to be a single process that just ran. The blast radius of "I am tinkering" went up, not down. I have had the "internet is broken" complaint from the rest of the house more times under Kubernetes than I ever did before it.
What it was actually good for
Two things, and I want to be fair about them.
The learning was real and transferable. There is no faster way to understand what an ingress controller actually does than to be the person who has to debug yours at midnight.
And declarative config, kept in git, was genuinely lovely. Knowing the entire state of my services lived in version control, that I could rebuild from nothing by applying a directory, that I could diff a change before making it: that is a good idea and I miss it already.
Where I landed
So I am not going back to a pile of hand-installed services and SSH-and-pray. The lesson is not "Kubernetes bad". It is that I reached for the heaviest possible tool for a job that wanted something an order of magnitude simpler. For the things the house depends on, I am moving to plain Docker Compose: declarative enough, in git, dramatically less to go wrong, and no orchestration layer between my DNS and my family. I will keep a small cluster running purely as a lab, deliberately holding nothing that anyone will miss when I inevitably break it. That, it turns out, was the only job it was ever the right tool for.