k3s and “k8s” are not rival products. k3s is a single-binary Kubernetes distribution from the Rancher/SUSE ecosystem; “k8s” is shorthand for upstream Kubernetes, which you usually install with kubeadm or get from a cloud provider. The short answer for a small team: if you run one to a few Linux hosts, a lab, an edge site or a CI test cluster, k3s gives you the same Kubernetes API with far less to assemble. If you need to pick every component yourself, or your platform team already runs kubeadm or a managed service, stay with upstream. Facts below were checked on 7 November 2026 against docs.k3s.io, kubernetes.io and the GitHub release pages of both projects. Not tested yet: we have not built a benchmark cluster for this article, so there are no speed or memory measurements of our own.
Versions and licences checked on 7 November 2026
| Item | k3s | Upstream Kubernetes (k8s) |
|---|---|---|
| Latest stable release on GitHub | v1.37.2+k3s1, published 3 November 2026 | v1.37.2, published 28 October 2026 |
| Licence | Apache-2.0, free | Apache-2.0, free |
| Delivered as | One binary or a minimal container image; install script at get.k3s.io | Separate components; kubeadm, a distribution or a managed cloud service |
| Default datastore | Embedded SQLite (single server); embedded etcd for HA | etcd |
| Minimum server | 2 CPU cores, 2 GB RAM | kubeadm: 2 CPUs and 2 GB RAM per control-plane machine |
| Minimum agent (worker) | 1 core, 512 MB RAM | kubeadm: 2 GB RAM per machine |
| Architectures | x86_64, armhf, arm64 | Depends on the distribution you use |
k3s version numbers track upstream: v1.37.2+k3s1 is built on Kubernetes 1.37.2. The k3s requirements page says its minimums are a baseline for k3s and its packaged components and “do not include resources consumed by the workload itself”, so treat 2 GB as a floor, not a plan. The kubeadm figures come from the kubeadm install guide; the k3s figures from the k3s requirements page.
What k3s bundles and upstream leaves to you
According to the k3s documentation, a fresh k3s server ships with containerd as the container runtime, Flannel as the network plugin, CoreDNS, the Traefik ingress controller, the ServiceLB load-balancer controller, kube-router for network policy, the local-path provisioner for volumes, and the Spegel image mirror. The packaging page lists coredns, traefik, local-storage and metrics-server as auto-deployed add-ons. Everything runs inside one server process, so certificates and control-plane startup are handled for you.
A kubeadm cluster gives you a control plane and nothing else: you install a container runtime first, then pick a CNI plugin, an ingress controller, storage and a load balancer. That is more work but also more choice, and it is the layout most Kubernetes training material assumes. If you want a CNI such as Cilium or Calico, you can still swap Flannel out in k3s, but then you own that part just as you would on kubeadm.
Install in five minutes: the k3s path
The documented one-node install is a single line, run as root on a systemd or openrc Linux host:
curl -sfL https://get.k3s.io | sh -This installs a service that restarts after reboots, adds kubectl, crictl, ctr and the k3s-uninstall.sh script, and writes the kubeconfig to /etc/rancher/k3s/k3s.yaml. To add a worker, run the same script on that machine with K3S_URL=https://myserver:6443 and K3S_TOKEN set to the value from /var/lib/rancher/k3s/server/node-token on the server. Hostnames must be unique; if they are not, set K3S_NODE_NAME. The script pipes a download into a shell, so read it first before using it on a production network.
The server must be reachable on TCP 6443, and nodes need to reach each other on UDP 8472 when the default Flannel VXLAN backend is used. If firewalld or ufw is on, the docs list extra rules for the pod range 10.42.0.0/16 and the service range 10.43.0.0/16, or recommend turning the firewall off. On Raspberry Pi OS the docs say cgroups must be enabled in cmdline.txt, and that etcd is write intensive, so SD cards and eMMC cannot handle the I/O; use an external SSD.
Upstream with kubeadm: what you sign up for
With kubeadm you prepare each host (container runtime, kubelet, kubeadm, kubectl, unique MAC address and product_uuid, open ports), run kubeadm init, apply a CNI, and join the rest. The kubeadm page also notes that its binaries are dynamically linked and expect glibc, which matters on Alpine-style minimal systems. None of this is hard, but it is a longer list to automate and keep consistent across nodes, which is where Ansible earns its place. Upgrades are also yours to sequence: control plane first, then each node.
High availability, storage and backups
This is where the “small cluster” argument needs care.
- Single server (default). k3s uses SQLite, which the docs say cannot be used on a cluster with multiple servers. One server means a control-plane outage if that host fails; pods already running on agents keep running, but you cannot change anything.
- Embedded etcd HA. Three or more server nodes, an odd number so etcd keeps quorum. The docs warn embedded etcd may be slow on weak disks such as Raspberry Pi SD cards.
- External database. Two or more servers with MySQL, MariaDB, PostgreSQL or etcd as the datastore. Certified versions on the datastore page include PostgreSQL 15.12, 16.7 and 17.3, MySQL 8.0 and 8.4, MariaDB 10.11 and 11.4. Poolers such as PgBouncer may need extra configuration because k3s requires prepared statements.
- Backups. With embedded etcd, scheduled snapshots are on by default at 00:00 and 12:00 system time, keeping 5 per server on local disk, with options for compression and S3-compatible storage. Snapshots on the same disk are not a backup of the host, so copy them off the machine.
The k3s sizing guide gives a server with 2 CPUs and 4 GB RAM as enough for 0 to 350 agents under standard workload conditions. Few small teams will approach that, which is the real point: at typical sizes the control plane is not the constraint, your application and your storage are. Upstream Kubernetes can run the same API at much larger scale, but nothing in this comparison needs it.
Support windows and upgrades
The Kubernetes release page lists 1.37 with end of life on 28 October 2027, 1.36 on 28 June 2027, 1.35 on 28 February 2027 and 1.34 on 27 October 2026, so a 1.34 cluster has already left the supported window as of this writing. k3s publishes a matching minor version shortly after each upstream one, so you inherit the same cadence. In either case plan a minor upgrade at least once a year, and keep a tested way to rebuild the cluster from code.
k3s supports manual upgrades and Kubernetes-native automated ones through Rancher’s system-upgrade-controller. One caveat from its upgrade notes: k3s 1.32 and later installs Traefik v3, while 1.31 and earlier installed Traefik v2, so ingress definitions may need review when you cross that line.
Where it runs: VMs, labs and code
Both options need Linux hosts, and for a small team those are usually virtual machines. A three-node k3s cluster fits on a modest Proxmox VE host, which is free and open source; QEMU works for a single-machine test; Vagrant suits throwaway lab clusters. To keep the VMs reproducible, define them with OpenTofu or Terraform. For the wider picture of hypervisors and container tools, see the virtualization and container tools hub.
Limitations
- k3s removes components and opinions, not the Kubernetes learning curve: networking, storage and RBAC still need to be understood.
- Packaged components are managed by k3s and rewritten at startup, so change them through documented configuration, not by hand.
- A single-server cluster has a single point of failure for the control plane.
- We have not run a performance comparison; the memory figures here are the vendors’ stated minimums, not measurements.
Who should choose what
| Situation | Better fit |
|---|---|
| One to five Linux hosts, no dedicated platform engineer | k3s |
| Edge site, branch office, Raspberry Pi or ARM boards | k3s (arm64 and armhf supported; use SSD storage) |
| CI test cluster that is created and destroyed often | k3s, single server with SQLite |
| You must choose your own CNI, storage and ingress from day one | Upstream with kubeadm, or k3s with those parts disabled |
| Your cloud provider offers managed Kubernetes and you need no on-premises nodes | The managed service |
| Company policy requires a specific vendor distribution | Follow the policy; check which version it supports |
FAQ
Is k3s production ready?
The project documents high-availability modes, backups and an upgrade path, which are production features. Whether it fits you depends on uptime needs: use three servers with embedded etcd, or an external database, if control-plane downtime matters.
What is the difference between k3s and k8s?
k8s is upstream Kubernetes, assembled by you. k3s is a Kubernetes distribution packaged as one binary with a default runtime, network, ingress, storage and SQLite datastore.
k3s vs MicroK8s: which is easier?
We have not compared them hands-on and will not guess. Check each project’s current documentation for supported operating systems and upgrade steps before choosing.
Can k3s run on a Raspberry Pi?
Yes, arm64 and armhf are supported. The docs require cgroups enabled on Raspberry Pi OS and recommend an external SSD instead of an SD card.
What are the minimum requirements for k3s?
A server needs 2 cores and 2 GB RAM, an agent 1 core and 512 MB, on top of whatever your workload uses.
Can I move from k3s to full Kubernetes later?
The API is the same, so manifests and Helm charts usually move across. Storage classes, ingress annotations and load-balancer behaviour are the parts to re-check.
Last updated: 7 November 2026 · ITForgePro editorial team. Licence, version and platform details are checked against each developer's official documentation.
