DEV Community

Cover image for I Run Bare-Metal Kubernetes on $200 of Scrap Hardware (And Why I Burned 3 SD Cards Learning)

I Run Bare-Metal Kubernetes on $200 of Scrap Hardware (And Why I Burned 3 SD Cards Learning)

Le Beltagy on July 25, 2026

I Run Bare-Metal Kubernetes on $200 of Scrap Hardware (And Why I Burned 3 SD Cards Learning) From a bricked Raspberry Pi to a 4-node Tal...
Collapse
 
barrypittman profile image
Barry

Nice write up and awesome build! Good job!

Collapse
 
le_beltagy profile image
Le Beltagy

Thanks Barry 🙏

Collapse
 
6t9 profile image
Malik Taimoor Awan

BUILT YOUR OWN AI MODEL, THANKS

Collapse
 
chromitedev profile image
ChromiteDev

This is the kind of engineering content I'd rather read than another "10 Kubernetes tips" article. The failure stories are way more valuable than a perfect setup because they're the things you actually remember.

The SD card wear issue and the MetalLB/DHCP conflict especially stood out. It's a good reminder that homelabs teach you operational thinking, not just commands.

I'm building tools in the developer space myself, and posts like this are exactly the kind of content that push me to test everything by breaking it first instead of assuming it'll work. Great write-up.

Collapse
 
le_beltagy profile image
Le Beltagy

Thanks! Glad it resonated. Breaking things has definitely been my best Kubernetes teacher. 😄

Collapse
 
dovzhikova profile image
Daria Dovzhikova

Those SD card burns are a real rite of passage on bare-metal k8s. One thing that catches people off guard: once the cluster is 'running', figuring out what's actually talking to what gets much harder without the cloud console you'd have on EKS or GKE. I work on Radar Open Source (grain of salt), which draws a live topology graph across pods, services, and ingress as it sees them -- useful on bare metal exactly because there's no other fallback when traffic mysteriously stops. Curious what you're currently using to visualize state when things go sideways.

Collapse
 
ramkumar-m-n profile image
Ramkumar M N

Thanks for sharing such informative content.

Collapse
 
annavi11arrea1 profile image
Anna Villarreal

Interesting read about the SD cards. I was warned to steer clear of using an SD card when building my tiny webserver on a jetson nano. I chose an nvme hard drive and have no regrets. Your post further supports this idea: use the right hardware for the job, haha. Easier said than done, of course! I really appreciate your drive to dig into the weeds and create something magnificent out of neglected hardware. Challeneging yourself to build something from neglected hardware shows that you have an entrepreneurial creative spirit! I imagine this is a deeply satisfying feeling.

Collapse
 
unitbuilds profile image
UnitBuilds

Ngl, it's refreshing to see someone take the cloud home and optimize it. Goes to show, you dont need to redesign the wheel entirely, you just swap out parts with what fits better. Personally, I feel like Ubuntu is the biggest cost-cutter. It's getting bloated lately to the point that you might aswell run windows, yet it's spoon-fed to you when dealing with cloud, when lighter options exist like Alpine. Though that's still bloated in my opinion... Cloud OS should be modular and start with the barest of minimums, we dont need drivers for 50k different devices, if it runs on an EK2 instance, we need exactly 1 set of drivers and if it's a headless setup, it needs even less than what's bundled into even the most bare minimum linux distros. It's half the reason why I started developing V.E.L.O.C.I.T.Y. OS, because booting up the smallest vm a provider offers, gives you only about 70% of the resources you acquisitioned. And for what? Features you wont ever use? 'Ease of use' that's neither easy, nor useful? What you did replacing the frameworks with lighter versions that suite you better, is exactly why hosted clouds are a ripoff. Take CloudRun for instance, great for hosting a landing page or a very basic app, but try push it and it cracks under pressure, or cracks your wallet a new one. All stemming from the root problem. Everything that runs everything is built with inefficiencies that honestly should have been replaced years ago. Your SD cards died, not because of the workload, but because of the inefficiencies that make them unsuitable. They should have worked flawlessly, just a tad slower than an ssd, but instead they got corrupted and you'll likely need to clean and format them through DiskPart if even that can manage to fix it.

Collapse
 
amit_chahar_d3d2d1fbf6b89 profile image
Amit Chahar

check out my repo