Every team aspires for their application to be flexible, scalable, and capable of handling user requests efficiently. While functional testing validates the application’s features, load testing assesses how the application performs under stress.

Modern tools have simplified functional testing, but conducting distributed load tests to evaluate an application’s resiliency remains complex. It requires the ability to adjust tests to simulate production-like scenarios dynamically.

In our previous post, we discussed the benefits of using Testkube over the k6 operator for scaling load testing. In this post, we’ll cover step-by-step how to scale your k6 load tests using Testkube to ensure your application can handle heavy loads seamlessly.

Distributed K6 Testing with Testkube

We discussed distributed load testing, k6, and how the k6 operator stacks up against Testkube in this blog post. Let us apply what we have learned and create a distributed k6 test using Testkube. We’ll create a Test workflow for running distributed k6 load tests and configure it to run in parallel. 

Pre-requisites

• Get a Testkube account.
• Kubernetes cluster - we’re using a local Minikube cluster.
• Testkube Agent configured on the cluster.

Once the prerequisites are in place, you should have a target Kubernetes cluster ready with a Testkube agent configured. 

We've created a video tutorial that walks you through the process. This video provides a visual guide to creating and running your k6 distributed test workflow using Testkube. You can watch it for a quick overview or follow along as you implement the steps yourself.

Creating a Test Workflow

Navigate to the Test Workflows tab and click on “Add a new test workflow”

This will provide you with three options:

• Create from Wizard - use the wizard to create a Test Workflow.
• Start from an example - use existing k6, cypress, and playwright examples
• Combine existing workflows - use with existing workflows.
• Import from yaml - import your own Test Workflow.

We’ll choose the “Start from an example” option to create this workflow. In the examples tab, choose “Parallel Execution” and then select “Distributed k6”. This will show a sample yaml code that will create a distributed k6 test. We’ll look at the yaml file at the end of this document.

Click on Create to create the Test Workflow.

Executing Test Workflow

Now that the Test Workflow is ready, click “Run Now” to execute the workflow. It will prompt you to provide values for parameters like the duration, number of virtual users, and workers. Provide the values as per your requirement and click the Run button.

The Test Workflow will start executing based on the parameter values that you’ve provided. 

Based on the number of workers provided, you can see that k6 load tests are running in parallel. You can click on any of those to view the detailed steps.

Navigate to the “Artifacts” tab to check the logs and reports generated from the test. You’ll see that logs and reports are generated for each worker. Click on any of the reports to view them in a new tab.

Below is what a typical k6 distributed test report looks like.

This was a simple demo of creating and executing distributed k6 load tests using Testkube. To take advantage of test workflows more, you can create custom workflows and import them to Testkube.

Let us now take a look at the test definition that was generated for the Test Workflow

‍

```yaml

kind: TestWorkflow
apiVersion: testworkflows.testkube.io/v1
metadata:
 name: distributed-k6
 namespace: testkube
 labels:
   docs: example
spec:
 config:
   duration:
     type: string
     default: 5s
   vus:
     type: integer
     default: 10
   workers:
     type: integer
     default: 3
 content:
   git:
     uri: https://github.com/kubeshop/testkube
     paths:
     - test/k6/executor-tests/k6-smoke-test.js
 steps:
 - name: Run test
   parallel:
     count: config.workers
     transfer:
     - from: /data/repo
     use:
     - name: distribute/evenly
     container:
       workingDir: /data/repo/test/k6/executor-tests
       env:
       - name: K6_SYSTEM_ENV
         value: K6_SYSTEM_ENV_value
       - name: K6_WEB_DASHBOARD
         value: "true"
       - name: K6_WEB_DASHBOARD_EXPORT
         value: /data/k6-test-report.html
       resources:
         requests:
           cpu: 128m
           memory: 128Mi
     paused: true
     run:
       image: grafana/k6:0.49.0
       shell: |
         k6 run k6-smoke-test.js \
           -e K6_ENV_FROM_PARAM=K6_ENV_FROM_PARAM_value \
           --vus {{ config.vus }} \
           --duration {{ shellquote(config.duration) }} \
           --execution-segment {{ index }}/{{ count }}:{{ index + 1 }}/{{ count }}
     artifacts:
       workingDir: /data
       paths:
       - '*.html'
status: {}

```

In the above file:

• The configuration specs define the number of workers, virtual users, and duration of the test. The document also specifies the environment variables for k6.
• The test source is a file in a GitHub repository. Refer to the k6 test referred to in this definition.
• Resource limits are provided for CPU and memory, along with the image details. 
• Test execution command is provided along with artifacts configuration to collect the logs.

Summary

There’s no second thought that load testing is critical to test the resilience of your application. Distributed load testing provides you with a more realistic and production-like environment. Tools like k6 make load testing simpler. 

Regarding Kubernetes, Leveraging k6 and Testkube can significantly enhance distributed load testing. While the k6 Operator offers robust automation, it requires deep Kubernetes expertise. Testkube simplifies the process with flexible test triggering, Git integration, distributed parameterization, and support for provisioning dependent services.

Get started with Testkube today, or visit the Testkube documentation to learn more about running distributed tests in Testkube using other testing tools. Feel free to post a note in our active Slack community if you struggle with anything.