K3s vs Kubernetes (kubeadm)

K3s is not a fork or a toy. It passes the same CNCF conformance tests as upstream Kubernetes. What Rancher's engineers did was remove things a small cluster never touches: legacy and alpha features that are off by default anyway, the old in-tree cloud provider code for AWS, GCP, and Azure, and the in-tree storage drivers those clouds needed. Then they wrapped the API server, controller manager, scheduler, and kubelet into one binary that runs as one process. The result is under 100 MB on disk, and a fresh single-node server idles around 500 to 600 MB of RAM instead of the 1 to 1.5 GB a kubeadm control plane with etcd burns before you deploy a single pod.

The clever part is the datastore. Instead of requiring etcd, K3s ships kine, a shim that translates etcd API calls to SQLite by default. On a single node this means no etcd cluster to feed, no quorum to worry about, and no watching etcd chew through your Raspberry Pi's SD card (etcd's write-heavy IO genuinely kills SD cards, the K3s docs warn about it directly). When you want a real 3-server HA cluster later, start the first node with --cluster-init and K3s runs embedded etcd for you, snapshots included via k3s etcd-snapshot save.

K3s also bundles the boring decisions: containerd as the runtime, Flannel for networking, CoreDNS, Traefik as ingress, ServiceLB so LoadBalancer services just work on bare metal, and local-path-provisioner so PersistentVolumeClaims bind without any storage setup. Every one of these is swappable. Do not like Traefik? Install with --disable traefik and drop in ingress-nginx. You get working defaults on day one and full control on day thirty.

kubeadm is the official bootstrapper, and it hides nothing. Before you even run kubeadm init you install a container runtime (containerd or CRI-O), disable swap, set kernel modules and sysctls, and install the kubeadm, kubelet, and kubectl packages on every node. Then init pulls the control plane images and launches kube-apiserver, kube-controller-manager, kube-scheduler, and etcd as separate static pods from /etc/kubernetes/manifests. Your cluster is still not functional at that point: nodes stay NotReady until you install a CNI plugin yourself. Budget 30 to 60 minutes the first time, and expect to troubleshoot at least one of swap, cgroups, or the CNI.

The ongoing cost is where kubeadm really diverges from K3s. Upgrades are a per-node ritual: kubeadm upgrade plan, upgrade apply on the control plane, then for each worker drain it, SSH in, upgrade kubeadm, run kubeadm upgrade node, upgrade kubelet and kubectl, restart, uncordon. One minor version at a time, no skipping. Certificates default to one-year validity, so a homelab cluster you ignore for 13 months greets you with x509 errors until you run kubeadm certs renew all and bounce the control plane. None of this is hard, but all of it is homework K3s does for you.

There is real educational value in that homework. Watching etcd fall over when it loses quorum, reading static pod manifests, and tracing why the scheduler will not place a pod teaches you how the machine works in a way K3s's single tidy process does not. The question is whether you want that lesson permanently attached to the cluster running your Jellyfin and Home Assistant. You do not.

The strongest case for kubeadm at home is career prep, so let us be precise about what transfers. Everything above the cluster bootstrap layer is identical: kubectl, Deployments, Services, Ingress, RBAC, NetworkPolicies, Helm, GitOps with Flux or Argo CD. If you run K3s for a year you are running real Kubernetes for a year, and that experience is legitimate on a resume. Nobody interviewing you for a platform role asks which installer laid down your API server.

What does not transfer from K3s: the kubeadm upgrade choreography, managing standalone etcd with etcdctl, static pod manifest debugging in /etc/kubernetes/manifests, and manual PKI work. Those show up in two places: shops that run self-managed clusters on bare metal or VMs, and the CKA exam. Most companies are on EKS, AKS, or GKE, where the control plane is the cloud provider's problem and your kubeadm knowledge sits unused anyway.

So the practical split is this: K3s as the permanent cluster that runs your actual services, and a disposable kubeadm cluster (three VMs on Proxmox, 2 vCPU and 4 GB each) that you build, break, upgrade, and delete when you are studying. Building that kubeadm cluster from scratch three or four times teaches you more than keeping it alive for a year would. If you are still deciding whether Kubernetes belongs in your homelab at all, our Kubernetes vs Docker Swarm comparison covers that fight.

Mostly yes, with specific gaps you must close. The CKA exam runs on kubeadm-built clusters tracking recent stable releases (v1.35/v1.36 territory in 2026), and roughly 80 percent of the tasks are pure kubectl and YAML work that behaves identically on K3s: troubleshooting workloads, RBAC, NetworkPolicies, Gateway API, storage objects, node maintenance. Daily driving K3s builds exactly the muscle memory those questions grade.

The gaps are the infrastructure tasks. The cluster upgrade question is one of the highest-point items on the exam and it is pure kubeadm procedure: upgrade plan, apply, drain, per-node kubelet upgrades, uncordon, verify. The etcd backup and restore task expects etcdctl snapshot save and restore against a standalone etcd static pod, with cert paths pulled from the manifest. K3s hides both flows behind its own commands (k3s etcd-snapshot, rerun-the-installer upgrades), so K3s-only experience leaves points on the table. Static pod behavior and /etc/kubernetes/manifests paths also differ.

The fix is cheap: two or three kubeadm VMs and a weekend of drills. Run the upgrade procedure until it takes you under 15 minutes, do etcdctl backup and restore five times, and you have covered everything K3s did not teach you. That is a far better trade than suffering kubeadm operations year-round for a handful of exam tasks.