Let me be honest about the conclusion before I waste your time pretending there's a payoff: the Pi cluster taught me nothing I'll ever use at work, solved no problem I actually had, and was one of the most enjoyable weekends I've had with hardware in years. If you need a justification, stop reading. If you've ever wanted to do a thing simply because it would be satisfying to see it run, carry on.
the build
Four Raspberry Pi 4s, the 4GB model, in a stacked acrylic case with a little 40mm fan blowing over the lot. A cheap five-port gigabit switch zip-tied to the side. One USB-C power supply per Pi, because I tried the single-PSU-with-a-splitter approach and was rewarded with undervoltage warnings and a node that rebooted whenever the others got busy. Sometimes the boring answer is the right one.
The fiddly part was tidy power and tidy networking in the same small space. I soldered up a little distribution arrangement, mostly for the pleasure of it, and learned my first genuine lesson: a USB-C power cable that says it carries 3A frequently does not, and the Pi 4 is fussy about exactly this. Half my early instability was cabling, not software. The red lightning bolt in vcgencmd get_throttled is telling the truth even when you'd rather it didn't.
I went with k3s rather than full Kubernetes, which on an ARM single-board computer is the only sane choice. It's a single binary, it's light, and it gets a control plane up without the Pi melting. One node as server, three as agents.
# on the first node
curl -sfL https://get.k3s.io | sh -
# grab the join token
sudo cat /var/lib/rancher/k3s/server/node-token
# on each agent node
curl -sfL https://get.k3s.io | \
K3S_URL=https://192.168.1.50:6443 \
K3S_TOKEN=<token> sh -
Twenty minutes later kubectl get nodes showed four Ready nodes, and I sat there grinning at a terminal like I'd discovered fire.
what i actually ran on it
Here is where the "nothing useful" part earns its keep. I deployed:
- A small web app that does nothing of consequence, so I could watch the scheduler place pods across nodes.
- Pi-hole, briefly, until I remembered I already run that on something more reliable.
- A pod whose only job was to print the hostname, so I could pull a node's power and watch the workload reschedule onto its neighbours.
That last one is the closest thing to a real lesson. Watching a pod evaporate from a dead node and reappear elsewhere a few seconds later is something I'd read about a hundred times and never felt. There's a difference between knowing Kubernetes reschedules workloads and yanking a USB-C cable out of a box on your desk and watching it happen. The textbook says "self-healing". The cluster on the desk says it in a way that sticks.
the honest reckoning
Performance is, predictably, dreadful. Four Pis have less aggregate grunt than the laptop I'm typing this on, the storage is microSD cards that I do not trust further than I can throw them, and a single mid-range mini PC would run circles around the whole stack whilst drawing less power and making no noise. As infrastructure, it is a joke. I would not put anything I cared about on it.
But that was never the point. The point was the wiring, the throttling warnings, the join token finally working, the four green Ready lines. It was a physical, tactile version of a thing I usually only meet as YAML in a pull request, and meeting it physically taught my hands something my head already knew.
So: nothing useful, and I'd do it again tomorrow. The cluster lives on a shelf in the garage now, mostly idle, occasionally pressed into service when I want to test something destructive on hardware I won't cry over. Every homelab needs a box you're allowed to break. Mine just happens to have four of them.