Load testing is an essential part of the software development process to ensure the performance and scalability of applications. As more and more organizations move to Kubernetes to manage their containerized workloads, load testing in a Kubernetes environment presents unique challenges.
Join us for our Office Hours as we go through the best practices and tools for load testing in Kubernetes - and how Testkube can help address common pitfalls.
In this webinar, 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 everyone! I think we're starting a little late, and I'm sorry about that, but we're all good. Hello, I hope you guys are doing great. It's almost the weekend, and I'm excited to talk to you today. First of all, welcome to Testkube office hours, where we open our virtual office doors to talk about all things testing in Kubernetes, update you on what we're doing, share the cool features that the devs are building, and discuss anything related to testing in Kubernetes.
Today I'm really excited about our topic. We're going to be talking about load testing in Kubernetes. This is such an important practice that is universally acknowledged for its relevance in ensuring good quality in our applications. I'm going to go through the agenda real quick. We'll do the usual, covering briefly what load testing is, sharing some of the load testing best practices that we recommend specifically when you're dealing with Kubernetes applications, brushing over some load testing tools, and finally showing how to do load testing with Testkube.
First, we're going to cover what load testing is. I'm pretty sure that if you're watching this, you're probably already familiar with it and might already put it into practice. Load testing is a type of performance testing. We actually touched upon this a while ago during one of our first office hours in the last couple of months, where we dove deep into the different types of performance testing. Load testing helps us simulate different loads to check the performance of our system under certain conditions and scenarios to see how our application will behave. Let's say, for example, that we want to release a web application and we're expecting a ton of users. We simulate that with load testing to see if our web application and our infrastructure are stable enough to make it through that huge load.
There are definitely different types of techniques, such as stress testing, spike testing, soak testing, and so on. These are great for maximizing the capacity of our software application and determining if our latest infrastructure changes or updates are capable of maintaining the application and keeping it usable under these loads. It helps determine sustainability, finds out the total amount of users the system can actually sustain, and determines availability, which is super important because we are working with really big Kubernetes applications. Ultimately, this allows for more people to come and use our software.
Now we'll touch on some best practices that we really recommend, specifically when you're getting started with your testing system or when you are trying to transition into using Kubernetes. The first thing I want to emphasize is the importance of starting small. With load testing, you ideally want to be able to test those huge loads coming to your application, but before running these large-scale load tests, we really recommend starting with small-scale tests to make sure your application works as expected. Gradually increasing the load will help you identify and fix any issues before you throw everything at it.
The second best practice is using real-world scenarios. Obviously, you want to simulate reality as much as you can because this is crucial to understanding how your application will actually behave and perform under specific, highly likely conditions. This can include simulating user behavior, network latency, and any other variable that can impact performance. Another critical point is monitoring your infrastructure. Since you're throwing all these scenarios and loads at your application, it is vital that you actively monitor your Kubernetes infrastructure at the same time. This helps you identify performance bottlenecks and other issues by monitoring CPU usage, memory usage, and network traffic under these loads. We recommend using observability tools and traces to check your application's health. A slight plug here, but we really recommend Tracetest for this; check it out, as it's pretty great for monitoring the infrastructure under these conditions.
Finally, it is super important to use load testing tools that are designed for Kubernetes. There are several tools available that are specifically kubernetes-friendly, including k6, Gatling, and Locust. These tools are designed to support and work really well with Kubernetes, which can simplify your load testing process because you don't have to do anything extra to adjust them; they will just work out of the box.
Let's cover these three tools a bit more. k6 is open-source and specifically designed for modern architectures like Kubernetes. It offers a simple scripting language using JavaScript, so you just write your scripts to simulate different loads. It also supports distributed load testing, which is great for Kubernetes environments where you want to test multiple things at once. Gatling is another popular open-source tool that comes with a very user-friendly interface and provides real-time monitoring of performance metrics. It can easily be integrated with Kubernetes using its built-in Kubernetes plugin. Then you have Locust, which is also an open-source load testing tool with a very intuitive interface, making it very easy to get started. It supports distributed load testing as well and easily integrates with Kubernetes via its plugin. While the last two come with out-of-the-box support through plugins, k6 can be implemented very easily thanks to its clean scripting structure.
Now that we've covered the tools, I will show you how to get started with actually running some load tests in Testkube using k6. As I mentioned, it's very simple to write a script and see it in action. I'm going to share my screen so we can create a simple test. Aside from my very geeky wallpaper, you can see I have VS Code over here and Testkube Cloud over there. Remember, you just need to sign into Testkube Cloud to start testing. Once you're signed in, have created your environment, and have installed your first agent, all you have to do is create a test.
Let's name this test "app-load-test" and create a k6 script. I should mention that we also support JMeter, and we'll touch upon some really cool updates we did to the JMeter executor in the future, so stay on the lookout for that soon. The source for your script can be a GitHub repository, a file, or even a string, which is pretty handy if you just want to check something real quick. Let's create a JavaScript file here in VS Code. We are going to import the necessary modules from k6. My GitHub Co-pilot is trying to help me out—the real one, anyway! We import that from k6, and don't forget your semicolons, as I'm a semicolon girl.
We'll create a script to check for different loads using stages. Co-pilot is doing everything for me, which is pretty cool. We can set a duration of 30 seconds to simulate a load of 100 users, but let's go a little lower so it runs faster. Let's try a duration of 5 seconds with a target of 20 users, and then add another 5 seconds targeting 10 users. We'll close that up, and then we'll create the function that executes it all. Since I've run this before, I will grab the URL we are going to test, define it, and then check the HTTP status. Exactly what we want is to get an HTTP result of 200, which means the request was successful. Let's make sure everything is correct and save the file.
Now, back in Testkube Cloud, we will import it as a file, browse for it, and select it. Once created, we can check the definition of our test, and as you can see, our script is defined as a Custom Resource Definition (CRD). We can run the test now, display the logs, and see the load testing happening in real time, which is pretty cool. It's running, iterating, and completing the simulations. Let's run it again—actually, let's just go ham on it. It wasn't showing the logs for a second, but I just needed to reload, so sorry about that. As you can see, it was a 100% success with 44 tests completed and zero interrupted iterations. This means that regardless of the load coming in, we always got that HTTP response of 200 based on our targets.
This is great for simulating visits on your web app. Another thing you can do is schedule it. Let's say you want to run these load tests every hour or every five minutes as a smoke test. Alternatively, you can trigger it every time you make changes to your infrastructure, push new code, or make a new deployment to verify everything still works. You can easily set this up under test triggers based on deployments or code changes. I will link you guys to the documentation because our team works incredibly hard to provide guides, articles, and tutorials on how to implement these different use cases. I think that's pretty cool, and I hope you take a look.
Let's go back to the presentation and close off this session by saying thank you so much for watching. I hope this was helpful in some way. As I said, we have so much content. We recently launched our learn section and our testing handbook program, which is full of little snippets and nuggets like this where you can see how to put specific tests into action and implement different tools. Make sure to check that out at testkube.io/learn. Wow, I'm learning a lot with this streaming thing!
We'll wait for you there. Join our Discord if you have any questions on how to perform your testing in Kubernetes; we're very happy to hop on and talk to you if you need specific assistance or help just getting Testkube set up so you can start running tests in no time. If you want to talk to our product lead to suggest features or share requests, feel free to message Bruno at bruno@kubeshop.io.
I'll see you on the next one! Thank you so much for joining. Oh, hi Git! Sorry that you missed the live part, but this is going to be recorded and available on our LinkedIn and YouTube. If you have any follow-up questions, please leave them here and I'll make sure to go through them. Thank you so much for joining, have a nice day everyone, bye!