What Kubernetes actually buys you that Compose doesn’t

Compose runs containers according to a file you wrote, on the host you ran it on. If that host goes down, your containers go down with it, full stop. Kubernetes is built around a different premise: you describe a desired state (how many replicas of this app, what resources it needs, what it should be reachable on) and a control plane continuously works to make the cluster match that description, across however many nodes you give it. If a node dies, workloads that were on it get rescheduled onto surviving nodes automatically. That’s the actual feature, self-healing scheduling across a pool of machines, and it’s the one Compose fundamentally cannot do because Compose has no concept of “a pool of machines” at all.

Everything else people associate with Kubernetes, rolling updates, health checks, horizontal scaling, service discovery, is either something Compose can approximate with enough Docker Swarm-lite tooling, or something that only matters once you have more than one node to spread load across. If you’re running everything on a single Proxmox host or mini PC, the self-healing-across-nodes feature has nothing to heal onto. You’re paying the full operational cost of Kubernetes to use roughly none of what makes it worth that cost.

The three distros that actually make sense at home

Full upstream Kubernetes (via kubeadm) is not what anyone should run in a homelab. It assumes a team of people maintaining etcd, a cloud provider’s load balancer integration, and infrastructure that updates itself through a CI/CD pipeline you don’t have. The homelab-sized options strip that down considerably.

k3s is the one you’ll see recommended most often, built by Rancher (now SUSE) specifically for resource-constrained and edge environments. It ships as a single binary, replaces etcd with embedded SQLite by default (or real etcd if you want multi-master HA), and bundles a lightweight ingress controller (Traefik) and local-path storage provisioner so a fresh cluster is actually usable for something within minutes of installing it, not just running. It’s genuinely light enough for a Raspberry Pi, and it’s the distro with the biggest homelab community, which matters more than it sounds like when something breaks at 11pm and you’re searching for the error message.

k0s takes a similar “single binary, batteries included” approach but is more deliberately minimal and unopinionated about what runs on top, it doesn’t bundle Traefik the way k3s does, leaving ingress and CNI choices more explicitly up to you. It’s a reasonable pick if you specifically want to avoid k3s’s opinions about what belongs in a base install, but the tradeoff is a smaller community and fewer homelab-specific guides when something doesn’t work the way the docs implied.

MicroK8s, from Canonical, is the most “appliance-like” of the three, installed via snap, with a plugin system (microk8s enable dns, microk8s enable ingress) that turns optional components on and off without hand-editing manifests. It’s a comfortable fit if you’re already running Ubuntu everywhere and like snap’s model, and a genuine friction point if you’re not, since it pulls snapd in as a hard dependency and that doesn’t sit well on every distro or inside every container runtime.

For a first homelab Kubernetes cluster, k3s is the default recommendation almost everyone converges on, and for good reason: it has the most documentation, the most Helm charts tested specifically against it, and the smallest number of “why doesn’t this work like the tutorial said” surprises. k0s and MicroK8s both have real niches, but they’re niches you reach for once you know specifically why k3s’s defaults don’t fit, not a first stop.

Where to actually run it

On Proxmox, the practical choice is VMs, not LXCs. Running a container orchestrator inside a container host works, people do it, but it means fighting the same cgroup and nesting friction covered in the LXC-vs-VM decision elsewhere on this site, and a Kubernetes node crashing into unrelated host-level issues is a worse debugging session than a VM crashing cleanly on its own. A handful of small VMs (2-4GB RAM each is plenty for k3s agents) spread across your Proxmox host or hosts gives you the multi-node setup that’s the entire point of running Kubernetes in the first place. If you only have one physical host, you can still run several VMs on it for a multi-node cluster, you just lose the “survives a hardware failure” benefit since one host failure takes all the VMs with it, but you keep the scheduling and self-healing behavior for software-level failures like a crashed pod or a hung node.

Storage is the part that trips people up first. k3s’s bundled local-path provisioner only gives you node-local storage, fine for stateless workloads, a real problem for anything with a database that needs to survive its pod moving to a different node. The two realistic options are Longhorn (distributed block storage built for Kubernetes, replicates volumes across nodes, but wants real CPU and network headroom to do it well) or just pointing stateful workloads at an existing NFS share from your NAS and accepting that storage lives outside the cluster’s self-healing story entirely. For a homelab-scale cluster, NFS-backed persistent volumes for anything stateful, with Longhorn reserved for the rare case where you specifically need storage that survives a node going away too, is the less painful default.

Networking-wise, MetalLB is the piece that’s easy to forget you need. Kubernetes LoadBalancer-type services assume a cloud provider will hand out a real external IP, which obviously doesn’t exist at home. MetalLB fills that gap by claiming addresses out of a range you give it on your LAN, so kubectl get svc actually shows you a usable IP instead of sitting at <pending> forever. k3s’s bundled Traefik ingress still needs something like MetalLB underneath it to get a real LAN-reachable address in the first place.

What it’s actually good for at home

The honest list of homelab use cases where Kubernetes earns its keep is shorter than the hype suggests, but it’s real:

Learning for work, full stop, legitimate on its own. If your job involves Kubernetes or you’re trying to get a job that does, running a real cluster at home where you can break things without a pager going off is worth the complexity by itself, no further justification needed.

Genuinely redundant self-hosting across multiple physical hosts, where you specifically want a service to keep running if one box dies, not just restart on the box that’s still up (that part Docker Compose plus a restart policy already does fine on a single host).

GitOps workflows, where you want your entire homelab’s app state defined declaratively in a git repo and reconciled automatically (ArgoCD or Flux are the common picks on top of k3s), which is a meaningfully different operating model from SSHing in and running docker compose pull && up -d by hand or through a UI.

What it’s not particularly good for: running the handful of apps most people start a homelab with. Pi-hole, Jellyfin, a reverse proxy, Vaultwarden, Nextcloud, these are all single-instance apps that don’t benefit from horizontal scaling and whose availability story is “restart it if it crashes,” which restart: unless-stopped in a compose file already covers. Wrapping them in Kubernetes adds YAML, adds a control plane to keep patched and running, and adds an entirely new category of thing that can break (the cluster itself), in exchange for scheduling flexibility you have no actual use for on one or two hosts.

The real cost nobody mentions upfront

Even k3s’s “lightweight” framing undersells the ongoing maintenance. A Kubernetes cluster is a live system with its own upgrade cadence, independent of whatever’s running inside it, and version skew between control plane and workloads is a real failure mode if you let a cluster sit unpatched for too long. You’re also debugging a different stack when something goes wrong: instead of docker logs and docker inspect, it’s kubectl describe pod, kubectl logs, checking whether it’s a scheduling problem, a networking problem, or a storage problem, each with its own command and its own learning curve. None of that is a reason to avoid Kubernetes if you want to learn it. It is a reason to be honest that “it’s just a lightweight distro, how hard can it be” undersells what you’re actually taking on.

Bottom line

If you’re running a handful of apps on one or two homelab hosts and nothing about your setup needs scheduling across machines, Docker Compose (optionally with Portainer or Dockge on top) is not a lesser choice, it’s the correctly-sized one, and adding Kubernetes on top buys you a second system to maintain for capabilities you won’t use. If you want to learn Kubernetes for real reasons, work, a genuinely multi-host resilient setup, or a GitOps-driven homelab, k3s is the right place to start: smallest footprint, biggest community, fewest surprises. k0s and MicroK8s are both fine choices once you know specifically why k3s’s defaults don’t fit what you’re building, not a reason to skip k3s on a first attempt.