MicroK8s: Canonical's Compact Kubernetes

Getting a Kubernetes cluster up used to mean hand-rolling kubeadm, fighting cgroup versions, and installing CoreDNS by hand. MicroK8s collapses that into one snap install — Canonical’s answer to “I want pure upstream Kubernetes without operating it.”

What it actually is

MicroK8s is Canonical’s minimal, single-package Kubernetes distribution. The pitch is deliberately narrow: pure-upstream (no forked APIs, CNCF-conformant), zero-ops (the packaging handles lifecycle), and HA-capable from the same bits that run a single node. It ships as a snap, which matters more than it sounds — the snap bundles the binaries, isolates them from the host filesystem, and gives Canonical a channel to push transactional OTA updates with automatic rollback.

That last part is the real differentiator. Most distributions hand you a version-upgrade runbook. MicroK8s treats the whole cluster as a snap revision: you snap refresh, the new revision goes live, and if the cluster doesn’t come back healthy it rolls itself back. It’s the apt-upgrade mental model applied to Kubernetes.

Install to first pod in four commands

The tutorial path is short enough to paste:

sudo snap install microk8s --classic
microk8s status --wait-ready
microk8s enable dns dashboard registry istio
microk8s kubectl get all --all-namespaces

--wait-ready blocks until the API server and addons settle, so you don’t race a half-started control plane. Note the microk8s kubectl wrapper — it points at this instance’s kubeconfig automatically, which is what keeps parallel installs on one host from stomping each other. If you’d rather use plain kubectl, microk8s config > ~/.kube/config exports the kubeconfig.

On macOS the path is brew install ubuntu/microk8s/microk8s followed by microk8s install; Windows has a native installer. The same snap runs on ARM and Intel, including Raspberry Pi boards, clouds, and appliances.

Two setup details bite people immediately:

sudo usermod -a -G microk8s $USER   # run kubectl without sudo
newgrp microk8s                     # apply group membership now

Without the group membership, every microk8s kubectl call needs sudo — and worse, a sudo kubectl against the exported kubeconfig writes root-owned files into your home directory. The API server listens on port 16443, so cloud security groups and firewalls need that open before you wonder why join times out. When something is wedged, microk8s inspect produces a support tarball with logs, status, and addon state — it’s the first command to reach for before guessing.

Addons are the product

The addon system is where MicroK8s earns its keep. microk8s enable <addon> deploys a curated, known-good manifest set — and microk8s disable <addon> removes it. Popular bundled addons include Prometheus, Jaeger, Istio, Linkerd, Knative, the dashboard, a local registry, and Helm (which installs microk8s.helm3).

The honest caveat: these are convenience installs, not managed services. Enabling Istio gets you Istio; you still operate Istio. But for evaluation clusters, CI runners, and edge boxes, the fact that DNS, ingress, and metrics come from one command rather than three YAML repos is a genuine time sink removed.

You’re not locked into the catalog either — the addon mechanism supports your own addons, so platform teams can wrap internal manifests behind the same enable/disable interface.

Growing it into HA

Single node is the default, but the HA path uses the same package:

# on the second node
microk8s join <first-node-ip>:25000/<token>

Each joined node runs a full control-plane member; MicroK8s uses Dqlite (a SQLite-based clustered datastore) rather than etcd for the HA control plane — lighter, and tuned for the small-node counts MicroK8s targets. Canonical describes the result as self-healing HA: node loss doesn’t take the API server with it.

A practical note on scale: MicroK8s is comfortable at the small-to-medium end. If you’re pushing hundreds of nodes, the Dqlite model and the project’s own positioning point you toward Charmed Kubernetes, Canonical’s composable alternative.

Why the snap matters

The packaging choice does three things at once:

• Isolation — binaries live inside the snap, so MicroK8s doesn’t fight the host’s Python, glibc, or container runtime. A snap remove microk8s leaves the host as it was; there’s no half-uninstalled control plane scattered across /etc and /var/lib.
• Transactional updates — a snap revision is swapped in whole, and a failed refresh rolls back automatically. That’s a materially different risk profile from a rolling kubeadm upgrade where a bad kubelet version can strand a node.
• One channel for everything — the control plane, the kubelet, and the addon catalog versions move together on the snap channel, so version skew between components is largely Canonical’s problem rather than yours.

The trade-off is equally real: snaps need the snapd daemon, they’re slower to start than a bare binary, and environments that ban snaps (some hardened appliances, some CI images) can’t use MicroK8s at all. That constraint is worth checking before you standardize on it.

MicroK8s is also CNCF-conformant, which means the conformance test suite passes — a fact you can verify rather than trust, and the reason “pure upstream” isn’t just a slogan here. There are no forked APIs to unlearn later.

Day-2: start, stop, update

Lifecycle commands are deliberately trivial:

microk8s stop      # halt the cluster (frees ports/sockets)
microk8s start     # bring it back
snap refresh microk8s   # transactional update, auto-rollback

stop/start is genuinely useful on laptops and CI — you reclaim RAM without uninstalling, and the cluster comes back with its state intact. And because updates ride the snap channel, patching a cluster is closer to patching Ubuntu than to a kubeadm upgrade.

Under Ubuntu Pro, Canonical attaches a 99.9% uptime SLA and security maintenance of up to 15 years — the commercial story for shops that want upstream Kubernetes with an enterprise patch tail.

When to pick it (and when not)

Choose MicroK8s when you want minimal friction on Ubuntu-adjacent hosts, one-command addons, and updates that don’t require a maintenance window plan. It’s a strong fit for edge appliances, dev clusters, and Kubernetes teaching environments.

Look elsewhere when you need a large-node fleet, non-snap-centric operations (some appliances block snaps entirely), or a specific distribution your organization has already standardized on. The snap is both the best thing about MicroK8s and its main portability constraint — isolated deployment protects the host, but it also means apt-only environments need the Windows/macOS paths or a different tool.

Further reading

• MicroK8s official site
• MicroK8s documentation
• Canonical: Kubernetes comparison
• Kubernetes: Running Kubernetes Locally