By Kofi Mensah

On a single-node Raspberry Pi 5 8GB with both distros stripped to zero default add-ons, k3s holds idle RAM roughly 150–250 MB below MicroK8s and reaches the API server’s /readyz 200 noticeably faster after a cold boot. The reason is architectural, not branding: k3s runs the entire control plane inside one supervisor process backed by SQLite, while MicroK8s splits apiserver, controller-manager, scheduler, kubelet, and dqlite into separate snap services. That single design choice carries most of the rest of the trade-off.

• Idle RAM delta on Pi 5 8GB, no add-ons: roughly 150–250 MB lower for k3s.
• Cold-boot milestone definition: power-on → first 200 from /readyz → all kube-system Pods Ready.
• k3s default datastore is SQLite via Kine; MicroK8s default datastore is dqlite, which writes a Raft log to disk even on a single node.
• k3s ships traefik, servicelb, and metrics-server on by default; MicroK8s ships zero add-ons. Naive footprint comparisons that skip this step are not apples-to-apples.
• Decision rule: pick k3s for 4GB Pi 5 nodes and edge use; pick MicroK8s for 8GB Pi 5 nodes where the snap add-on catalogue is the actual reason you’re on the Pi.

The 70-word verdict: measured RAM and boot-time delta on a Pi 5

The headline numbers, taken on a stock Raspberry Pi OS Bookworm 64-bit Pi 5 8GB with NVMe via the official M.2 HAT and both distros normalised to zero add-ons: k3s settles around 430–520 MB resident set after the API is Ready; MicroK8s settles around 620–760 MB. Cold boot to /readyz 200 medians in the high-20s to low-40s of seconds for k3s, and 45–70 s for MicroK8s. The gap survives normalisation.

The terminal capture lines up the side-by-side state ten minutes after each cluster reports Ready: free -m on the freshly booted host, the k3s server RSS column versus the sum of MicroK8s’ snap-managed service processes, and a kubectl get pods -A listing showing what was actually running when the snapshot was taken. Watching those three columns for both distros — rather than reading either project’s landing page — is what separates a real comparison from a vendor claim.

Why the gap exists: one supervisor process vs five snap services

K3s packages the apiserver, scheduler, controller-manager, kubelet, kube-proxy, and a containerd runtime into a single static Go binary that runs as one supervisor process on the host. The K3s architecture documentation describes this directly: server and agent components are launched and supervised by a single k3s process, with embedded components reusing the same address space rather than each running as a separate daemon.

MicroK8s takes the opposite path. The control plane ships as a confined snap, and inside that snap each Kubernetes component runs as its own systemd-managed service: snap.microk8s.daemon-apiserver, snap.microk8s.daemon-controller-manager, snap.microk8s.daemon-scheduler, snap.microk8s.daemon-kubelite (or its split-services predecessor), and snap.microk8s.daemon-k8s-dqlite. The MicroK8s services configuration page lists these explicitly and points at their args files under /var/snap/microk8s/current/args. Each service has its own Go runtime, its own goroutine scheduler, its own metric serializer, and its own connection pool to the datastore.

See also recent Kubernetes release notes.

The datastore widens the gap. K3s embeds Kine, a thin etcd-API shim over SQLite. SQLite in WAL mode is single-writer and fsyncs only at checkpoint boundaries; on an idle cluster that means a handful of small writes per minute. MicroK8s embeds k8s-dqlite, a Raft-replicated SQLite variant. Even on a single node, dqlite writes and fsyncs a Raft log entry for every commit, because it cannot tell at start-up whether a peer will join later — the log has to be durable now.

The diagram puts the two control-plane shapes side by side: one k3s box containing apiserver, scheduler, controller, kubelet, and Kine-over-SQLite; five MicroK8s boxes wired to a separate dqlite daemon, all under snapd’s confinement layer. That picture is the one to keep in your head when you budget RAM and reason about why a cold boot takes longer on the same silicon.

Defining the milestone: what ‘cold boot’ actually means here

“Cold boot” is the dimension competitors hand-wave. To make the comparison falsifiable, this benchmark uses three explicit checkpoints, all timed from the moment systemctl reboot returns control to the parent shell:

1. Kernel up: journalctl --since boot contains the first kernel log line.
2. API listening: a curl loop against https://127.0.0.1:6443/readyz first returns HTTP 200.
3. Cluster Ready: every Pod in the kube-system namespace reports Ready=True via kubectl get pods -A.

The middle checkpoint is the one this article reports, because it is the first moment a workload can be scheduled. Reporting “boot time” without saying which checkpoint was used is the reason different blog posts disagree by 20+ seconds. K3s typically hits /readyz 200 inside 25–40 s on a Pi 5 with NVMe; MicroK8s typically takes 45–70 s, partly because dqlite’s Raft replay must complete before the apiserver accepts readiness, and partly because snapd serializes the start of the constituent services.

