What Actually Changes When You Move from Docker to Kubernetes at Home
A look at what gets easier, what gets harder, and what surprised me the most
If you have been running Docker for a while in your home lab, there is a good chance you have at least thought about Kubernetes. Maybe you have heard that it is the “next step” or that everything is moving in that direction. This has been something I wanted to do for a while, make Kubernetes my main platform for hosting containers. I have always had a K8s cluster “sitting in the corner” but has always been more of a toy. My Docker setup was working, but I kept wondering if I was missing out on something by not making the jump. So I did what most of us eventually do. I migrated.
What I expected was a cleaner, more powerful way to run my containers. What I actually got was a mix of real benefits, new complexity, and a few things I did not anticipate at all.
One of the first things that stood out is how different the mental model is. With Docker, especially Docker Compose or Swarm, you are thinking in terms of services and containers. It is very direct. You define what you want and it runs. Kubernetes shifts that thinking into a more declarative model. You describe the desired state and the system works to maintain it.
That sounds great on paper, but it does take time to adjust to. Simple things like exposing a service or persisting data are no longer just a few lines in a Compose file. You are dealing with deployments, services, ingress, persistent volume claims, and sometimes storage classes depending on your setup. That said, once things are running, Kubernetes does shine in a few key areas.
Resiliency is one of the biggest. If a container dies in Docker, you can restart it or rely on restart policies. In Kubernetes, self-healing is built in at a deeper level. Pods are recreated automatically, and workloads can move between nodes without much effort once you have things configured correctly.
Scaling is another area where Kubernetes starts to make more sense. Even in a home lab, being able to scale replicas up or down with a single command or configuration change feels powerful. It also changes how you think about workloads. Instead of treating services as static, you start thinking about them as something that can expand or contract as needed.
Where things got interesting for me was storage and networking. Moving from traditional Docker volumes to something like Ceph-backed persistent storage in Kubernetes was not as simple as just pointing to a path. You have to understand how your storage backend integrates with Kubernetes, how persistent volumes are provisioned, and how your applications expect to access that storage.
Networking also becomes more abstract. Instead of directly mapping ports, you are working through services and ingress controllers. It is more flexible, but also another layer to understand and troubleshoot when something is not working. I think if you are running Docker Swarm or moving that direction, it helps you to “get your feet wet” with Kubernetes.
The biggest surprise overall was not that Kubernetes is more complex. That part is obvious. The real surprise was how much it changed how I think about running applications in my home lab. It pushed me toward more automation, more consistency, and better separation between infrastructure and workloads.
At the same time, it made me appreciate how simple and effective Docker can be for many use cases. Not everything needs Kubernetes, especially in a smaller environment.
If you are considering making the jump, or you are in the middle of it and wondering if your experience is normal, I go much deeper into what worked, what did not, and how I approached the transition in my full write up here: https://www.virtualizationhowto.com/2026/04/i-replaced-docker-with-kubernetes-in-my-home-lab-and-it-wasnt-what-i-expected/