Kubernetes on a stack of Raspberry Pis

Managed Kubernetes hides a lot from you — which is exactly the point, and exactly why I built a cluster on Raspberry Pis. A three-node cluster, one control-plane node and workers, running real applications on my desk. It’s where I experiment with container orchestration and deployment strategies without a cloud bill or a production blast radius.

Why bother, when GKE exists?

Because the abstractions leak eventually, and when they do, you want to have seen what’s underneath. Running your own cluster forces you to deal with things a managed service handles quietly:

How the control plane actually comes up, and what happens when it doesn’t.
How pods find each other across nodes (the container network interface is suddenly your problem).
How storage attaches to workloads that move between machines.
What “node failure” means when you can pull the power cable yourself.

Every one of those lessons has paid for itself in production conversations.

The hardware reality

Raspberry Pis are wonderful and constrained. A few things matter more than you’d expect:

ARM architecture. Not every container image ships an arm64 variant. Multi-arch images, and knowing how to build them, become part of your toolkit.
Storage. SD cards are not designed for the constant small writes that cluster state and logs produce. Booting from SSD makes the cluster far more reliable.
Power and cooling. A throttled Pi looks like a flaky node. Good power supplies and cooling fix a surprising number of “Kubernetes bugs.”
Memory. The control plane competes with workloads for RAM; lightweight Kubernetes distributions exist for exactly this reason.

What can you do with a Raspberry Pi Kubernetes cluster?

The cluster is a sandbox for the deployment patterns I care about professionally:

Rolling updates vs. blue-green vs. canary — watching traffic shift between versions on real hardware makes the trade-offs obvious.
Failure drills — draining nodes, killing pods, unplugging a worker, and checking that workloads reschedule the way the manifests promise.
Resource requests and limits — on small machines, bad sizing shows up immediately as evictions and throttling.
Self-hosted services from the rest of my home lab, orchestrated instead of hand-started.

What it taught me about platforms

Constraints are the best teacher. A cluster of small ARM boards won’t let you hide sloppy resource management behind a bigger instance type.

The habits I built here — right-sizing workloads, treating failure as routine, and designing for machines disappearing — are the same habits that later helped cut a cloud bill by 40% and keep a production platform at 99.9% uptime. Cheap hardware, expensive lessons, zero risk.