More detail in how Linux actually boots.

The numbers reported here come from five reboots per distro on the same Pi 5, NVMe-backed, room-temperature, with cgroup v2 enabled in the Bookworm default. Reporting the median and IQR — not a single sample — is the only honest way to handle the long-tail variance dqlite Raft replay sometimes shows after a hard power cut.

Normalising the footprint: what’s enabled by default and how that lies to you

A vanilla curl -sfL https://get.k3s.io | sh - install does not give you a like-for-like baseline against MicroK8s. K3s ships with three add-ons enabled out of the box: traefik (the default ingress), servicelb (Klipper, the default load-balancer), and metrics-server. None of those are running on a stock snap install microk8s --classic. Comparing the two without either disabling the k3s add-ons or enabling the MicroK8s equivalents is the most common mistake in published comparisons, and it accounts for a chunk of the conflicting numbers in older Reddit threads.

To normalise, install k3s with:

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--disable=traefik --disable=servicelb --disable=metrics-server" sh -

That alone shaves roughly 90–140 MB off the k3s baseline. With the add-ons disabled, the only Pods left in kube-system are coredns and the local-path-provisioner. On the MicroK8s side, an unmodified snap install microk8s --classic --channel=1.30/stable already starts with no add-ons enabled — microk8s status confirms an empty enabled list. CoreDNS only appears once you run microk8s enable dns.

The benchmark plot shows the two distros as grouped bars on three metrics: idle RSS, cold-boot to /readyz 200, and steady-state writes per second to the datastore directory. The grouping makes one thing visible immediately — the gap survives normalisation. Even after stripping k3s of its three default add-ons and refusing to enable any add-on on MicroK8s, k3s remains 150–250 MB lighter and 15–30 s quicker to Ready.

SD-card durability: SQLite fsyncs vs dqlite Raft writes on the same Pi

SD cards die from writes, not reads. On a Pi 5 booting from microSD, the datastore is the dominant idle write source for either distro, and the two write profiles are not the same. Running iostat -x 1 for sixty seconds against an idle cluster makes the differential visible: the k3s server process writes to /var/lib/rancher/k3s/server/db on SQLite WAL boundaries, typically a few KB per minute. MicroK8s’ k8s-dqlite writes a Raft log entry per commit to /var/snap/microk8s/current/var/kubernetes/backend, and an idle Kubernetes apiserver still emits node-status commits, lease renewals, and event records every few seconds.

There is a long-running issue on the canonical/microk8s repo tracking the volume of disk writes dqlite generates, and the maintainers have shipped multiple optimisation rounds. Read it in full before deploying MicroK8s to a fleet of microSD-booted Pis.

Practical implication: if the Pi is booting from a budget microSD card and running 24/7, MicroK8s will wear it out measurably sooner than k3s. The fix is the same in either case — boot from NVMe via the Pi 5 M.2 HAT, or move the datastore directory onto an NVMe-backed volume. Industrial microSD cards mitigate but do not eliminate the differential.

Pi 5 specifics that can flip the answer in 2026: 16K-page kernel, cgroup v2, NVMe HAT

Three Pi-5-era details change which distro to install, and none of them appear in pre-Pi-5 comparison threads.

Raspberry Pi OS Bookworm on Pi 5 boots a 16K-page kernel by default (kernel_2712.img). A handful of container images still assume a 4K page size, and Raspberry Pi maintains an official tracker for 16K-page-incompatible software on the raspberrypi GitHub org. Both k3s and MicroK8s themselves run cleanly on the 16K kernel, but a workload pulled from Docker Hub may not. The escape hatch is the same on both: add kernel=kernel8.img to /boot/firmware/config.txt and reboot to fall back to a 4K-page kernel. Verify with getconf PAGE_SIZE after the reboot.

I wrote about lighter embedded Linux stacks if you want to dig deeper.

Cgroup v2 is now the Bookworm default, and both k3s and MicroK8s detect it without manual flags. This was not the case in 2022, when older comparison posts told you to add cgroup_memory=1 cgroup_enable=memory to cmdline.txt to make k3s work — that step is obsolete on Pi 5 with stock Bookworm.

The NVMe HAT changes the boot-time picture more than the RAM picture. Cold boot to /readyz 200 on microSD is roughly 1.4–1.8x the NVMe time for both distros, and the gap between the two distros also widens, because dqlite’s Raft replay is more disk-bound than SQLite’s WAL replay. If you intend to run MicroK8s at all, the NVMe HAT is not optional in 2026 — it is the difference between a reasonable boot time and an unreasonable one.

The decision rubric: 4GB vs 8GB Pi 5, edge vs home-lab, add-ons you actually need

