Getty Images
Tools and techniques to test Kubernetes objects
Kubernetes manifests and objects represent the baseline of code development on the platform. Here's why and how to test these integral elements of Kubernetes.
DevOps teams must deploy and manage several resources for customers or internal applications, often in containers managed with Kubernetes. They typically write code, flesh out the resources manually and deploy the application with Kubernetes. However, when developers do not fully vet the deployment environment, they may deploy unnecessary extra resources.
Kubernetes environments have many ways to test these objects and the environments they deploy to.
What are Kubernetes objects?
Kubernetes objects are "persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster," as stated in the container orchestration technology's documentation.
Most developers think of a persistent entity as anything that's created by either of the two Kubernetes API groups: core (legacy) API group and named API groups. The core API group is where developers will see all the original Kubernetes resources, including the following:
- deployments
- services
- pods
- ConfigMap
The named API group consists of all the new APIs, including the following:
- ingress
- RoleBinding
Any time developers see "k8s.io" in the Kubernetes API group name, that API belongs to the named group. For example, rbac.authorization.k8s.io/v1/clusterroles.
With all these different Kubernetes APIs, developers must be mindful of all the available configurations and possible obstacles each scenario has. Testing plays an integral role with Kubernetes objects.
Another integral part of Kubernetes development are manifests. These are specifications of the Kubernetes API object but either in JSON or YAML format.
Why does testing matter?
Imagine that some piece of application code wasn't tested. Regardless of how well the code addresses the need and how talented the developer is, that code will be vulnerable if the developer deploys the code to production without testing first. For that reason alone, testing is an essential part of the application development lifecycle.
The reason developers should test Kubernetes objects and code, such as Kubernetes manifests, is simple: everyone makes mistakes. If developers put a proper testing mechanism in place -- preferably automated -- it creates assurances and efficiency. Developers aren't spending time fixing broken Kubernetes objects.
Another important consideration for testing Kubernetes objects is the quick rate at which Kubernetes updates. As a result, APIs are subject to major differences between updates that could affect code. Organizations often use beta APIs in production, and like all things beta, the code changes. If the code changes and breaks or modifies something already in use, a developer might not know until application users experience problems.
Who should test?
Depending on the organization, development or DevOps teams are responsible for writing Kubernetes manifests. When it comes to who is responsible for testing the manifests, the quick answer is that it falls to the team who writes them.
In Kubernetes there's a development side and an infrastructure side, which can affect who in the company does the testing. Since almost all Kubernetes APIs are objects, if the infrastructure team handles API modification, the testing could fall on the infrastructure team.
There's no right or wrong answer to who should test Kubernetes objects. But in most instances, the team responsible for writing them should also test them.
3 tools to test Kubernetes objects
Now that teams have a plan organized, they will need tools to test these Kubernetes objects. Here are three options that teams can consider to conduct these tests.
Kubetest. Before this tool existed, many engineers used the Pytest testing tool for Python. Kubetest is now a Pytest plugin for developers to write integration tests for Kubernetes manifests. Developers can automate tests for networking and infrastructure and even disaster recovery.
K6 from Grafana Labs. This CLI-based load testing tool tests the performance of an application by writing JavaScript tests that mimic real-world scenarios. Performance testing tools test an application's resilience in different demand scenarios.
Kube-monkey. This tool is based on Netflix's Chaos Monkey chaos engineering technology. Kube-monkey deploys tests daily that schedule a random Kubernetes pod death to see if the system will revive the pod as expected. It works on a schedule that runs during the day, like many chaos testing tools. By testing in production, the DevOps team can see how resilient the application is in the real world.
