I’m writing this post for the ones with stuff to get done in the seemingly never sleeping cloud native community. Talk about two things that don’t mix well.
When only looking at Kubestack briefly, you may mentally file it as yet another tool to build Kubernetes clusters and move on. But doing so, you’d be missing out, in my humble, and arguably biased opinion.
Kubestack aspires to be for GitOps and Terraform, what Spring Boot or Rails are for application development and Java or Ruby respectively. Yes, that's a big goal.
Kubestack does not turn a bunch of machines into a Kubernetes cluster. Instead, the open source framework maintains the desired state of clusters and cluster services and applies changes following a GitOps approach to an API. This API may be a cloud provider API or the Kubernetes API, depending on what part of the desired state changed. Currently, Kubestack supports managed Kubernetes from Amazon (EKS), Azure (AKS) and Google (GKE). For on-premise and other cloud providers I consider Cluster API the most promising development.
Teams basing their infrastructure automation on Kubestack can
- reason about proposed changes using pull requests,
- and test proposed changes on the non-critical ops-environment
- before applying the changes to the critical apps-environment.
Kubestack enables this for both the infrastructure of the cluster itself, and the services that run on top of the cluster. Think services that need to be on the cluster before application workloads can run there. Using Kubestack you can maintain both in one repository and have changes applied reliably through the same GitOps automation.
Following this approach, teams can jointly make changes to both infrastructure and applications without one blocking the other.
And that is Kubestack in a nutshell for you. If you want to learn more, head over to the Kubestack GitOps framework documentation for all the details.
Top comments (0)