k0s vs k3s vs RKE2: Which Lightweight Kubernetes in 2026?

All three of these call themselves lightweight Kubernetes. All three pass the CNCF conformance tests, ship as a single binary, and install with one curl command. So on paper they're interchangeable, and that's exactly why picking one is confusing.

They aren't interchangeable. Each one makes a different bet about who you are, and those bets live in the defaults: which datastore, which network plugin, whether an ingress controller shows up uninvited, and whether your control plane runs your workloads. Get the defaults wrong for your situation and you spend a weekend undoing them.

Here's how they actually differ, checked against each project's docs and release feeds as of mid-September 2026.

The Short Version

• k3s if you want everything working in five minutes on one small box: homelab, edge device, dev cluster, small team.
• RKE2 if someone will ask you about compliance: FIPS, CIS benchmarks, SELinux, regulated environments.
• k0s if you want a clean upstream-style cluster with nothing opinionated bolted on and a control plane kept apart from your workloads.

Side by Side

Look at that version row first. Kubernetes 1.37 shipped on August 26. k3s and RKE2 both released 1.37 on September 14. k0s is still on 1.36, which matches its stated release policy: it builds from the official upstream release and deliberately lands a few weeks behind. Neither approach is wrong, but if you want new Kubernetes features the week they ship, that gap matters.

k3s: Batteries Included

k3s assumes you want a working cluster immediately and would rather remove things than assemble them. Out of the box you get SQLite as the datastore, Flannel for networking, Traefik as the ingress controller, ServiceLB (Klipper) so LoadBalancer services get an address on a single node, CoreDNS, and a network policy controller.

curl -sfL https://get.k3s.io | sh -

The kubeconfig lands at /etc/rancher/k3s/k3s.yaml, and the token for joining agents lives at /var/lib/rancher/k3s/server/node-token.

SQLite is the part that surprises people. It's perfect for one server and useless for HA. For high availability you need an odd number of servers (three minimum) running embedded etcd, and you have to start the first one with --cluster-init. You can't bolt that on later by adding servers to a SQLite cluster.

If you already run your own ingress, start the server with --disable=traefik rather than fighting the bundled one.

RKE2: Built for the Audit

RKE2 started life as "RKE Government", and it shows. Its images are built on a hardened SLE Base Container Image, its Go binaries are compiled with a FIPS 140-2 compliant build process, and it ships with a CIS hardening guide, SELinux support and secrets encryption. One caveat worth knowing before you promise anything: only Linux AMD64 is FIPS compliant.

curl -sfL https://get.rke2.io | sh -
systemctl enable rke2-server.service
systemctl start rke2-server.service

The first thing that trips everyone: kubectl is installed to /var/lib/rancher/rke2/bin/ and is not on your PATH. The kubeconfig is at /etc/rancher/rke2/rke2.yaml.

Networking defaults to Canal, with Cilium, Calico and Flannel also bundled. You pick one with the cni key in /etc/rancher/rke2/config.yaml.

The big 2026 change is ingress. The Ingress NGINX project announced its retirement in March, and RKE2 responded: Traefik became the default for new clusters in v1.36, and ingress-nginx is gone entirely for new clusters in v1.37. Existing clusters that already use ingress-nginx as their default keep it on upgrade. So a lot of RKE2 tutorials online, and plenty of comparison articles, are now simply wrong about what you get. RKE2 publishes an official migration guide if you're moving an existing cluster.

k0s: Nothing You Didn't Ask For

k0s takes the opposite position from k3s. It ships no ingress controller at all, defaults to kube-router for networking (Calico is also bundled), and isolates the control plane by default: controller nodes don't run your workloads.

curl --proto '=https' --tlsv1.2 -sSf https://get.k0s.sh | sudo sh
sudo k0s install controller --single
sudo k0s start

That separation is good hygiene for production and genuinely confusing on a one-node test box, which is why the flag choice matters more than it looks:

• --single gives you a single-node cluster that cannot be expanded later.
• --enable-worker (with --no-taints if you want pods scheduled there) makes a controller double as a worker and still lets you add nodes.

Storage has its own wrinkle. k0s defaults to etcd, but --single mode uses kine with SQLite instead. Build that same single node with k0sctl and you get etcd unless you set kine explicitly. Not a problem, just not what most people expect.

Troubleshooting

RKE2: kubectl: command not found. Add /var/lib/rancher/rke2/bin to your PATH and point KUBECONFIG at /etc/rancher/rke2/rke2.yaml.

RKE2: your ingress resources stopped working after a fresh install. You're on v1.37 with manifests written for ingress-nginx. Update the ingress class or annotations for Traefik.

k3s: can't add a second server for HA. The first one wasn't started with --cluster-init, so it's on SQLite. Plan HA from day one.

k0s: pods stuck Pending on a one-node cluster. The controller isn't a worker. Reinstall with --enable-worker --no-taints, or use --single.

k0s: can't join a second node. You used --single. It's a one-way door.

Running One Without Babysitting It

All three are available as managed deployments on Elestio at $16/month: k3s, RKE2 and k0s, with backups, monitoring and updates handled, across Hetzner, DigitalOcean, Vultr, Linode, Scaleway, Netcup, AWS or your own VM. Budget 2 vCPU and 4 GB RAM as a comfortable baseline for a single node.

My honest default: start with k3s unless you have a specific reason not to. Reach for RKE2 when compliance is a requirement rather than a preference, and for k0s when you want upstream Kubernetes without anyone else's opinions baked in.

Thanks for reading ❤️ See you in the next one 👋