I've recently released a major update for Kubestack, the Terraform framework for Kubernetes platform engineering teams. This update moves all functionality previously provided by Kubestack Cloud into the kbst CLI.
I decided to make this change, because Kubestack Cloud was only able to provide a better developer experience on day one. But, once exported to Terraform, the UI was not helpful any more on day two and all following days.
But my goal is to improve the developer experience and day-to-day lives of platform engineering teams at all times. This latest kbst release is a major step towards achieving this goal.
If this is the first time you hear about Kubestack Cloud: Kubestack Cloud was a browser based UI and allowed users to design a Kubernetes platform by following a step-by-step wizard and then exporting and downloading the designed platform's Terraform code.
However, the disconnect between the UI and the code in the repository on a developer's local machine, diminished the value of Kubestack Cloud on day two and beyond. To address this issue, I moved all this functionality into the kbst CLI, where access to the local code is easier.
The kbst CLI, which previously also only scaffolded new repositories, now has CRUD (create, read, update, delete) functionality for clusters, node-pools, and services. This means users can use the CLI to scaffold Terraform code to add or remove clusters, node-pools, or services inside their existing Kubestack repositories.
If you want to see the new CLI in action, give the updated tutorial a try or read the documentation on adding and removing cluster modules, node pool modules or service modules.
But if you'd like to learn more about how this works under the hood, keep reading.
How this works
If you're already familiar with Kubestack, you know that Kubestack repositories follow a convention-over-configuration approach to define the clusters, node pools, and services that make up a Kubernetes platform in a single Terraform codebase. At the root of each repository, there are several .tf files that follow a specific naming convention. These files contain module calls that define each platform component.
To add or remove components, or update the versions of existing component modules, the kbst CLI parses the necessary subset of Terraform code to understand the components of the platform. You can list the Kubestack component modules it discovered using the kbst list command. By appending --all to the list command, you can also see any non-Kubestack modules.
You can add node pools or services to existing clusters or add more clusters from the same or even a different cloud provider. The CLI will scaffold the additional required .tf files and update the Dockerfile's FROM line to specify the correct image, in case of changing from a single to a multi-cloud environment or vice versa. Likewise, it will also remove module calls and the respective .tf files if you remove a service, a node pool or even a cluster from your platform.
But don't worry, the kbst CLI only changes local files and does never change any cloud or Kubernetes resources.
You can use it to avoid writing repetitive boilerplate code or manually deleting module calls and Terraform files, while still owning your codebase and retaining the ability to extend or modify the code to meet specific needs.
Once you're happy with the code, you can follow the Kubestack GitOps workflow to peer-review, validate, and promote changes to your platform's environments as usual.
In conclusion, the shift from Kubestack Cloud to the kbst CLI provides a better developer experience not only on day one, but also on day two and makes it easier for platform engineering teams to manage their Kubernetes based platforms.
What happened to the platforms I designed with Kubestack Cloud?
If you have previously designed a platform with Kubestack Cloud, you can sign in with your existing user and will see instructions how to scaffold your existing platforms using the new CLI.
Here's an example screenshot of how that will look like.
Top comments (0)