InfoQ on WKSctl and Cluster Configuration Management with GitOps
InfoQ, the magazine for professional software development, and Christian Melendez recently conducted an interview with the Weaveworks team on the WKSctl project. WKSctl is an open source tool that can be used to create and manage developer and production ready Kubernetes clusters from git.

InfoQ, the magazine for professional software development, and Christian Melendez recently conducted an interview with the Weaveworks team on the WKSctl project. WKSctl is an open source tool that can be used to create and manage developer and production ready Kubernetes clusters from git.
WKSctl is part of Weaveworks’ commercial product, the Weave Kubernetes Platform (WKP), that uses GitOps to provide policy management, operational automation and cross-cloud management capabilities. WKSctl can install and bootstrap open source Kubernetes on public clouds, in private data centers, or air-gapped.
“The purpose of WKSctl is not to do the machine provisioning. So the ideal customer of WKSctl is someone who uses Terraform, vSphere, Salt, Ansible, or Chef to provision machines themselves. Customers can then use WKSctl to install and bootstrap Kubernetes onto those machines. But if you don’t want to provision the machines, we also have Firekube, which takes WKSctl one step further. Firekube takes a vanilla Kubernetes and uses WKSctl to install it on Ignite (Firecracker VM) clusters.” --Alexis Richardson, Weaveworks CEO
A typical WKSctl use case
Most want to take advantage of cutting edge open source technology. But getting all of these technologies to work together and then reproducing that configuration across environments can be challenging. The basic idea behind WKSctl and WKP is for application developers and operators to have an easier, consistent and secure Kubernetes experience.
Clusters should be cattle
Clusters should be easy to start, stop and delete wherever you need one. If you want “application clusters” that are ready for development, you need a readily available choice of add-ons and configured extension components, such as ingress, and monitoring. These application clusters once configured also need to be reliable, reproducible and secure.
Eliminate brittle clusters
Eliminate dependence on complex configuration scripts and CLI flags which can lead to incorrect or unknown cluster state or worse, to “snowflake clusters” that cannot be safely shut down or upgraded.
Consistency across environments
It should be easy to keep your Kubernetes cluster configuration consistent across development through to production and between different infrastructure environments.
If it doesn’t provision machines, what exactly is WKSctl?
WKSctl allows you to manage cluster configuration from git. It has three important features:
- Correct clusters made simple: Using a single tool, SREs and DevOps engineers can create clusters for development through to production. A cluster can be spun up in a single step to include add-ons such as Helm and Prometheus, all correctly configured. This allows for clusters to be more easily replicated on demand, and removes a major source of Kubernetes pain.
- Continuous verification: WKSctl maintains clusters in a verifiably correct state. It uses a GitOps control loop to enforce correct changes in the entire cluster. Since all configuration is kept in git as a single source of truth, runtime cluster and add-on management, cluster upgrades, including some migrations are vastly simplified.
- GitOps best practices: WKSctl and WKP starts with a git repo to configure complete clusters as well as the permissions on who can change what to a cluster. After the clusters have been configured, a simple `git fork`, and a `git clone` is all that’s required for your cluster to be set up consistently.
The figure below describes the basic drivers behind WKSctl. YAML manifests are kept in git which are managed and reconciled on drift alerts with Flux. The “WKS controller” component implements a cluster API provider. WKSctl can self-bootstrap and create a cluster using the SSH endpoints from a set of VMs.
“There are two reconciliation loops. The first one is Flux, a reconciler that watches the git repository for any changes to the configuration of the cluster. Its job is to take those things from git and essentially commit them to etcd. The second reconciler is the WKSctl controller that watches etcd just like the replication controller does in Kubernetes.” -- Cornelia Davis, CTO Weaveworks
For free users of open source WKSctl:
- WKSctl is a stand-alone installer and cluster controller that provides enterprise runtime management and upgrades, on a single-cluster basis.
- As a baseline option, WKSctl works with upstream Kubernetes.
- WKSctl OSS can work with your choice of OS, on-metal, VM, etc.
For paying customers of WKP:
- WKSctl can also subscribe to a Weaveworks repo to add extensions. It’s not a “forked distribution”, but rather an additive to upstream Kubernetes.
- Subscribers also have access to a patch stream in case of CVEs
Weaveworks certifies supported combinations of OS, virtualization, on-metal, air-gapped installations.
Depending on the type of support you need for your development or production cluster, choose from the free and open source WKSctl or the commercial and fully supported Weave Kubernetes Platform (WKP) that also includes services and applications like ingress, Prometheus monitoring, Grafana, and other dashboards with drift alerts and more.
With both solutions, Kubernetes upgrades are simpler, and your choice of operating system, VM or provisioning tools are also not restricted. You can also easily use WKSctl in your CICD pipelines, adding GitOps cluster lifecycle management to your delivery toolchain, or you can make it part of your operational stack. Weaveworks also offers full commercial support and additional features and services in WKP.
Contact us for a demo of WKP and WKSctl.