MicroK8s: a single-package Kubernetes for workstations, CI runners and edge boxes

What MicroK8s is for, and who ends up running it

MicroK8s is a Kubernetes distribution packaged as a single snap. The README calls it a "Single-package fully conformant lightweight Kubernetes" and lists four target audiences: developer workstations, IoT, edge, and CI/CD. That list is the honest scope. If your cluster is one machine, or a handful of machines that need to look like one, MicroK8s is aimed at you. If you are running a fleet with a control plane you never touch, it is not.

The pitch rests on packaging rather than on a rewritten control plane. The README claims compatibility with AKS, EKS and GKE "when you run it on Ubuntu", which is a narrower claim than it first appears: the compatibility story is tied to the Ubuntu runtime, not to arbitrary Linux. The Snap Store page is cited for 42 flavours of Linux, so the snap does install widely, but the Kubernetes API parity claim is scoped to Ubuntu in the project's own wording.

The other thing worth noticing is the add-on list. Service mesh (Istio, Linkerd), serverless (Knative), monitoring (Fluentd, Prometheus, Grafana, Metrics), ingress, DNS, dashboard, clustering, and GPGPU bindings for AI/ML. Each of those is a manifest or script the project maintains, not a third-party chart you pin yourself. That is the real product: a curated set of cluster services with a one-word switch.

One snap, one kubectl wrapper, add-ons as named actions

The architecture is deliberately flat. The snap carries the Kubernetes binaries, the container runtime and the dependencies, so there is no separate package manager step for the cluster itself. The README describes it as having "no moving parts", which is marketing phrasing for a real property: the components are versioned together and updated together.

MicroK8s ships its own kubectl entry point. The README shows `microk8s kubectl` used directly, and separately shows how to merge its kubeconfig into your existing one. That second path matters because it means you are not locked into the wrapper: the cluster exposes a standard kubeconfig, and standard tooling can talk to it.

Add-ons are the extension mechanism. `microk8s enable` turns on a named capability, and `microk8s status` lists what is enabled and what is available. The README points at `${SNAP}/actions/` for the manifests and scripts, with `${SNAP}` defaulting to `/snap/microk8s/current`. That is a useful detail for anyone who wants to read what an add-on actually does before enabling it, rather than trusting a name.

Access control is group-based. Installation creates a `microk8s` user group, and members can run `microk8s` commands. This is a coarse model. There is no per-namespace delegation described in the README; you are either in the group or you are using sudo.

Install MicroK8s on Ubuntu and run your first workload

The README gives the install as a single classic snap. Classic confinement is required because the snap needs access outside its sandbox to manage the cluster.

snap install microk8s --classic

After that, the bundled kubectl is available. The README's first commands check that the node came up and list services.

sudo microk8s kubectl get nodes
sudo microk8s kubectl get services

You should see a single node in Ready state. If you would rather use your own kubectl binary, the README shows how to export the cluster config into the standard location.

sudo microk8s kubectl config view --raw > $HOME/.kube/config

A barebones cluster is what you get at this point. DNS and the dashboard are not on by default; the README is explicit that they are enabled separately.

sudo microk8s enable dns
sudo microk8s enable dashboard

Run `microk8s status` to see which add-ons are enabled and which are still available. To avoid sudo on every command, the README describes adding your user to the group created at install time.

sudo usermod -a -G microk8s <username>

Group membership changes take effect on a new login session, so plan for a re-login or a fresh shell before testing.

Where MicroK8s stops being the right tool

The single-package model is also the main constraint. Because the cluster, its runtime and its dependencies arrive as one snap, you upgrade them as one unit. The README states that automatic updates to the latest Kubernetes version are part of the package, and that security updates "can be applied immediately or scheduled to suit your maintenance cycle". What the README does not document is rollback. There is an `upgrade-scripts/` directory at the top level of the repository, which suggests upgrades are a maintained concern, but the README itself gives no procedure for reverting a version you did not want.

