Kubetest was an interesting experiment, but I've mainly moved my focus to Conftest which has a similar, but broader, goal. Conftest also uses the much more powerful, and supported, Rego language from Open Polciy Agent. Given this, I'm archiving this repository.
kubetest is a tool for running tests against a Kubernetes YAML or JSON configuration file.
These tests can be used to enforce local or global best-practices, for example:
- Ensuring certain labels are set
- Prevent usage of images with the
- Prohibit privileged containers
- Enforce a naming convention for different resources
kubetest is currently alpha quality and undoutedly has a few issues. Things will change, hopefully for the better. Please open issues if you have feedback when trying it out.
Tests are written in Skylark, which is a small dialect of Python suitable for embedding in other programmes. This means you do not need an additional interpreter installed to run tests with
kubetest prioritises interopability over flexibility in this regard. Tests for Kubetest just require the
kubetest binary to run. Let's take a look at an example test:
#// vim: set ft=python: def test_for_team_label(): if spec["kind"] == "Deployment": labels = spec["spec"]["template"]["metadata"]["labels"] assert_contains(labels, "team", "should indicate which team owns the deployment") test_for_team_label()
Save the test file in a directory called
tests, with an extension of
.sky. You can change the default directory name using the
--tests flag. You can now run
kubetest against your configuration files.
$ kubetest my-deployment.yaml WARN my-deployment.yaml Deployment should have at least 4 replicas $ echo $? 1
If any of the tests fail then
kubetest will return a non-zero exit code.
kubetest outputs information about failing tests only, but you can pass
--verbose to get information about passing tests as well.
$ kubetest rc.yaml --verbose INFO rc.yaml should not use latest images WARN rc.yaml ReplicationController should have at least 4 replicas
spec is a global variable passed into the Skylark code which contains the structure of the Kubernetes configuration passed in to
kubetest. You'll need to be reasonably familiar with the structure of the Kubernetes API objects to write tests, but it is possible to write helper methods for common assertions.
kubetest automatically makes available a set of assertions to make writing tests in Skylark more pleasant. A failed assertion results in
kubetest exiting with a non-zero exit code, and assertions output results as shown above.
Assertions take zero, one or two arguments (noted above) depending on what they are comparing. They then take an additional message argument which is output when the assertion runs. For example the following assertion checks whether the variable
labels contains the value
assert_contains(labels, "team", "should indicate which team owns the deployment")
Tagged versions of
kubetest are built by Travis and automatically
uploaded to GitHub. This means you should find
tar.gz files under the
release tab. These should contain a single
kubetest binary for platform
in the filename (ie. windows, linux, darwin). Either execute that binary
directly or place it on your path.
wget https://github.com/garethr/kubetest/releases/download/0.1.0/kubetest-darwin-amd64.tar.gz tar xf kubetest-darwin-amd64.tar.gz cp kubetest /usr/local/bin
Windows users can download tar or zip files from the releases tab.
$ kubetest --help Run tests against a Kubernetes YAML file Usage: kubetest <file> [file...] [flags] Flags: -h, --help help for kubetest --json Output results as JSON -t, --tests string Test directory (default "tests") --verbose Output passes as well as failures
A big thank you goes to the authors of stretchr/testify from where much of the assertion code has been ported.