Building a Raspberry Pi 5 based K8s cluster
The following is an AI generated summary of the video
Sometimes the best way to learn a technology is to stop reading about it and start building something with it.
That's exactly what led me to build a Kubernetes cluster using Raspberry Pi 5s.
The goal wasn't to create a production-grade platform or save money. It was to refresh skills that had become a little rusty and build something genuinely useful along the way. :contentReference[oaicite:0]{index=0}
Returning to Kubernetes
I first experimented with Kubernetes back in 2019.
At the time, I assembled a cluster from a handful of Raspberry Pis, a basic network switch, and a healthy dose of optimism.
It was not a success.
I spent hours fighting architecture differences, building containers for ARM hardware, troubleshooting mysterious failures, and generally convincing myself that Kubernetes was much harder than everyone claimed.
In hindsight, the problem wasn't Kubernetes.
The problem was me.
I was attempting to learn multiple difficult concepts simultaneously while running on hardware and configurations I barely understood. :contentReference[oaicite:1]{index=1}
Why Try Again?
Fast-forward a few years and Kubernetes has become impossible to ignore.
On my current engagement, I've been working with teams migrating workloads to Kubernetes and realised that much of my practical experience was several years out of date.
I could have watched more training videos.
Instead, I decided to build something.
Learning through projects has always worked better for me than learning through slides. :contentReference[oaicite:2]{index=2}
Finding a Real Use Case
A home lab is much more motivating when it solves actual problems.
I already had several small applications running around the house:
- A family chat application.
- A bedtime story generator.
- A small game built with one of my children.
- Pi-hole for network filtering.
- Various personal experiments and utilities.
They all worked.
But they were scattered across different systems and lacked any real resilience.
Kubernetes seemed like a good excuse to tidy everything up. :contentReference[oaicite:3]{index=3}
Choosing the Platform
My first decision was whether to use standard Kubernetes or a lighter distribution.
For a Raspberry Pi cluster, the answer was obvious: K3s.
K3s is a lightweight Kubernetes distribution designed for resource-constrained environments. It strips away many of the components that aren't essential for smaller deployments while retaining the Kubernetes experience that most people care about.
Installation turned out to be refreshingly simple.
Within a short time, I had a working cluster running across multiple nodes. :contentReference[oaicite:4]{index=4}
Hardware Lessons
One thing I underestimated was how much time I'd spend thinking about hardware.
Cooling.
Power delivery.
Storage.
Boot order.
Network cabling.
At one point I became completely distracted trying to determine whether a fan was behaving correctly.
It was a classic example of what developers call yak shaving—solving increasingly irrelevant problems while avoiding the task you originally set out to complete.
Eventually I settled on Raspberry Pi OS, SSD-based storage, and Power over Ethernet (PoE) to keep cabling manageable. :contentReference[oaicite:5]{index=5}
Containerising Everything
Once the cluster existed, the real work began.
Every application needed to be containerised.
Fortunately, modern AI tools made this dramatically easier.
For many of the smaller applications, the workflow looked something like this:
- Ask an AI assistant to generate a Dockerfile.
- Review and refine the output.
- Push the container image to GitHub Container Registry.
- Generate Kubernetes manifests or Helm charts.
- Deploy to the cluster.
The process wasn't completely automatic, but it was considerably faster than doing everything manually. :contentReference[oaicite:6]{index=6}
Adding Load Balancing and Storage
As soon as multiple services were running, I needed a way to expose them cleanly.
For that, I installed MetalLB.
MetalLB provides load-balancer functionality for bare-metal Kubernetes clusters, allowing services to receive IP addresses directly on the local network.
I also added local storage provisioning and dashboard tooling to make the cluster easier to manage and observe. :contentReference[oaicite:7]{index=7}
The Finished Cluster
The final setup consisted primarily of:
- Raspberry Pi 5 nodes with SSD storage.
- Power over Ethernet networking.
- K3s Kubernetes.
- MetalLB for networking.
- Local storage provisioning.
- Several family and personal applications.
It's hardly internet-scale infrastructure.
But that's not the point.
It's a platform for experimentation, learning, and hosting useful services at home. :contentReference[oaicite:8]{index=8}
AI and the Changing Nature of Engineering
One unexpected theme throughout the project was how often AI assisted the process.
Not by replacing engineering judgement.
Not by magically solving problems.
But by accelerating routine work.
Generating Dockerfiles.
Creating manifests.
Explaining unfamiliar concepts.
Helping troubleshoot issues.
The more I use these tools, the more I see them as collaborators rather than replacements.
They reduce friction.
But they still require direction and verification. :contentReference[oaicite:9]{index=9}
Why Physical Projects Still Matter
Interestingly, building the hardware gave me something AI can't.
Satisfaction.
There's something uniquely rewarding about physically assembling a system, routing cables, mounting hardware, troubleshooting power issues, and eventually seeing everything come together.
For many engineers, software has traditionally scratched that itch.
As AI becomes increasingly capable of generating code, hardware projects still provide that tangible sense of creation and problem-solving.
The joy isn't just in the result.
It's in the process. :contentReference[oaicite:10]{index=10}
What I'd Do Differently
Looking back, a few lessons stand out:
- Buy integrated PoE and SSD solutions from the start.
- Spend less time obsessing over minor hardware details.
- Avoid unplugging SSDs while the system is powered on.
- Integrate AI tools more directly into the development workflow.
- Design infrastructure automation earlier.
Every project leaves a trail of mistakes behind it.
That's usually where the learning happens. :contentReference[oaicite:11]{index=11}
Final Thoughts
The biggest surprise was how approachable Kubernetes on Raspberry Pi has become.
A project that felt frustrating and fragile in 2019 now feels entirely practical.
The hardware is better.
The software is better.
The tooling is better.
And perhaps most importantly, my understanding is better.
The cluster now serves useful workloads, gives me a playground for experimentation, and keeps my Kubernetes skills current.
Not bad for a pile of single-board computers sitting on a shelf.