I built a Raspberry Pi cluster. Four nodes, a stacked acrylic case, little fans, a switch, the works. I told myself it was to learn Kubernetes properly, on real hardware, where the failure modes are honest. What I actually learned was almost nothing of practical use, and I had a wonderful time, and I think that is allowed.
Let me be clear about the premise before anyone writes in. You do not need a Pi cluster to learn Kubernetes. You can run k3d or kind on your laptop and get a more capable cluster in ninety seconds, with more RAM, faster disks, and no risk of a power supply browning out under load. If your goal is genuinely to learn Kubernetes the fast way, do that. Close the tab. Spend the money on something else.
I did not want the fast way. I wanted the version with cables.
the build
Four Raspberry Pi 4s, the 4GB model, because the 8GB ones were silly money and hard to get hold of this year anyway. A stackable case with standoffs and a 30mm fan per layer. A small unmanaged gigabit switch. Four short Ethernet patch leads in matching colours, because if you are going to do something pointless you should at least do it tidily. Four USB-C power leads into a single multi-port supply, which I will come back to, because it was a mistake.
The assembly is the fun part. There is real satisfaction in standoffs and ribbon-thin fan leads and getting four identical boards to sit square. It is Lego for people who have a soldering iron and feel guilty when it is cold.
I flashed Raspberry Pi OS Lite onto four cards, enabled SSH and set the hostnames with the Imager's new advanced options, which this year finally lets you pre-bake the hostname, Wi-Fi and SSH key before first boot. That alone saved the usual dance of plugging in a monitor four times. Static leases on the router, so pi-node-1 through pi-node-4 always come up at known addresses.
the software
I installed k3s, because full upstream Kubernetes on a 4GB ARM board is an exercise in watching things get OOM-killed. k3s is the sensible choice here: it strips out the cloud provider cruft, swaps etcd for sqlite by default, and runs happily in a few hundred megs.
# on node 1, the control plane
curl -sfL https://get.k3s.io | sh -
# grab the token
sudo cat /var/lib/rancher/k3s/server/node-token
# on nodes 2-4
curl -sfL https://get.k3s.io | \
K3S_URL=https://pi-node-1:6443 \
K3S_TOKEN=<token> sh -
A few minutes later, kubectl get nodes showed four Ready nodes, and I felt a completely disproportionate amount of joy. There it was. A real cluster, on real hardware, that I could pick up with both hands.
what it actually does
This is where the honesty comes in. What runs on it? Almost nothing worth mentioning. I deployed a few things to feel like I had:
- A couple of replicas of a "hello world" web service, just to watch the scheduler spread them across nodes.
- Pi-hole, briefly, before deciding I did not want my house's DNS depending on a hobby cluster I planned to break repeatedly.
- A small Prometheus and Grafana stack, mostly so I could draw graphs of the cluster monitoring itself, which is exactly as recursive and pointless as it sounds.
None of this needed a cluster. All of it would run on a single Pi with room to spare. The whole edifice exists to host workloads that do not require it. That is the joke, and I am in on it.
the lessons, such as they were
I did learn a few small, real things, and they are mostly about hardware rather than Kubernetes.
The power supply was the lesson that bit. A single multi-port USB charger does not deliver clean, independent power to four hungry boards under load. When two nodes spun up at once, the voltage sagged enough to throw the little undervoltage lightning bolt and, on one occasion, to reboot a node mid-task. The fix is boring and correct: give each Pi its own proper supply, or use a PoE HAT and a PoE switch so power and data share one tidy cable. I have a PoE switch on a wishlist now, which is precisely how these projects metastasise.
I also learned that ARM is a tax you pay constantly. Plenty of Helm charts and container images still did not ship a clean arm64 variant this year, and you discover this only when a pod sits in ImagePullBackOff looking innocent. It is getting better, but "it works on my laptop" and "it works on four little ARM boards" are not the same statement.
And I relearned the oldest lesson, which is that a thing you have built with your hands and can see blinking on a shelf is more motivating than the same thing as a window on a screen, even when the window is objectively better in every measurable way. The cluster gets used because it is there, looking at me, slightly reproachful.
was it worth it
Did it teach me anything useful? Honestly, no, not much I could not have learned faster elsewhere. Was it worth it? Completely. Not every project has to justify itself on a spreadsheet. Sometimes the deliverable is the afternoon you spent making four small computers agree to be one slightly larger computer, and the quiet pride of seeing four green Ready lines in your terminal. If you have been talking yourself out of building one because it makes no sense, that is the wrong axis. It makes no sense. Build it anyway.