MicroK8s

What MicroK8s actually is

MicroK8s is Canonical's compact Kubernetes distribution, shipped as a single snap package. It is not a hosting product and not a managed control plane in the way the hyperscalers sell one: it is upstream Kubernetes, packaged so that a conformant cluster installs on any snap-capable Linux in one command, with add-ons you toggle on and off from the CLI. Canonical released it in December 2018, initially targeting the gap between minikube-style laptop toys and production kubeadm installs. In our view it has since become the default choice for edge and single-node Kubernetes, and one of the two or three distributions we actually recommend when someone asks "how do I run Kubernetes on a small box?"

The headline claim is the footprint. Since Kubernetes 1.21, Canonical compiles the upstream binaries into a single binary before packaging, which cut the deployed Kubernetes from about 800MB to roughly 540MB of RAM. That number is real and it matters: it means a Raspberry Pi 4 with 2GB, a small Intel NUC, or a Jetson device can run a working control plane and still have memory left for workloads. Canonical's own documentation recommends at least 4GB RAM and 20GB disk for comfort, and we agree — 540MB is the floor for the platform itself, not for anything useful you plan to run on it.

The packaging model is the second thing worth understanding. Snap channels track upstream Kubernetes minor versions (1.31/stable, 1.32/stable, and so on), patch updates apply automatically within a channel, and minor upgrades are an explicit channel switch. A strict-confinement channel exists as well, which restricts host system access — relevant for anyone embedding MicroK8s inside a product. MicroK8s is CNCF-conformant Kubernetes, so workloads that run on it run on EKS or GKE too. That conformance is the main reason we rate it above hobbyist distributions: local development parity with production is not a marketing line here, it is enforced by the conformance test suite.

Pricing: what you really pay

MicroK8s is free. The snap installs from the Snap Store at no cost, the source is on GitHub under Apache 2.0, and there is no license key, no seat count, and no metered tier. If you see a MicroK8s invoice, you are buying something else — Canonical's paid Kubernetes support (via Ubuntu Pro or a commercial support agreement) covers supported clusters including MicroK8s deployments, but that is a support contract priced per node or per machine, sold by Canonical's sales team, and entirely optional. We could not find a public per-node MicroK8s support price to quote here, so we will not invent one.

This is the honest framing: the software costs nothing, and the costs appear in the hardware you run it on and the operational time you spend on it. A three-node HA MicroK8s cluster on cheap VPS instances is still three VPS bills plus the sysadmin hours to keep the cluster healthy. Compared with paying a cloud provider a monthly fee for a managed control plane, the trade is money for time. For teams with Kubernetes experience, that trade is usually worth it. For teams without it, the "free" price tag quietly turns into consultancy spend.

Performance & infrastructure

There is no datacenter, no SLA, and no network to benchmark in the usual sense — MicroK8s runs wherever you put it, so performance is a function of your hardware. What we can say concretely: the 540MB platform footprint is the smallest among full distributions we track, the add-on set covers the practical needs (DNS, storage via OpenEBS or hostpath, ingress, a private registry, Prometheus, Grafana, Istio, Knative, GPU enablement via the NVIDIA add-on, Kubeflow, Linkerd, Cilium and others), and each add-on is a single microk8s enable <name> away. The docs list well over thirty add-ons across core, community, and partner repos.

Clustering is built in: microk8s add-node prints a join command, dqlite backs the control plane for multi-node HA, and the same snap that runs your laptop cluster runs the edge cluster. Automatic updates patch the platform inside a channel; note that workloads and enabled add-ons are not upgraded by a platform refresh, and the upgrade docs say so explicitly. That is the right default (surprise workload upgrades are worse), but it means upgrades are a two-step habit, not one command.

On hardware: x86_64 and arm64 are first-class, arm32 is supported, and the NVIDIA add-on wires up GPU operators for ML workloads on Jetson-class devices. If you are looking for raw numbers to compare against VPS providers, our benchmark methodology applies to rented machines, not to software like this — run MicroK8s on the provider you pick and the provider's numbers are what you get.

Two operational details are worth calling out because they shape real deployments. First, the registry add-on gives you a local OCI-compliant container registry in one command, which is genuinely useful at the edge: appliances can cache images locally instead of pulling across a thin link on every rollout. Second, the storage story is deliberately thin by default — hostpath or the OpenEBS add-on cover basic stateful workloads, but serious production state wants a proper storage layer, and that is an extra integration you own. The same applies to networking: Calico is the default CNI, Cilium is available as an add-on, and customising either means taking over a manifest that platform upgrades will not maintain for you.

