K3s vs MicroK8s
K3s vs MicroK8s compared on install, footprint, datastores, high availability, networking, add-ons, upgrades and release cadence, using K3s v1.37.1+k3s1 and the MicroK8s snap as of October 2026.
Quick Answer
Pick K3s if you want one small binary that runs on almost any Linux distribution and CPU (x86_64, armhf, arm64), with SQLite for a single server, embedded etcd for HA and a choice of external MySQL, MariaDB, PostgreSQL or etcd. It is also closer to upstream: K3s shipped Kubernetes 1.37 on 30 Sep 2026. Pick MicroK8s if you live on Ubuntu and want snap-managed Kubernetes with one-command add-ons (GPU, Rook-Ceph, MetalLB, cert-manager and more) and automatic HA once you have three nodes. Its newest stable track is 1.36, with no 1.37 track in the Snap Store yet.
Last updated October 27, 2026. Covers K3s v1.37.1+k3s1 (30 Sep 2026) and the MicroK8s Snap Store tracks as of 27 Oct 2026 (1.36/stable v1.36.2), using each project's current docs on requirements, datastores, HA, networking, add-ons and upgrades.
| Feature | K3s | MicroK8s |
|---|---|---|
| Licence | Apache-2.0 | Apache-2.0 |
| Maintainer | K3s project (originally Rancher, SUSE); CNCF Sandbox | Canonical |
| Latest Stable (Oct 2026) | v1.37.1+k3s1 (30 Sep 2026); stable channel v1.36.5+k3s1 | v1.36.2 (1.36/stable, 30 Jun 2026); 1.37 not yet in the Snap Store |
| Install Method | Single binary / install script | Snap (--classic), track per Kubernetes minor |
| Minimum Resources | Server 2 cores, 2 GB RAM; agent 1 core, 512 MB | 540 MB minimum; 4 GB memory and 20 GB disk recommended |
| CPU Architectures | x86_64, armhf, arm64 | amd64, arm64 (1.36/stable) |
| OS Support | Most modern Linux distributions | Ubuntu first; any Linux with snapd; Windows/macOS via Multipass |
| Datastore | SQLite (default), embedded etcd, external etcd/MySQL/MariaDB/PostgreSQL | dqlite (k8s-dqlite); etcd only with ha-cluster disabled |
| High Availability | Embedded etcd with 3+ (odd) servers, or external DB | Automatic with 3+ nodes (dqlite voters) |
| Worker-Only Nodes | Yes (k3s agent) | Yes (microk8s join --worker, since 1.23) |
| Default CNI | Flannel (VXLAN by default) | Calico (VXLAN); Flannel only with ha-cluster disabled |
| Ingress / Load Balancer | Traefik + ServiceLB bundled | ingress and metallb add-ons |
| Add-ons / Extras | Bundled CoreDNS, metrics-server, local-path, Spegel; Helm charts via manifests | ~20 core add-ons + community repository (~30) |
| Upgrades | system-upgrade-controller Plans following release channels | Automatic snap refreshes within a track; move tracks for minors |
K3s
Certified, lightweight Kubernetes distribution originally developed by Rancher (now SUSE) and a CNCF Sandbox project. It ships as a single binary under 100 MB that bundles containerd, Flannel, CoreDNS, Traefik, ServiceLB, kube-router, local-path-provisioner and Spegel.
Pros
- One binary under 100 MB with a container runtime, CNI, DNS, ingress, load balancer, network policy and local storage included
- Runs on most modern Linux distributions on x86_64, armhf and arm64, so Raspberry Pi and edge boxes are first-class
- Small baseline: 2 cores and 2 GB RAM for a server, 1 core and 512 MB for an agent
- Datastore choice: SQLite by default, embedded etcd for HA, or external etcd, MySQL, MariaDB or PostgreSQL
- Tracks upstream closely: v1.37.1+k3s1, v1.36.5+k3s1 and v1.35.9+k3s1 all shipped on 30 Sep 2026
- Files dropped in /var/lib/rancher/k3s/server/manifests are applied automatically, and any bundled component can be turned off with --disable
Cons
- The default SQLite datastore cannot be used with multiple servers; HA means embedded etcd (an odd number of servers, at least three) or an external database
- Embedded etcd can perform poorly on slow disks such as Raspberry Pi SD cards, as the docs warn
- No add-on catalogue: anything beyond the bundled components is Helm charts or manifests you manage yourself
- The docs recommend turning off firewalld and list extra setup steps for RHEL, SUSE, Ubuntu/Debian and Raspberry Pi
- Automated upgrades need the separate system-upgrade-controller, and it does not stop you from skipping minor versions
Best For
Edge and ARM devices, small VPS clusters and CI runners on any Linux distro, and teams that want the newest Kubernetes minor soon after release.
MicroK8s
Canonical's snap-packaged Kubernetes. A single kubelite service runs the API server, scheduler, controller manager, proxy and kubelet, with containerd, a dqlite datastore and Calico, plus a catalogue of core and community add-ons enabled with microk8s enable.
Pros
- One command to install on Ubuntu or any OS with snapd: sudo snap install microk8s --classic
- Add-ons in one command: dns, ingress, metallb, cert-manager, gpu, rook-ceph, mayastor, prometheus, registry and more, plus a community repository (Argo CD, Cilium, Istio, Linkerd, KEDA, OpenEBS)
- HA turns on automatically once a cluster has three or more nodes, using a replicated dqlite datastore
- Joining is microk8s add-node on an existing node and the printed microk8s join command on the new one; --worker adds nodes without the control plane
- Patch releases and security fixes arrive through snap refreshes within the track you follow
- Runs on Windows and macOS through Multipass for local development
Cons
- Snap-based, so you need snapd; Ubuntu is the primary target and refreshes apply automatically with no notification unless you schedule or proxy them
- Slower to new Kubernetes minors: the newest stable track in the Snap Store on 27 Oct 2026 is 1.36 (v1.36.2), with no 1.37 track yet and a default track of 1.35
- Recommended sizing is higher than K3s: at least 4 GB of memory and 20 GB of disk (540 MB is the stated minimum)
- dqlite is the only HA datastore option; there is no supported external MySQL or PostgreSQL backend
- Switching from Calico to Flannel means disabling ha-cluster, which the docs call destructive and only suitable for new clusters
Best For
Ubuntu-based developer machines, labs and small clusters where one-command add-ons (GPU, storage, ingress, observability) and automatic HA matter more than the newest Kubernetes minor.
Packaging: a single binary versus a snap
K3s ships as one binary under 100 MB. Inside are a container runtime (containerd, or cri-dockerd), Flannel for pod networking, CoreDNS, Traefik as ingress, ServiceLB as a load-balancer controller, kube-router for network policy, local-path-provisioner for volumes, Spegel as a distributed registry mirror and host utilities like iptables and socat. CoreDNS, Traefik, local storage and metrics-server are deployed as AddOns, and any of them can be removed with a flag such as --disable=traefik, which uninstalls it and deletes its manifest. Anything you drop into /var/lib/rancher/k3s/server/manifests on a server is applied automatically, which is a simple GitOps hook. MicroK8s is a classic-confinement snap. Since 1.21 a single kubelite service runs the scheduler, controller manager, proxy, kubelet and API server as subprocesses, next to containerd and the k8s-dqlite datastore. Out of the box it is deliberately minimal; Canonical's getting-started guide tells you to enable dns and hostpath-storage yourself. The difference in practice: K3s gives you a working ingress and load balancer on first boot, while MicroK8s asks you to choose them from its add-on list.
Footprint and where each one runs
K3s documents a baseline of 2 cores and 2 GB of RAM for a server and 1 core and 512 MB for an agent, before workloads. Its sizing table puts a 2-core, 4 GB server at 0 to 350 agents and a 4-core, 8 GB server at 351 to 900, with roughly 50% more headroom in a three-server HA setup. It supports x86_64, armhf and arm64 and is expected to work on most modern Linux distributions, with extra notes for SUSE, RHEL and Fedora, Ubuntu and Debian, and Raspberry Pi. The docs recommend turning firewalld off. MicroK8s says it runs in as little as 540 MB of memory but recommends at least 4 GB of memory and 20 GB of disk. Ubuntu is the primary environment; any OS with snapd works, and Windows and macOS users run it inside Multipass VMs. That makes MicroK8s handy on a developer laptop, but on a 2 GB VPS or an ARMv7 board K3s is the safer fit. If your fleet mixes distributions, K3s avoids adding snapd to hosts that do not already use it.
Datastores and high availability
K3s defaults to SQLite, which is fine for a single server but cannot be used with multiple servers. For HA you either start the first server with --cluster-init to use embedded etcd and join more servers (an odd number, at least three, for quorum), or point all servers at an external datastore. K3s lists etcd 3.5, MySQL 8.0 and 8.4, MariaDB 10.11 and 11.4, and PostgreSQL 15, 16 and 17 as tested backends, with notes that Galera-style multi-master setups are not supported and PgBouncer may need prepared-statement configuration. An existing single-server SQLite cluster can be converted to etcd by restarting with --cluster-init. The docs warn that etcd struggles on slow disks such as SD cards. MicroK8s keeps cluster state in dqlite. HA switches on automatically when the cluster reaches three nodes: a subset of at least three nodes hold voting copies, others are standbys or spares, and a new leader is elected within about 5 seconds if the leader disappears. You add nodes with microk8s add-node and the printed join command, and --worker nodes run workloads without the control plane. There is no external SQL option, so if you already run a managed PostgreSQL and want the control plane state there, only K3s supports it.
Networking, ingress and add-ons
K3s uses Flannel with the VXLAN backend (UDP 8472 between nodes), with a WireGuard backend option on UDP 51820. Traefik and ServiceLB mean a LoadBalancer Service and an Ingress work on a bare VPS without MetalLB or a cloud controller. Everything else, from cert-manager to Longhorn, is a Helm chart or manifest you install and upgrade yourself; K3s can deploy Helm charts declared in its manifests directory. MicroK8s uses Calico with VXLAN by default when ha-cluster is enabled. Moving to Flannel requires disabling ha-cluster, which the docs describe as destructive and only for new clusters. Its strength is the add-on catalogue. The core repository includes cert-manager, dns, dashboard, gpu, helm, hostpath-storage, ingress, kube-ovn, mayastor, metallb, metrics-server, minio, prometheus, rbac, registry and rook-ceph. The community repository adds Argo CD, Cilium, Istio, Linkerd, KEDA, Knative, OpenEBS, Portainer, Traefik, Trivy and more. For a GPU workstation or a three-node lab with Ceph storage, that saves real setup time, as long as you are comfortable with how each add-on is versioned within MicroK8s.
Upgrades and release cadence
K3s publishes release channels at update.k3s.io; on 27 Oct 2026 the stable channel points to v1.36.5+k3s1 and latest to v1.37.1+k3s1. Patch releases for 1.37, 1.36 and 1.35 all shipped on 30 Sep 2026. Automated upgrades use Rancher's system-upgrade-controller: you write Plan resources that select nodes by label and either follow a channel URL or pin a version, and the controller runs upgrade Jobs. The docs warn that it will not stop you from skipping a minor version, so step through minors yourself. MicroK8s follows snap tracks, one per Kubernetes minor. Within a track, new revisions with patch and security fixes are applied automatically about every six hours with no notification, unless you set a refresh timer or put a Snap Store Proxy in front. On 27 Oct 2026 the Snap Store's newest stable track is 1.36 (v1.36.2, published 30 Jun 2026), the default track is 1.35, and there is no 1.37 track, although the MicroK8s repository added Kubernetes 1.37 patches on 30 Sep and bumped build components for 1.37 on 14 Oct. If you need a new minor within weeks of upstream, K3s has the better record right now.
Verdict
Choose K3s for anything that is not an Ubuntu machine you control end to end: edge devices, Raspberry Pi clusters, small VPS fleets on Debian, RHEL or SUSE, and CI. It is one binary with ingress, load balancing, storage and network policy already wired, it scales from a single SQLite-backed server to embedded etcd or an external PostgreSQL or MySQL database, and it shipped Kubernetes 1.37 on 30 Sep 2026. Choose MicroK8s if your nodes run Ubuntu and you want to turn features on rather than assemble them: microk8s enable gpu, rook-ceph, metallb or cert-manager is quicker than finding and maintaining Helm charts, and HA is automatic at three nodes. Accept two trade-offs with MicroK8s: snap refreshes apply on their own unless you schedule them, and new Kubernetes minors arrive later (no 1.37 track in the Snap Store as of 27 Oct 2026). If you need an external SQL datastore or 32-bit ARM (armhf) boards, pick K3s: MicroK8s documents no external SQL backend, and its 1.36 stable snap is published for amd64 and arm64 only.