Last week, the open-source team at Spectro Cloud held a Hackweek. If you haven’t heard of the format, it’s basically a week where we don’t focus on the highest-priority tickets. Instead, we work on things we want to work on—whether it’s for fun, exploration, or finally giving some love to that neglected project in the corner. I find Hackweeks incredibly valuable. In fact, I’ve written about them before—once in 2020 and even earlier back in 2015. They spark ideas, rekindle curiosity, and sometimes result in something genuinely useful.
One thing I’ve been meaning to do for a while is level up my Kubernetes game.
That might sound odd—I work on Kairos, a Linux-based OS for running Kubernetes—but in practice, most of my day-to-day work is in Linux, containers, and Go. I rarely need to interact with Kubernetes itself. It reminds me of Matz, the creator of Ruby, saying he’s actually a C developer. I guess it’s not that uncommon in our field. Still, I want to get better at Kubernetes because the better I understand it, the better I can support Kairos users. And the best way I learn? By building stuff.
The setup#
The week before Hackweek, I went on eBay to buy some used machines for a home cluster. That plan flopped—the seller completely botched the delivery, and I had to request a refund. Thankfully, I found a local shop instead: tweedehandslaptop.com. Not the cheapest option, but totally worth it. Fast service, even during the Belgian summer slowdown. For now, I only bought one node to start small and grow organically.
The node is an HP ProDesk 600 G4 Mini with an Intel Core i5 8500T (8th gen, 2.1 GHz), Intel UHD Graphics 630, 16 GB of RAM, and a 256 GB SSD. I got it for €275. I can already hear the fan even when it’s running without a load, so I’m wondering how bad that will get in the future—but my inner geek thinks it’s worth the trouble. The plan is to eventually add an amd64 worker node that also handles storage, plus a Raspberry Pi 4 to run arm64 workloads and connect to physical peripherals like a doorbell and a camera.
I also picked up a copy of The Book of Kubernetes, which I’ve been enjoying. The exercises are hands-on and solid, but it reminded me why I enjoy working on Kairos.
Configuration management systems like Ansible feel so much heavier compared to working with immutable systems, where you start with the final image. And it’s not just about complexity—it’s kind of wild that everyone has to rerun the configuration of their system from scratch. With an immutable image, you save time and resources by building it once and distributing it. It’s more ecological too—you’re not pointlessly running the same setup hundreds of times across different machines and users. Imagine if we didn’t use caching in other areas of computing. It’d be madness! And yet, somehow, our industry is still stuck in the CMS world. But we’re changing that. 😉
Special shoutout to abcd by Jacques Landru, who uses Kairos to teach computer networking. That’s a great example of how infrastructure should be built for learning environments.
Building the image#
One of the first things you need to get used to with immutable systems is the need to rebuild the image for any change you make. While you’re still learning, it’s tempting to rely on a GUI, but sooner or later, that workflow needs to move into a pipeline.
At Kairos, we’ve worked hard to make that pipeline as smooth as possible. Tools like AuroraBoot offer both a web UI and a CLI, and you can plug the latter straight into your automation. Still, I wanted something even simpler—especially for day-one users.
That’s why my main Hackweek project was creating the kairos-factory-action: a GitHub Action that makes it ridiculously easy to produce Kairos images from a repository. You don’t need to write a Dockerfile or understand the internals of AuroraBoot to get started. Just drop in a workflow like this:
name: Docker Build
uses: kairos-io/kairos-factory-action/.github/workflows/reusable-factory.yaml@main
secrets:
registry_username: ${{ secrets.REGISTRY_USERNAME }}
registry_password: ${{ secrets.REGISTRY_PASSWORD }}
with:
base_image: ubuntu:24.04
model: "generic"
arch: "amd64"
version: "auto"
iso: true
grype: true
registry_domain: "quay.io"
registry_namespace: "mauromorales"
summary_artifacts: true
kubernetes_distro: "k0s"
kubernetes_version: "v1.33.3+k0s.0"
This snippet declares the base image, Kubernetes distribution, version, and output format (an ISO, in my case). No boilerplate needed.
Boot, browser, boom
Once the GitHub Action finishes, you download the ISO, flash it to a USB stick, and boot up the machine. Open a browser at IP:8080, paste your config, and boom—single-node cluster running.
The configuration at this point is very simple, I mostly followed Kairos’ example for setting up a manual single-node cluster with k0s with one small tweak: instead of using the --single flag, I passed --enable-worker and --no-taints. This lets me run it as a single-node cluster for now, while keeping the door open to add more nodes later.
k0s:
enabled: true
args:
- --enable-worker
- --no-taints
If I want to change something, I just commit it to my repo. The action builds a new image, I point the node to it, and upgrade. No manual builds. It honestly feels a bit like updating an Apple device: the OS just shows up ready to go.
It’s a small cluster (so far), but seeing it boot for the first time felt like flipping the switch on a personal cloud. Can’t wait to see what else I can build with it.
Next steps#
First thing I wanted to deploy? My doorbell app. But then I realized I wanted to tweak a couple things.
That led to a new project: Mowa—short for MacOS Web API. It’ll let my cluster talk to my Mac Mini programmatically. More on that in a follow-up post.
Reply by Email