In the dynamic world of Kubernetes, ensuring the reliability and quality of your applications is of the upmost importance. To achieve this, testing is a crucial step in the software development lifecycle. However, traditional synchronous testing methods can be time-consuming and inefficient, hindering the rapid delivery of features and bug fixes.
Join us for a Office Hours, where we will explore techniques and best practices for asynchronous test triggering in Kubernetes environments. In this session, you will discover how to harness the power of Kubernetes and modern testing approaches. We'll cover:
Who should attend?
DevOps Engineers, Software Developers, QA Engineers, SREs - or anyone in-between. This event is perfect for those who wish to dive deeper or are curious about the world of testing applications in Kubernetes.
Hello hello, and happy Friday everyone! Welcome back to Testkube's office hours, where we open our virtual office doors to you. My name is Ali, and I am the Developer Advocate at Testkube. Today, we will be talking about performing asynchronous testing in Kubernetes. If you are new here, Testkube is a Kubernetes-native testing framework designed for testers and developers to help orchestrate, execute, and display tests and test results for applications running in Kubernetes. If you are new to our office hours specifically, this is a space where we hold bi-weekly conversations to discuss different testing practices or tools, and explicitly how to implement them in a Kubernetes environment using Testkube.
Today's agenda will cover briefly what the concept of asynchronous testing entails, as well as the techniques and approaches we can take when implementing asynchronous testing specifically within Kubernetes. Of course, we will also look at the approach you can take with Testkube by leveraging our test triggers feature, and we will cover exactly what test triggers are. Feel free to ask any questions at the end or at any point during the live stream, as I am very happy to chat with anyone who is interested.
We will get started with the first part of this short talk: what is asynchronous testing? Simply put, asynchronous testing refers to testing our application automatically based on different events, situations, or triggers. Ideally, you wouldn't have to worry about synchronous testing—where you have to manually log in, look at a test, and click "run test" yourself. Instead, you can go about your day while your system triggers tests autonomously. Specifically in Kubernetes, this means being able to trigger tests based on various cluster events, such as a deployment, a job, an event, or configuration changes within a ConfigMap.
Implementing this practice in a Kubernetes environment does come with some notable challenges. Chief among them is the introduction of non-deterministic behavior, which makes it very difficult to predict exactly when a particular action will complete or when a specific event will be triggered. Additionally, Kubernetes itself introduces significant architectural complexity. Kubernetes applications often involve highly complicated, multi-step workflows. Testing each of these steps manually is not only incredibly time-consuming but also highly prone to human error, making it difficult to figure out how to implement an automated, asynchronous workflow that actually works. There are also dynamic scalability issues, as Kubernetes applications scale up and down on the fly, adding another layer of complexity to testing in general and asynchronous testing specifically.
To target these challenges, there are several different techniques that you might have already tried or heard about. One approach is implementing automation through your CI/CD pipeline, leveraging orchestration tools like Jenkins, Travis CI, or GitLab to handle your testing processes. Another technique is mocking and stubbing, where you simulate external services or components involved in asynchronous communication so you can isolate the component being tested and control the behavior of external dependencies. You might also use a service mesh to manage and monitor communication between microservices, which can help you configure asynchronous testing workflows. Finally, you can follow chaos engineering practices to proactively test how your applications respond to failures and delays. However, while these techniques can significantly improve asynchronous testing in Kubernetes, they often still require a lot of manual intervention and a massive amount of upfront work to set up and maintain properly.
This brings us to Testkube's test triggers. Testkube allows you to fully automate the execution of tests and test suites—which are simply groups of tests—by defining triggers tied to specific events across various Kubernetes resources. Simply put, a trigger defines an execution action that will run when a certain event occurs on a specific resource, all while adhering to a given concurrency policy. For example, we could define a test trigger that automatically runs a test suite whenever a ConfigMap gets modified or when our application undergoes a new deployment.
How do they work under the hood? Testkube uses a native Kubernetes concept called informers to watch cluster resources and register event handlers. Informers are a reliable, highly scalable, and fault-tolerant architectural concept. Each informer registers handlers directly with the Kubernetes API and gets instantly notified by Kubernetes on each event occurring on the watched resources. This is where it becomes incredibly valuable to leverage native Kubernetes capabilities, which is exactly what we focus on with Testkube. We use everything the platform naturally brings to the table to make testing better without needing to inject heavy, external components. It is simply utilizing what Kubernetes is already offering us.
I am going to show you how that works and what it looks like with Testkube. We will head over to cloud.testkube.io, sign in, and get started. Let me connect and manage my screen over here. I hope you are able to see it. At the same time, I am sharing our documentation link where you can check everything out for yourselves.
Looking at the Testkube documentation, you can navigate to the "Concepts" section to find all the information on your triggers, how they work, how they are built, their underlying architecture, and a deeper dive into informers. Implementing them is remarkably straightforward. You can review what a Testkube test trigger is, look at the Custom Resource Definition (CRD) model, and see how they are structured.
Here are the supported values for the different resources you can use to trigger events: you can trigger tests based on pods, deployments, services, ingresses, events, or changes in your ConfigMaps. The corresponding action can trigger the execution of either an individual test or an entire test suite whenever those specified resources are created, modified, or deleted.
Let's look at a practical example of how a test trigger is defined and how it looks inside Testkube. Swapping over to Testkube Cloud, you can see I have a bunch of tests here. Let's assume the scenario where I want to automatically trigger a test suite to run whenever my application undergoes a new deployment. I have a specific "load testing suite" here. Ideally, whenever there is a new deployment in my app, I want all the health checks and performance tests within this suite to run immediately without me having to manually press a button. Every time I push an update or a change occurs in my pod or cluster, Testkube should identify that event and detect that there is testing to be done to ensure everything works perfectly post-deployment.
To set this up, we click on the lightning bolt icon, which represents test triggers, and create a new trigger. We can name it "new-deployment" and select "deployment" as our target Kubernetes resource. Next, we provide a resource identifier—which is where you specify the name of your app—and set the event condition to fire when the deployment is modified. When that event happens, we configure the Testkube action to run a test suite, and we select our "load testing" suite by name.
Once created, we can view our trigger definition. The definition shows that we have a custom TestTrigger resource named "new-deployment" deployed on our Testkube namespace. It is configured to listen to a deployment resource on our application, and whenever that resource is modified, it will automatically execute the load testing suite we have ready in our dashboard. This allows you to easily edit your triggers on the go, add new conditions, change actions, and save updates seamlessly. That is exactly how...