Kubernetes: Benefits & Use Cases for QA Teams

What is Kubernetes?

Kubernetes (aka “k8s”) is an open source tool and framework that allows developers to manage containerized software. It is primarily used as a way to deploy and scale containers. To leverage some of the benefits it brings to QA teams, it’s important to have an understanding of how Kubernetes works within the development pipeline.

What is containerization and what are containers used for?

Containerization is a software packaging model in which an application is divided into independent components known as containers that are able to run as isolated executables. The idea behind them is that they are packaged in such a way that they can run on any infrastructure. A variety of different components can comprise a container - e.g. microservices, monolithic applications, and batch jobs.

Consider the example of a mobile app in which people can process payments - the component that is responsible for processing said transactions can be thought of as a microservice within the app and can be packaged into its own container along with any relevant libraries or environment details needed for it to be an independent executable. This container may include code for validating payment details, a process for updating a database with the transaction details, and a process that allows customers to save their payments details, among others.

The types of components that will be containerized is dependent on an application’s architectural structure, but the key to using Kubernetes is to containerize the application in a way that makes sense for application’s particular structure.

How does Kubernetes work?

As mentioned earlier, Kubernetes is primarily used as an engine for managing these containers. To do this, Kubernetes builds what are known as pods. A pod is the most basic element of Kubernetes and is a collection of one or more containers, typically ones that work closely together and are ideally managed together. This can apply to containers that frequently share data or communicate with each other. Either way, grouping containers in a pod allows them to be scaled, deployed, and managed together. Or, alternatively, pods can consist of just one container if doing so makes sense for application structure.

Once pods are created, the Kubernetes scheduler deploys to a set of worker nodes that are, in turn, managed by the master node (also known as the control plane in Kubernetes). Worker nodes are machines - virtual or physical - that are responsible for actual running of the containers, and the master node is what controls a set of worker nodes and determines when, where, and how to manage the pods within each. This grouping of worker nodes and master nodes comprises what’s known as the Kubernetes cluster that all work together to run the application. One or more pods can be deployed to a single worker node, and their placement is determined by custom scheduling principles as determined by the developers.

Testing Applications with Kubernetes

Let’s now delve into some ways Kubernetes can be of value to QA engineers and testers.

Deployment & Rollbacks

As a common part of the software development life cycle, when developers push new changes to a version control system - say, GitHub - and a new build is generated and deployed to its intended environment. When integrated with Kubernetes, this change would prompt the CI/CD tool to create a new container image for these changes to be created and stored within a container registry. The CI/CD tool will then update Kubernetes about this new container image via Kubernetes’ configuration file. Kubernetes will then use this information to create new containers and pods and terminate the old ones.

While the Kubernetes’ deployment process for new changes can be relatively hands-off for QA engineers and testers, the relatively easy rollback process can be a time-sensitive means for revering changes quickly. This rollback command can be executed as follows:

kubectl rollout undo deployment/my-app

where ‘kubectl’ is the Kubernetes command that allows QA to manage a cluster. Doing this will rollback the changes from the specific environment targeted by kubectl and return to a previous version of the containers and pods. Using Kubernetes to roll back changes is preferable when resolving issues that don’t require reverting changes in the source code (which may not always be necessary anyway if the reason for the rollback is not due to a bug), which has the potential to introduce new risk.

Benefits for Stress and Load testing

For testing, one of the primary benefits to Kubernetes is its ability to scale pods up or down, thus making it a useful tool for resource management, load balancing, as well as scale and load testing. Let’s continue with the example of the mobile app with a transaction processing container. A common stress test might be to validate the behavior of the app when a high volume of transactions are being processed in a given time period. When running this test at high volumes, if the app’s performance begins to dip below the acceptable threshold for QA, Kubernetes can be used to quickly and easily increase this threshold by scaling up the number of containers used to process transactions. Kubernetes does this by making copies of the pods with those containers and scheduling them to run on their designated node. This effectively boosts the processing power of the app in the event of high loads. Developers can either manually configure Kubernetes to duplicate pods or automate the scaling up of pods using Kubernetes autoscaling functionality.

Executing this change without Kubernetes would require that developers provision, deploy, balance, and monitor new server instances either manually or through the use of custom automation scripts, which can be time-intensive and difficult to maintain over time as more server instances are added. Scaling changes are especially important when needing to support pre-launch crowd testing or post-launch traffic spikes due to updates or new features.

Network Testing

Furthermore, QA is able to leverage network testing tools to test network performance of different nodes and pods. This can be helpful as an exploratory scenario to narrow down parts of the application that exhibit the biggest latency or bandwidth problems. A simple network can be executed via the following steps:

1) SSH into the node under test

2) Using the tc command, add the intended network latency. For example, here is a sample command that adds 100ms of latency to outgoing packets:

tc qdisc add dev eth0 root netem delay 100ms

3) Add packet loss as designated by the test setup and data pre-conditions

4) Run the network test by executing any test scenarios or cases that are relevant to the node under test

5) Once the test is complete, remove the network conditions with the following command:

tc qdisc del dev eth0 root netem

QA can use Kubernetes to define a cluster solely for network testing or other types of performance tests. This allows for isolated testing that won’t interfere with other QA work, and it allows tests to be run in environments that are duplicates of the QA, production, or staging environments. Test-specific clusters also simplify the debugging process, providing developers with a clear path to the exact test environment and to more easily narrow down the root cause of a defect.

Logs and Monitors

Kubernetes logs and monitors the performance of each container running within a pod. These logs can be accessed using

kubectl logs <pod-name>

or

kubectl logs <pod-name> -c <container-name>

for a specific container. For example, connection errors, HTTP request failures, and many others will be visible here.

Also, Kubernetes monitors pods for basic performance data such as CPU and memory usage, data which can be tracked for early detection of resourcing problems with a pod or node that may require reconfiguration. Kubernetes can output the CPU and memory usage of all nodes in a cluster with the following command:

kubectl top nodes

Or, more granularly at the pod level:

kubectl top pods

This data can be imported into a third-party tool to build data visualization dashboards or simply tracked within Kubernetes itself.

Other QA Use Cases With Kubernetes

Given Kubernetes’ capabilities for replicating clusters and environments, QA can have debugging-specific clusters that are specifically used for more aggressive testing and can be equipped with specialized debugging tools. These sorts of QA clusters can also be designated for early-stage, isolated testing of individual components, microservices, or features. With either test focus, Kubernetes makes the process of creating, scaling, and removing these environments much easier so that QA can focus on targeted application testing as needed.

Summary

Kubernetes is a robust tool and framework for managing software applications via containers, and it provides numerous ways to streamline the QA process for functional and non-functional testing. For additional information on Kubernetes and capabilities, check out its documentation hub at https://kubernetes.io/docs/concepts/.