Running Kubernetes on Raspberry Pi — the real cost and the real lessons

Every homelab blog post starts the same way. A photo of a neat stack of Raspberry Pis, LEDs glowing, followed by kubectl get nodes showing everything Ready. What you don’t see is the six weeks of dead SD cards, missing ARM64 images, and late nights debugging storage mounts that got them there.

This is what it actually looks like, costs included.

The hardware and what it actually costs

My current cluster is four Raspberry Pi 5 nodes (8GB each). Three are control-plane-capable workers, one is a dedicated worker for heavier tasks. Here’s the honest bill of materials:

• 4x Raspberry Pi 5 8GB: ~€340
• 4x NVMe SSD (256GB) + USB 3.0 enclosures: ~€160
• 1x Ubiquiti USW-Lite-8-PoE switch: ~€110
• 4x PoE+ HATs: ~€80
• Cabling, standoffs, a small rack shelf: ~€40
• Synology DS220+ NAS (shared storage): ~€300

Total: roughly €1,030. That’s not cheap. Anyone who tells you a Pi cluster is a budget alternative to cloud compute is leaving out half the receipt. The NAS alone costs more than a year of a small cloud VM. But the point was never to save money. It was to learn by operating something real.

K3s, not K8s

Full Kubernetes on a Raspberry Pi is technically possible. It’s also a terrible idea. The kubelet, API server, etcd, kube-proxy, and the various controllers will eat 1.5-2GB of RAM before you deploy a single pod. On a 8GB node, that’s a quarter of your resources gone to overhead.

K3s fixes this. It’s a single binary that replaces etcd with SQLite (or embedded etcd for HA), bundles the Helm controller, and strips out cloud-provider integrations you don’t need on bare metal. My control plane nodes idle at around 400-500MB for the K3s process. That leaves actual room for workloads.

Installation is one command: curl -sfL https://get.k3s.io | sh -. Worker nodes join with a token. The whole cluster was running in under ten minutes. Compare that to kubeadm, which took me an entire Saturday the first time I tried it on ARM.

The ARM64 image problem

This is the part that burns the most time and nobody warns you about upfront. Not every Docker image ships an ARM64 variant. Some popular images are amd64-only. Some technically have ARM builds but they’re broken or months behind the latest release.

A few things I learned the hard way:

Check the image manifest before you plan a deployment. docker manifest inspect will show you the supported architectures. If linux/arm64 isn’t listed, you’re building it yourself or finding an alternative.

Multi-arch builds on the Pi itself are painfully slow. Cross-compiling with docker buildx on a more powerful machine and pushing to a registry works better. I keep a small CI job on my desktop that builds ARM64 images for the handful of services that don’t offer them.

Some Helm charts hardcode amd64 image references. You’ll need to override the image tag or repository in your values. This is where GitOps helps, because those overrides are tracked in Git and you won’t forget them next time you upgrade.

Storage will humble you

I started with SD cards. Don’t do this. My first cluster lost data twice in three months. SD cards aren’t designed for the write patterns that container runtimes and databases generate. The second time a card died mid-write and corrupted the filesystem, I ordered NVMe drives that same evening.

NVMe over USB 3.0 is the sweet spot for Pi clusters. You get reasonable IOPS without needing custom hardware. Boot from NVMe using the Pi 5’s built-in USB boot support, and SD cards become a non-issue.

For persistent data, everything goes to my Synology NAS. Kubernetes PersistentVolumes backed by NFS or Samba mounts on the NAS. This matters because local storage on a Pi node is a trap. If that node dies, your data goes with it. With NAS-backed storage, any node can pick up the workload.

The tricky part is performance. NFS over a gigabit link is fine for document storage and config files. It’s not fine for database write-ahead logs. PostgreSQL goes on a node with local NVMe, and I accept the single-point-of-failure trade-off for a homelab.

Power, thermals, and the “cheaper than cloud” myth

I measured actual power draw with a smart plug. The four Pi 5 nodes plus the switch pull about 35-40 watts at typical load. The NAS adds another 25 watts. That’s roughly 65 watts total, which works out to about €15/month at German electricity prices.

A comparable cloud setup, four small VMs with a managed Kubernetes service and some block storage, would run €80-120/month depending on the provider. So yes, the Pi cluster is cheaper month-to-month after about a year. But you’re paying for it in time. Every hour spent debugging an ARM image compatibility issue or replacing a dead SD card is an hour you wouldn’t spend on a managed service.

Thermals are manageable. The Pi 5 runs warmer than the Pi 4, but with the active cooler that comes with the official case, I haven’t seen throttling under normal workloads. Sustained CPU-heavy builds can push temps to 75-80°C. A small USB fan on the rack shelf keeps ambient temperature reasonable.

What I’d do differently

NVMe from day one, no exceptions. I wasted weeks dealing with SD card failures that were entirely preventable. The cost difference is small compared to the frustration.

Budget more for networking. I started with a basic unmanaged switch and had to upgrade when I needed VLANs for network segmentation. Buying the PoE switch from the start would have saved me a swap.

Start with two nodes, not four. You don’t need a four-node cluster to learn Kubernetes. Two nodes teach you scheduling, affinity, and failover. Scale up when you actually need the capacity.

The real point

I don’t run production on Raspberry Pis. That’s not the goal. The goal is building muscle memory with Kubernetes, GitOps, networking, and storage that transfers directly to real clusters at work.

When something breaks in production and I need to debug a PersistentVolumeClaim that won’t bind or a pod stuck in CrashLoopBackOff, I’ve already seen that failure mode at home. The fix comes faster because it’s not the first time. That’s worth more than the €1,000 hardware cost. It’s the lab work that makes the theory stick.