2026-06-25 | kubernetes

K3s vs K8s: Why the Home Lab Keeps Choosing the Underdog

Another week, another blog post explaining that K3s is “lightweight Kubernetes.” This one, from KodeKloud, at least gets to the point: the difference isn’t the API or the kubectl experience. It’s the control plane tax, and home lab operators feel that tax every time they provision another VM.

KodeKloud’s piece cuts through the marketing. They frame K3s as a CNCF-certified, single-binary distro built for IoT, edge, and resource-constrained environments. The key distinction they highlight is architectural: K3s runs control plane components in a single process, uses SQLite instead of etcd by default, and ships with a stripped-down set of operators that actually matter for small clusters. Meanwhile, upstream Kubernetes assumes you want HA etcd, dedicated control planes, and enough RAM to run a small bakery. The article recommends K3s for IoT devices, CI/CD pipelines, and development clusters, while reserving full K8s for massive multi-tenant workloads. Nothing shocking, but it’s refreshing to see a mainstream training site admit that “full fat” Kubernetes is often overkill.

SQLite Is Not a Dirty Word

KodeKloud notes K3s defaults to SQLite for single-node setups. Most home labbers hear “SQLite” and panic, thinking they need etcd because that’s what the CKA course taught. Nonsense. For my three-node K3s cluster on Proxmox, SQLite handles the state just fine until I need HA. When I do flip to embedded etcd, the migration is one flag:

curl -sfL https://get.k3s.io | K3S_TOKEN=<secret> sh -s - server \
  --cluster-init \
  --tls-san 192.168.1.50

Don’t run etcd on an SD card. The KodeKloud article hints at IoT use cases; if you’re deploying on a Raspberry Pi, stick with SQLite or use an external data store on real storage. I learned that after chewing through three SanDisk Ultras in six months.

Measure Your Control Plane Tax

The KodeKloud breakdown estimates K3s at ~512MB RAM for a node. My Proxmox dashboard shows my K3s server LXC idling at 780MB with Prometheus, Loki, and Grafana agents running inside. Compare that to the 2GB+ just for a kubeadm control plane before you schedule a single pod. The actionable part: audit your actual resource burn. If you’re running a home lab on a NUC or a refurbished OptiPlex, those gigabytes matter. I keep a Grafana panel tracking container_memory_working_set_bytes for the k3s process. When it trends up, I know it’s time to evict a side project, not buy more hardware.

Use the Right Metal (or Virtual Metal)

KodeKloud pushes K3s for IoT. I push it for Proxmox LXCs and Talos VMs. The distinction isn’t just resource size; it’s maintenance surface. A standard K8s cluster needs OS-level tuning for kubelet, containerd, and a dozen systemd units. K3s wraps the container runtime and networking into one binary. On Talos, that’s redundant. On an Ubuntu LXC, it’s a lifesaver. My current setup:

  • Proxmox host: Dell OptiPlex 7080, 64GB RAM
  • K3s server LXC: 4 vCPU, 4GB RAM, Ubuntu 22.04
  • K3s agent VMs: 2 vCPU, 2GB RAM each

If I were running kubeadm, I’d need at least two more GBs on the control plane node. That’s a whole extra LXC I don’t have to back up.

Have an Escape Hatch

The KodeKloud article doesn’t cover this, but it should. K3s is easy to install and easy to destroy. That’s a feature until you have persistent workloads. I automate cluster rebuilds with Ansible, but I also test them. Monthly, I nuke a worker node and rejoin it to the cluster. The playbook:

- name: Drain and delete k3s node
  kubernetes.core.k8s_drain:
    name: "{{ inventory_hostname }}"
    state: absent
    delete_options:
      ignore_daemonsets: true

If you can’t rebuild your cluster in under thirty minutes, you’re not running a home lab. You’re running a pet. K3s makes that rebuild cheap enough that I actually practice it.

When to Actually Use Upstream K8s

I’ll say it: I don’t run upstream K8s at home. I don’t need Pod Security Standards enforced by twenty admission controllers. I don’t need to schedule ten thousand pods. The KodeKloud piece is correct that full Kubernetes wins when you have dedicated platform teams, multi-tenancy, and custom scheduler profiles. For the rest of us, K3s is the production-grade choice. If I ever need something K3s can’t do, I’ll deploy a dedicated Kubeadm cluster on its own Proxmox node and peer them with Cilium. That day hasn’t come in three years.

I’m keeping my K3s cluster on SQLite for now. The embedded etcd experiment is on the backlog for when I add a fourth node, but I’m in no rush. What I am changing is the monitoring: I’m adding a Loki alert for K3s certificate expiration, because the single-binary model means cert-manager isn’t running by default and it’s easy to forget. The cluster rebuilds fine, but TLS warnings at 2 AM are still annoying. That playbook is next weekend’s problem.

tags:
← Back to blog