Kubernetes Ecosystem: From User to Contributor, Episode 3
← EP02: Minikube · EP03: k3s vs MicroK8s vs Minikube · EP04: Rancher →
10 min read
TL;DR
- k3s vs MicroK8s vs Minikube comes down to one question first: do you need this to run in production on real hardware (k3s, MicroK8s), or only on a developer’s laptop (Minikube)?
- k3s (built by Rancher, now part of SUSE) is a single ~70MB binary using SQLite or embedded etcd, designed explicitly for edge and IoT production deployments, not just local dev
- MicroK8s (Canonical) is a snap-packaged cluster using Dqlite for HA — covered in EP01 — closer to k3s in intent than to Minikube
- Minikube is the odd one out here: it’s VM/container-isolated and explicitly a local development tool, not something you’d run in production
- Recommendation: for production edge/IoT, pick k3s or MicroK8s based on your packaging preference (binary vs snap) and datastore comfort (SQLite/etcd vs Dqlite); for local development and CI, pick Minikube when you need real isolation, or either k3s/MicroK8s when you just need “a cluster, fast”
- Contribution opportunity: none of the three has a first-class way to migrate a running cluster’s workloads to another — a real, currently-unfilled gap
The Big Picture
k3s MicroK8s Minikube
──── ──────── ────────
Packaging Single binary Snap package VM/container
Intended for Edge/IoT prod Edge/IoT prod Local dev only
Datastore (HA) SQLite / etcd Dqlite etcd (per-node)
Multi-node HA Yes Yes No (single profile
node, though multi-
profile exists)
Isolation from host None (bare) None (bare) Full (VM or
container boundary)
Default footprint ~70MB binary ~200MB snap 500MB-1GB+ VM/image
Add-on model Helm charts snap add-ons minikube addons
via manifests
k3s vs MicroK8s vs Minikube isn’t really a three-way tie — it’s two production-oriented, bare-metal tools (k3s, MicroK8s) and one deliberately isolated local-dev tool (Minikube) that happen to get compared because all three market themselves as “lightweight Kubernetes.”
Architecture at a Glance
k3s strips Kubernetes down to a single binary by removing in-tree cloud provider integrations, dropping alpha features, and swapping etcd for embedded SQLite by default (though it supports real etcd or external datastores for HA). It was purpose-built by Rancher Labs for resource-constrained edge devices and CI, and that heritage still defines its design decisions today.
MicroK8s — covered in full in EP01 — takes a different packaging route (a snap bundle rather than a single binary) but lands in almost the same use-case space: edge, IoT, and CI, with its own HA datastore (Dqlite) instead of etcd.
Minikube — covered in EP02 — is architecturally unlike either: it isolates the entire cluster inside a VM or container specifically so your laptop’s Kubernetes environment doesn’t interact directly with your laptop’s actual kernel and network stack. That isolation is a feature for local development and actively unwanted overhead for a production edge deployment.
Resource Footprint: What Each One Actually Costs to Run
# k3s — single binary, starts in seconds, minimal base memory
$ curl -sfL https://get.k3s.io | sh -
$ k3s kubectl get nodes
NAME STATUS ROLES AGE VERSION
my-node Ready control-plane,master 12s v1.28.5+k3s1
# MicroK8s — snap install, slightly heavier than k3s due to bundled containerd/Dqlite
$ sudo snap install microk8s --classic
$ microk8s status --wait-ready
# Minikube — heaviest by design, provisions a full VM or container first
$ minikube start --driver=docker
# (30-90 seconds depending on driver, before Kubernetes even starts booting)
On a resource-constrained edge device (a Raspberry Pi, an industrial gateway), the difference between k3s’s ~70MB binary and Minikube’s VM-based footprint isn’t a rounding error — it’s the difference between fitting on the device at all and not. This is why Minikube essentially never appears in edge deployment discussions: it was never built for that use case.
The Add-on / Component Model Compared
| k3s | MicroK8s | Minikube | |
|---|---|---|---|
| CNI | Flannel (default), swappable | Calico (default), swappable via add-on | Varies by driver, addon-enabled |
| Ingress | Traefik (bundled by default) | nginx via add-on | nginx via addon |
| Storage | local-path-provisioner (bundled) | hostpath-storage add-on | default-storageclass addon |
| Extending | Standard Helm charts, manifests | microk8s enable <addon> |
minikube addons enable <name> |
k3s ships more “batteries included” by default (Traefik and local-path storage are on unless you disable them) — a meaningfully different default posture from MicroK8s and Minikube, which both start closer to bare and expect you to opt in to what you need.
Recommendation: Which One Actually Fits Your Use Case
Running Kubernetes on real edge/IoT hardware in production: choose between k3s and MicroK8s based on packaging preference and datastore comfort, not raw features — they solve the same problem. If you’re already inside the snap ecosystem (Ubuntu Core, other Canonical tooling) or want a specific datastore, MicroK8s’s Dqlite. If you want the smallest possible footprint and the option of real etcd for HA, k3s. If you’re evaluating Rancher for fleet management (EP04), note that Rancher created k3s specifically to be its default downstream cluster type — that pairing has more operational precedent than any other combination here.
Local development, testing against something close to a real cloud node: Minikube, specifically when you need the VM isolation boundary — testing kernel-adjacent behavior, simulating a genuinely separate node, or needing multiple isolated profiles side by side.
CI pipelines needing a disposable cluster fast: k3s’s single-binary startup is hard to beat for raw speed; MicroK8s’s snap install is a close second. Minikube is the wrong tool here unless the CI environment specifically needs VM-level isolation for security reasons.
Don’t pick based on “most popular” or “newest” alone — all three are actively maintained, CNCF-conformant, and the “right” one is entirely determined by whether you’re targeting production hardware or a local workstation.
⚠ Production Gotchas
k3s’s default SQLite datastore is single-node only — HA requires explicit configuration. Don’t assume curl | sh gives you production HA out of the box; it gives you a working single node, and HA (embedded etcd or external datastore) is a deliberate follow-up step.
Comparing “footprint” numbers from marketing pages is misleading without matching workloads. A k3s binary’s on-disk size and MicroK8s’s snap size aren’t measuring the same thing (a binary vs. a bundle including containerd and a datastore) — benchmark actual running memory under your real workload, not install-time size.
None of these three are drop-in replacements for each other operationally, despite the “lightweight Kubernetes” label all three carry. Add-on names, default CNI, and default ingress all differ — migrating a manifest set between them is not guaranteed to work unmodified.
Quick Reference
# k3s
curl -sfL https://get.k3s.io | sh -
k3s kubectl get nodes
sudo systemctl status k3s
# MicroK8s
sudo snap install microk8s --classic
microk8s status --wait-ready
microk8s kubectl get nodes
# Minikube
minikube start --driver=<docker|kvm2|hyperkit|virtualbox>
minikube status
kubectl get nodes # uses minikube's kubeconfig context directly
Contribution Opportunity: No First-Class Migration Path Between Them
The limitation: If you outgrow Minikube for local dev and want to mirror your production k3s environment more closely, or you’re running MicroK8s at the edge and want to evaluate switching to k3s, there’s no tooling in any of the three projects that translates the other’s add-on configuration, ingress setup, or storage class definitions into its own equivalent. You’re reproducing configuration by hand, from documentation, project by project.
Why it’s hard to fix: Each project’s add-on/component model evolved independently, solving the same category of problem (ingress, storage, networking) with different defaults and different configuration surfaces — there’s no shared standard to translate through, and no single maintainer group owns “compatibility between lightweight Kubernetes distros” as a problem, because each project’s maintainers are reasonably focused on their own users, not on easing exit to a competitor.
What a contribution-shaped fix looks like: A standalone, community-maintained translation tool or even a well-structured comparison-and-migration guide (living in a neutral location like a CNCF sandbox project or a widely-referenced GitHub repo, not owned by any one vendor) that maps common add-on configurations (ingress-nginx settings, storage class parameters, CNI policy syntax) between the three. This doesn’t require deep contribution to any single project’s core — it requires someone who has actually run workloads on more than one of these and is willing to document the translation precisely, which is exactly the kind of gap a practitioner (not a maintainer) is best positioned to fill.
Key Takeaways
- k3s and MicroK8s are both production-oriented, bare-metal tools for edge/IoT; Minikube is a deliberately isolated local-dev tool — they’re not really three-way competitors on the same axis
- k3s’s single-binary packaging and MicroK8s’s snap packaging solve the same problem differently — pick based on ecosystem fit and datastore preference, not raw capability
- Minikube’s VM/container isolation is the right tool specifically when you need a real isolation boundary for local testing, not for general “I want Kubernetes on my laptop”
- Default component choices differ meaningfully (Traefik vs nginx, bundled storage vs addon-based) — verify defaults before assuming any two of these behave the same out of the box
- The most concrete, currently-unfilled contribution opportunity is configuration translation between the three — a documentation and tooling gap any experienced user could start closing
What’s Next
k3s was built by Rancher as the default cluster type for its own fleet-management platform. EP04 covers Rancher itself — what it actually does when you’re managing more than one cluster, and where its own control plane becomes another thing you have to operate.
Next: EP04 — Rancher: Multi-Cluster Kubernetes Management at Scale
Get EP04 in your inbox when it publishes → linuxcent.com/subscribe