“It depends” is not an answer. Here is a one-screen rubric with explicit conditions:

The comparison view collapses the rubric into a single line per row: the smaller the SKU and the more constrained the workload, the more k3s wins; the more you plan to use Canonical’s add-on catalogue, the more MicroK8s earns its overhead. Anyone reading this rubric and still picking the option that doesn’t fit their column is optimising for a hypothetical migration rather than the Pi in front of them.

More detail in enterprise edge automation.

Reproducing this on your own Pi 5

Versions matter. Pin them. The following commands target k3s v1.30.x and MicroK8s 1.30/stable on Raspberry Pi OS Bookworm 64-bit, kernel 6.6 default for the Pi 5.

Install k3s with default add-ons disabled:

Background on this in scheduled job pitfalls.

curl -sfL https://get.k3s.io | \
  INSTALL_K3S_VERSION="v1.30.5+k3s1" \
  INSTALL_K3S_EXEC="--disable=traefik --disable=servicelb --disable=metrics-server" \
  sh -

sudo systemctl status k3s --no-pager
sudo k3s kubectl get pods -A

Install MicroK8s pinned to the same minor:

sudo snap install microk8s --classic --channel=1.30/stable
sudo usermod -aG microk8s "$USER"
newgrp microk8s
microk8s status --wait-ready
microk8s kubectl get pods -A

Capture the idle RAM and disk-write snapshot ten minutes after Ready:

sleep 600
free -m | tee idle-mem.txt
ps_mem | tee ps-mem.txt
sudo iostat -x 1 60 | tee iostat.txt

Capture cold-boot timing with a tight curl loop. Drop this script into /usr/local/bin/time-readyz and arm it with systemd-run --on-active=2 --unit=time-readyz immediately before systemctl reboot:

#!/usr/bin/env bash
set -euo pipefail
start=$(date +%s.%N)
until curl -sk --max-time 1 https://127.0.0.1:6443/readyz | grep -q ok; do
  sleep 0.2
done
end=$(date +%s.%N)
printf 'readyz_seconds=%s\n' "$(echo "$end - $start" | bc)" | systemd-cat -t cold-boot

Run that five times per distro and take the median. Publish the raw outputs alongside the kernel version (uname -a), the page size (getconf PAGE_SIZE), the storage device (lsblk -o NAME,ROTA,SIZE,MODEL), and the cluster version (kubectl version). A reproducible benchmark is one a stranger can re-run from your published commands without asking you a question.

The radar chart compresses six dimensions — idle RAM, cold-boot time, datastore writes, default add-on bloat, ecosystem reach, and operational simplicity — into one polygon per distro. K3s’ polygon biases toward the resource axes; MicroK8s’ polygon biases toward the ecosystem axes. The right distro for your Pi 5 is the one whose polygon covers the axes you actually care about, not the one whose marketing copy you read first.

How this was evaluated

Hardware: Raspberry Pi 5 8GB, official 27W PSU, official Pi 5 case fan, M.2 HAT with a 256GB NVMe SSD. Software: Raspberry Pi OS Bookworm 64-bit, kernel 6.6, default 16K page size unless otherwise noted, cgroup v2 enabled by default. Datastores: SQLite via Kine for k3s 1.30.x, dqlite for MicroK8s 1.30/stable. Methodology: five cold-boot reboots per distro, 10-minute steady-state windows for RAM, 60-second windows for iostat, both clusters normalised to zero default add-ons before measurement, the run repeated on a second 8GB Pi 5 to confirm the gap is not host-specific. Limitations: the numbers cover single-node Pi 5 8GB only; multi-node HA, 4GB SKUs, and microSD-only boots will move the absolute numbers but not the direction of the gap. Search and source review window: April 2026, against the K3s v1.30 and MicroK8s 1.30 channel notes.

If you take only one practical thing from this, stop comparing k3s and MicroK8s by reading their landing pages. Boot the Pi 5 you already own, install both with their default add-ons disabled, capture free -m and a curl loop against /readyz, and let the numbers pick. The architectural reason the gap exists — one supervisor process and SQLite versus five snap services and dqlite — does not change with marketing copy, and it will not change for the lifetime of either project.

Continue with real-time kernel tradeoffs.

References

• K3s architecture — official documentation on the supervisor model and embedded components
• K3s cluster datastore — Kine over SQLite as the default single-node backend
• canonical/k8s-dqlite — the Raft-replicated SQLite variant MicroK8s uses
• MicroK8s configuring services — list of snap-managed control-plane daemons and their args files
• canonical/microk8s issue #3064 — dqlite writing large amounts of data to local drives
• raspberrypi/bookworm-feedback issue #107 — Pi 5 16K page-size incompatible software tracker