pi-tower

Six Raspberry Pi 4s in a rack I designed and printed, running k3s. It's older hardware on a gigabit network, and it is not fast. I've stopped treating that as a flaw.

Why constrained hardware is the point

The homelab is split in two. An Unraid box holds everything I'd be annoyed to lose and runs the services the household depends on. That machine has to work. This cluster is the other half: the one I'm allowed to break, at 11pm, on a Tuesday, without apologising to anyone.

Constrained hardware earns its keep in that role. Memory pressure, slow disks and a control plane that genuinely notices when a node goes away are all things a generous machine hides from you. Nearly everything I've learned here has transferred upward to clusters where the stakes were considerably higher.

The storage situation

Each node boots from an SSD. One node additionally has a USB-attached SSD exposed as a physical volume to the cluster, which is how anything needing real persistence gets it.

What's next

NVMe hats. I expect storage latency to be the constraint that matters most, more than any tuning I could do first, but that's a hypothesis, not a result, and it stays on the list until I've measured it.