Local Kubernetes Clusters in Minutes

Introducing Kluster

I’ve been working on a CLI tool I’ve named kluster that spins up a Kubernetes environment in minutes for local development and CI testing. The intention is to provide developers, who may have varying degrees of comfort and familiarity with Kubernetes, with the ability to run their software in a Kubernetes cluster that’s just for them without having to follow complex sets of instructions.

Motivation

I’ve worked on platforms and infrastructure automation at a number of organizations over the past 10 years and during the last 6, I’ve noticed a surprising lack of maturity in developer tooling that addresses and accelerates the inner-loop (the local dev-and-test cycle). Too many teams get stuck in slow, manual, error-prone feedback loops because that inner-loop is too constrained, not close enough to the real runtime environment, and shared across multiple colleagues.

Make It Simple

My first priority is making a tool that can provide me with a pre-configured Kubernetes cluster for local development and testing. Provisioning a full cluster through a cloud provider is simpler than the early days of doing it all yourself with some community scripting, but it’s still enough to derail and distract most folks from the task at hand.

Kluster is intended to stand up a small local cluster in a single step so that you can focus on your work and reach a high degree of confidence that after merge and deploy, everything works as intended.

Make It Repeatable

Passing around command line incantations is less than ideal. In the past decade of DevOps environments, the established norm is a cursed search across Google Docs, wikis, and Confluence to try to find the correct combination of subcommands and flags required to stand up the local dev environment. I can’t count the number of times that those documented commands have gone stale and no longer produce a working outcome, leaving the new hire in the uncomfortable position of troubleshooting unfamiliar tooling.

Kluster supports configuration files so that everyone on the team can get the same local environment without having to go back to documentation to make sure that what’s recorded is what works.

Make It Safe to Break

I think it’s too often overlooked, but part of learning, experimentation, and innovation is providing environments where it’s safe to experiment and even break things in a way that doesn’t disrupt the flow of others. Shared development environments create an atmosphere of anxiety where folks will avoid making changes to a shared environment for fear of irritating and slowing their colleagues.

A complete, local environment makes it safe to take big swings. The disposability and repeatability of a local environment means the cost of a mistake is isolated to one person and only minutes between realizing the environment is broken and having a fresh setup in a known, healthy state.

Make It Extensible

Kluster is new but it has an add-on system that will allow me to extend it with commonly used software that can be installed and pre-configured. Want to test auto-deployment? Include the ArgoCD add-on.

Testing and Contribution

It’s still early days and kluster will continue to change and evolve. I built this to solve my own pain points and I believe others who have felt the same friction may find it useful.

I’ve made heavy use of Claude Code to build a working prototype that I can use for my projects. You can find the source on GitHub here. Keep in mind, it’s a functional prototype that I hope will improve over time, please don’t expect the source to be a model of Go idioms and patterns.

I welcome anyone to try it out, file bugs, or provide feedback for how it could be improved. Contributions are welcome, but I might be slow to review PRs given how many other things I’m currently working on.

Disclaimer: Not for Production Workloads

While it may be obvious, I should be clear that kluster is not designed with production workloads in mind and exposing a kluster-provisioned Kubernetes to the public internet is well outside of the intended use case. I have tried not to cut too many corners in its design, but my focus was on creating something that should work for most local and CI environments, not building something that you can host live software on.