Kubestack
Open-source Terraform Gitops Framework for Teams
Kubestack Cloud is a low-code UI to define Kubernetes platforms and export them to production grade Terraform. Architecting a K8s platform is time-consuming and difficult. It gets easier if you've done it before, of course, but then it's little more than just another repetitive task.
A UI can provide a lower entry barrier and allows for quicker iterations. But from a long term maintenance perspective, a UI managed platform is not sustainable. I'm trying to combine the best of both worlds, by having all the benefits of a UI in the beginning, but the power and control of infrastructure as code long-term.
With the Kubestack framework I've been maintaining an open-source Terraform framework, and Kubernetes Terraform provider for ~3 years now. But while the framework provides proven, reusable modules, it still requires writing 100s of lines of Terraform code to call the modules from your root module with the correct configuration.
Kubestack Cloud allows users to define the root module in the UI. It provides guidance on a number of high level architecture decisions, like how many environments and how changes are validated and promoted between these environments. It then lets users drill down to configure cloud providers (AKS, EKS or GKE), node pools and cluster services. Once done, everything can be exported to production grade Terraform code for free.
The generated Terraform code is human-readable and easy to maintain long term, because, again, Kubestack Cloud "just" generates the root module that calls the existing open-source framework modules.
Kubestack Cloud is still in the MVP stage. But give it a try and let me know what you think.
Kubestack aims to bring the benefits of web application frameworks to infrastructure automation. One of the big benefits frameworks bring is their awesome developer experience. A big piece of this are seamless local development environments.
Kubestack has had a local development environment for a while. But the previous implementation wasn't as nicely integrated, because it required its own Terraform configuration.
The new implementation does not require a specific Terraform configuration anymore, but reads the real configuration and simulates it locally.
Furthermore, the new CLI watches for changes to the configuration and automatically applies changes to the local development environment.
This screencast shows the new developer experience: https://www.youtube.com/watch?v=_VtakP6AdCs&feature=youtu.be
My biggest challenge is to share more about what I do. It doesn't come naturally and I end up not doing it. Knowing this, I am forcing myself to dedicate more time to doing it. This is the main reason why I signed up here.
Over the last couple of weeks, I've been working on writing documentation and a step-by-step tutorial to get started with the Kubestack GitOps framework.
Documentation: https://www.kubestack.com/framework/documentation
Tutorial: https://www.kubestack.com/framework/documentation/tutorial-get-started
I've also created a time-lapse video showing the full tutorial from start to finish. It's a big ask to try something new. And in my case, trying it requires provisioning actual cloud infrastructure. The idea behind the video is you can see how it works before trying it for yourself.
The latest release was quite a big one for the project because it replaces a previously Terraform provisioner based kustomize and kubectl integration with an actual kustomize provider that I built.
Before this, the integration lacked the same Terraform like plan/apply feedback for resources inside the cluster. The provider also makes sure resources that are removed from the repository, are also removed from the cluster. Something that kubectl apply is not able to do.
I am excited about this because although this is a big change, I was able to provide a reasonably simple upgrade path. And while the upgrade isn't fully automated, given how this is a pretty fundamental change the effort is comparatively low.
Three friends&family like users have already updated their clusters.
I believe maturity and future proof upgrades are critical for people to trust my framework. So I am investing quite a bit of time into solid automated testing and upgrade instructions.
Comment