One Cluster to Rule Them All

Change is coming to the homelab.

For a while now I’ve been running two separate Kubernetes clusters — one for production workloads and one for development/experimentation. The idea was clean isolation in theory. In practice? It means double the maintenance, double the upgrades, and double the headaches every time something breaks at 11pm.

So I’m collapsing them. One cluster. Proper namespace isolation, node labels, and taints to keep production workloads from noisy neighbors — without the overhead of managing two separate control planes.

Built on Talos Linux

The new cluster runs on Talos Linux — an immutable, API-driven OS purpose-built for Kubernetes. No SSH. No package manager. No shell on the nodes by default. Everything is managed declaratively through the Talos API, which means the nodes are lean, consistent, and dramatically harder to accidentally break.

Talos falls into a category called a Core OS — a stripped-down, minimal operating system designed to do one thing well and get out of the way. Traditional Linux distros ship with compilers, package managers, shells, and dozens of other tools you don’t need on a Kubernetes node. A Core OS throws all of that out. The surface area is tiny, the attack surface is smaller still, and the entire system is read-only at runtime. You don’t log in and make changes — you push a new config through the API and the node converges to the desired state. It’s closer in philosophy to a network appliance than a general-purpose server.

If you haven’t looked at Talos, it’s worth your time. The security posture alone is a massive step up from a typical Linux-based node setup.

Say Hello to Nanobot (aka Jarvis)

Nanobot Logo

The cluster also has a brain now. Running inside it is Nanobot — an ultra-lightweight personal AI assistant inspired by OpenClaw, and my cluster-aware right hand, or as I call it, Jarvis. Nanobot delivers core agent functionality with 99% fewer lines of code than OpenClaw — all the capability, none of the bloat.

Nanobot has eyes into the cluster through Kubernetes MCP tools and can help manage workloads, answer questions about what’s running, and generally be the kind of assistant Tony Stark would acknowledge as “acceptable.”

More on that in a future post.

What’s Coming

This redesign is a big one and I’ll be documenting the whole thing — the architecture decisions, the migration, the things that went sideways, and the wins. Stay tuned.

Leave a Comment