I put Kubernetes on my home network because I wanted to learn it for work, not because anything I run at home needs it. That distinction turns out to matter enormously, and it's the whole reason this post exists. As a learning exercise, mostly worth it. As infrastructure for half a dozen home services, a mistake, and I want to be specific about why rather than just sneering at complexity for sport.
The setup: three nodes, an old desktop and two NUCs, kubeadm to bootstrap, Flannel for the network, and a small pile of YAML. Getting it up was a weekend, which is honestly impressive for what it is. Then I moved my self-hosted bits onto it and started running it for real, and the gap between "it works in a demo" and "it works while I'm asleep" opened up underneath me.
what it actually cost
The thing nobody warns you about is that the cluster is itself a service that needs running. With Docker Compose, the failure modes are roughly: a container died, restart it. With Kubernetes, you've added an entire control plane that can be unhealthy in its own creative ways. etcd, the API server, the scheduler, the kubelet on each node, the overlay network. Every one of those is a new thing that can be the reason your media server is down, and several of them produce log output that assumes you already know what's wrong.
I had an afternoon where everything was unreachable and the answer was that a certificate the cluster issues itself had quietly expired and nothing renewed it. That is not a problem Compose can have, because Compose doesn't issue itself certificates. I'd added a whole category of failure in exchange for capabilities I wasn't using.
where it was actually good
I want to be fair, because there were genuine bright spots and they're the reason I'd hesitate to call it a total mistake.
Declarative state is lovely. A deployment YAML says "I want three of these, this image, this config", and the cluster makes that true and keeps it true. A node rebooted? The pods reschedule onto the survivors and the service stays up. The first time I pulled the plug on a NUC and watched everything just move, I understood the pitch in my gut rather than just on paper. That self-healing is real and it's the thing Compose genuinely cannot do.
spec:
replicas: 2
template:
spec:
containers:
- name: app
image: myapp:1.4
resources:
requests:
memory: "128Mi"
limits:
memory: "256Mi"
And the resource limits actually meant something. One greedy container could no longer eat the whole host and take everything else with it, which on a shared Compose box it absolutely could. That's a real operational improvement.
the verdict, with the "mostly" doing work
Here's the honest accounting. For learning, it was worth every hour. I now understand pods and services and the reconciliation loop and why the control plane is shaped the way it is, from running it badly and fixing it, which is the only way I ever actually learn anything. When I touch Kubernetes at work now, it's a tool I've bled on rather than a diagram. That value is hard to overstate and it's why the title says "mostly".
For running my house? No. A handful of stateless-ish services on three boxes I own do not need a distributed control plane, and they certainly don't need me to be its on-call engineer. The self-healing is nice but my services don't have the uptime requirement that justifies it, and the new failure modes cost me more sleep than the old ones ever did. I've since moved the actual workloads back to Docker Compose, which does everything I need with a fraction of the moving parts, and I keep a single-node cluster around purely to keep learning on.
That's the shape of it. Kubernetes solves a real problem I do not have at home, and creates several smaller problems I definitely do. As tuition it was excellent. As infrastructure for six containers it was, mostly, a mistake, and the most useful thing I got from it was the clarity to say so.