Running a k3s Kubernetes Cluster on Raspberry Pi 5

Kubernetes at homelab scale, without the overhead

Running a k3s Kubernetes cluster on a Raspberry Pi 5 is a genuinely practical homelab project in 2026, not the fragile experiment it would have been a couple of years ago. Full Kubernetes is overkill for a homelab, but k3s – Rancher’s lightweight, single-binary distribution – was built specifically for resource-constrained environments like a Pi cluster, and the Pi 5 ecosystem has matured enough that the hardware side isn’t fighting you the way it did for early Pi 5 adopters. Stable PCIe support, widely available NVMe HATs, and resolved Docker/container tooling issues all help.

Why k3s specifically, not full Kubernetes

• Single binary, minimal dependencies – a fraction of full Kubernetes’s memory footprint, which matters directly on Pi-class hardware
• Ships with sensible homelab defaults built in – a lightweight local storage provisioner and Traefik as an ingress controller, so you’re not assembling every component separately
• Uses SQLite by default for small clusters instead of requiring a separate etcd cluster, though it supports etcd or an external database if you outgrow that
• ARM64 support is first-class, not an afterthought – it runs the same on Pi hardware as it does on any other ARM64 node

What you’ll need

• At least two Raspberry Pi 5 boards (one control-plane node, one or more workers – a single node works but defeats the point of “cluster”)
• NVMe storage via a PCIe HAT rather than SD cards – SD card I/O is a real bottleneck once you’re running actual workloads, not just experimenting
• A dedicated switch or VLAN for cluster traffic if you’re running more than a couple of nodes, to keep cluster chatter off your main home network
• Static IPs or DHCP reservations for every node – Kubernetes clusters do not appreciate nodes changing address

Getting a cluster running

1. Flash Raspberry Pi OS Lite (64-bit) to each node – you don’t need a desktop environment on cluster nodes.
2. On the first node, install k3s as the server: curl -sfL https://get.k3s.io | sh -
3. Grab the node token for joining workers: sudo cat /var/lib/rancher/k3s/server/node-token
4. On each additional node, join as an agent: curl -sfL https://get.k3s.io | K3S_URL=https://<server-ip>:6443 K3S_TOKEN=<token> sh -
5. Confirm the cluster’s up from the server node: sudo k3s kubectl get nodes

What’s actually worth running on it

• Self-hosted apps you’d otherwise run as one-off Docker containers – Pi-hole, a small internal wiki, monitoring dashboards – now with proper rolling updates and restart-on-failure instead of a bare docker run
• A genuine sandbox for learning real Kubernetes concepts (deployments, services, ingress, persistent volumes) on hardware you own outright, rather than burning cloud credits
• CI/CD runners for personal projects, scaled across nodes rather than tied to a single always-on machine
• A practical testbed for GitOps tooling (Argo CD, Flux) at a scale small enough to fully understand what’s happening end to end

Where it stops making sense

If your actual goal is just “run a few self-hosted apps reliably,” plain Docker Compose on a single Pi is simpler and arguably a better fit – Kubernetes adds real operational complexity (networking model, RBAC, the whole controller/reconciliation mental model) that only pays off once you’re managing enough moving pieces that the orchestration itself becomes valuable. The honest case for k3s on a Pi cluster is either genuinely wanting multi-node resilience for something that matters to you, or wanting hands-on Kubernetes experience without a cloud bill attached. Both are legitimate reasons; “because it’s there” isn’t quite enough on its own to justify the added complexity.