The main focus of the recent developments was improving the CLI, supporting several clusters running in parallel, and enabling developers to test Kubernetes patches easily. In addition, we’ve added a bunch of documentation, improved error messages and, of course, fixed a lot of bugs.
We’ve completely redesigned the CLI commands used to interact with kube-spawn. You can now use
create to generate the cluster environment, and then
start to boot and provision the cluster. The convenience
up command does the two steps in one so you can quickly get a cluster with only one command.
Once a cluster is up and running you can use
stop to stop it and keep it there to start it again later, or
start the cluster.
destroy will take a cluster in the stopped or running state and remove it completely, including any disk space the cluster was using.
The following diagram provides a visualization of the CLI workflow.
Previously, users could only run one cluster at the time. With the flag
--cluster-name flag, running multiple clusters in parallel is now possible.
All the CLI operations can take
--cluster-name to specify which cluster you’re referring to. To see your currently created clusters, a new command
list was added to kube-spawn.
This is especially useful when you want to test how your app behaves in different Kubernetes versions or, as a Kubernetes developer, when you made a change to Kubernetes itself and want to compare a cluster without changes and another with your change side-by-side. Which leads us to the next feature.
Dev workflow support
kube-spawn makes testing changes to Kubernetes really easy. You just need to build your Hyperkube Docker image with a particular
VERSION tag. Once that’s built, you need to start kube-spawn with the
--dev flag, and set
--hyperkube-tag to the same name you used when building the Hyperkube image.
Taking advantage of the aforementioned multi-cluster support, you can build current Kubernetes master, start a cluster with
--cluster-name=master, build Kubernetes your patch, and start another cluster with
--cluster-name=fix. You’ll now have two clusters to check how your patch behaves in comparison with an unpatched Kubernetes.
You can find a detailed step-by-step example of this in kube-spawn’s documentation.
kube-spawn, a certified Kubernetes distribution
We’ve successfully run the Kubernetes Software Conformance Certification tests based on Sonobuoy for Kubernetes v1.7 and v1.8. We’ve submitted the results to CNCF and they merged our PRs. This means kube-spawn is now a certified Kubernetes distribution.
With the above additions, we feel like kube-spawn is one of the best tools for developing on Linux with, and on, Kubernetes.