From a security standpoint, MicroK8s benefits from snap confinement and automatic patch updates, and the strict-confinement channel goes further by restricting host access — Canonical has been pushing that channel since the 1.26 release, and for embedded products we think it is the right default. Pod-level security is stock Kubernetes: RBAC, network policies, and whatever admission controllers you add. Nothing here replaces a hardening pass on your own workloads.

Where it falls short

The single-node default is convenient until it is not. Clustering works, but MicroK8s is opinionated about it (dqlite, its own join flow) and large or heterogeneous clusters are outside its comfort zone. If you need a 50-node production cluster with autoscaling, multiple control planes behind a load balancer, and managed etcd, that is kubeadm, Cluster API, or a managed service territory — MicroK8s has CAPI providers now, but it is not what we would reach for at that scale.

The add-on model is a double-edged sword. Toggling Prometheus on in one command is great; the add-ons are packaged manifests with pinned versions, and the upgrade path for them is still, per Canonical's own docs, disable and re-enable. Customized add-on configurations need manual re-patching across upgrades. Teams that treat MicroK8s like a platform they can deeply customize end up maintaining forks of manifests.

Support for the free tier is community-level: GitHub issues, a Discourse forum, Stack Overflow. Canonical's paid support exists and is good, but it is priced for organisations, not side projects. And there is no hosted option — if you want someone else to run the control plane, look at the managed offerings in our Kubernetes category instead. Finally, being snap-based is a real constraint: some organisations block snaps, and non-Ubuntu distributions can have friction with snapd, though it generally works.

Who should pick this

We pick MicroK8s when the workload is small, the hardware is modest, or the deployment target is the edge. Concretely: developers who want a production-parity local cluster instead of a laptop-only tool; IoT and telco teams shipping Kubernetes onto gateways, vehicles, or retail appliances; CI pipelines that spin disposable clusters up and down; homelab and self-hosters running real services on a single node; and ML teams that need GPU-enabled Kubernetes on devices like Jetson.

We would not pick it for a large multi-tenant production estate, for a team with zero Kubernetes experience and a deadline, or for anyone who needs an uptime SLA on the control plane itself. In those cases a managed cluster from a major provider, or a supported kubeadm-based setup, earns its cost. As a category pick, it sits comfortably in Kubernetes distributions next to heavier options, and for the edge case in particular, it is our default recommendation.

One pairing we like: MicroK8s on cheap, well-specced VPS or bare-metal nodes from providers we rate highly on our benchmarks. A 4GB/2-vCPU node comfortably hosts a single-node MicroK8s plus a few real services, which puts a genuinely portable production stack at the price of an inexpensive VM. The same recipe scales to a three-node dqlite HA cluster for small production use, though at that point we would want monitoring (the Prometheus add-on), tested backups of persistent volumes, and a documented upgrade routine before calling it production-ready. MicroK8s gives you the platform; the discipline is still yours.

Key takeaways

• Free, Apache-2.0 upstream Kubernetes as a single snap; CNCF-conformant, so portability to managed clouds is real, not aspirational.
• Roughly 540MB RAM footprint for the platform — the smallest full distribution we track, viable on Raspberry Pi, NUC, and Jetson hardware.
• Over thirty add-ons (DNS, ingress, storage, registry, Prometheus, Istio, GPU) toggled with one command; add-on upgrades need manual disable/re-enable.
• Built-in multi-node clustering with dqlite-backed HA; automatic patch updates within a version channel, minor upgrades are explicit.
• No SLA, no hosted option, community support by default; Canonical sells paid support separately.
• Best for edge, IoT, local development parity, and small single-node production — not for large managed estates.

Sources

• https://snapcraft.io/blog/canonical-launches-microk8s-deploy-kubernetes-in-seconds
• https://canonical.com/microk8s/docs/getting-started
• https://canonical.com/blog/microk8s-memory-optimisation
• https://microk8s.io/docs/upgrading
• https://microk8s.io/docs/release-notes
• https://discuss.kubernetes.io/t/past-release-notes/33682
• https://canonical.com/legal/companies
• https://github.com/canonical/microk8s