That gap matters most on edge devices. A field unit that silently moves to a new Kubernetes minor version is a different risk profile from a laptop that moves and can be rebuilt. The README's claim that you can "stick to any release version from 1.10 onwards" is the mechanism you would use to control this, but it is stated as a capability, not as a step-by-step pinning recipe.

The group model is the second constraint. Membership in the `microk8s` group grants access to microk8s commands, and the README does not describe a narrower role. On a shared workstation or a CI runner that multiple people can reach, that is effectively cluster-admin for everyone in the group. If your organisation needs per-user or per-namespace boundaries at the tooling level, this is not the distribution that provides them.

Finally, the README's compatibility framing is Ubuntu-centric. Running the snap on another of the 42 supported Linux flavours may work, but the API-parity claim against managed clouds is written for Ubuntu. Treat non-Ubuntu deployments as something you validate yourself.

MicroK8s vs k3s and minikube: three different bets

The two comparisons people actually search for are k3s and minikube, and the differences are structural rather than cosmetic.

Minikube is built around local development. Its model is a VM or container that hosts a cluster for a single developer, with drivers for different hypervisors. MicroK8s instead installs directly onto the host through the snap and expects to be the cluster on that machine, with a user group controlling access. If your goal is a disposable cluster per developer that gets torn down and recreated, minikube's lifecycle matches that; MicroK8s is closer to a long-lived node you keep running.

k3s is the closer comparison, because both aim at small footprints and edge deployment. The packaging differs: MicroK8s is a snap with add-ons enabled by name, while k3s is distributed as a single binary. That distinction drives everything downstream. A snap brings the snapd refresh model, channel selection, and classic confinement; a binary brings whatever upgrade and service management you build around it. MicroK8s also leans on its curated add-on catalogue, where the project maintains the manifests. With k3s you assemble the equivalent stack yourself.

Neither is strictly better. If you already run Ubuntu at scale and want cluster services to arrive as named switches with the project owning the manifests, MicroK8s fits. If you want a single artifact you can drop onto a non-Ubuntu system and manage with your own tooling, the snap model is working against you.

Maintenance, version cadence and the licence

The repository is not archived, and the last push was on 2026-09-21. Release tags show a steady cadence: v1.34 on 2025-09-01, v1.35 on 2025-12-19, and v1.36 on 2026-05-25. That is roughly two releases a year on the tagged line, with the README separately claiming that beta, RC and final bits are released the same day as upstream Kubernetes.

Those two statements describe different things and it is worth keeping them apart. The release tags are the project's own versioned drops. The same-day tracking claim is about how quickly upstream Kubernetes changes appear in the snap channels. If you need a specific upstream patch level, the channel you select is what determines it, not the tag name.

Upgrade cost is dominated by the snap refresh model. Because everything ships together, a refresh moves the cluster and its dependencies at once. The README says updates can be applied immediately or scheduled, which is the lever you have. There is no documented rollback, so the practical safeguard is testing the refresh on a non-critical node first. The presence of `upgrade-scripts/` in the repository indicates the project maintains upgrade logic, but the README does not describe what those scripts do or when they run.

The licence is Apache-2.0, which is permissive and includes an explicit patent grant. That is the same licence family as upstream Kubernetes, so combining MicroK8s with Kubernetes ecosystem tooling raises no new licensing question in principle. This is a description of the licence text, not legal advice; if you redistribute the snap or bundle it into a product, read the Apache-2.0 terms and the Snap Store distribution terms yourself.

Editorial conclusion

Adopt MicroK8s when you want a conformant Kubernetes on a Linux box, especially Ubuntu, with add-ons turned on by name instead of a chart pile. Do not adopt it if you need a non-Linux control plane, or if you cannot give the microk8s group and sudo access to the people who will run kubectl. Before rollout, verify three things on your own hardware: that the snap channel you want exists for your architecture, that the add-ons you need appear in microk8s status output after enabling, and that your upgrade window matches the snap refresh schedule, since the repository documents refresh behaviour but no rollback path.

Frequently asked questions

Official sources

1. canonical/microk8s on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases