How to Test Microservices in Kubernetes

In this article, you will learn about some of the tools to test microservices running in a Kubernetes cluster. In particular, we will compare the Speedscale CLI tool with other tools and  the main benefits of using Speedscale CLI.

In the last few years, software companies have been shifting from building monolith applications to utilizing smaller microservices. In a microservices architecture, you operate with decentralized applications. This means that there’s a separation in which each service is responsible for a specific component of your application.

In many instances, microservices are built as containers and deployed to a cluster, like Kubernetes, an open source platform for managing containerized workloads and services. There are other alternatives for running your containerized application, like Rancher and HashiCorp Nomad; however, Kubernetes is more developed in terms of scalability, community support, and usage, making it the superior choice when it comes to microservices.

When making the shift from a monolith application to microservices, it’s vital to ensure proper communication between the various microservices. In any application, it’s crucial to test your code in a staging environment before going to production. One of the most important aspects of this staging environment validation is testing APIs to ensure they return correct responses and are able to handle errors gracefully.

Since its rapid adoption and popularity, testing your hosted containers running in Kubernetes hasn’t really evolved. As a result, various tools have been developed to help with testing APIs, like Speedscale, hey, and gRPCurl.

Testing Microservices in Kubernetes

Before you learn more about the tools used for testing microservices, you need to fully understand how networking works in Kubernetes.

Kubernetes pods consist of one or more containers running on the same node. Pods are able to communicate with each other via their IP addresses. However, this is not ideal because the ephemeral nature of a pod means that a pod can be destroyed and recreated at any time—sometimes on a different node. This results in the pod having a different IP address each time. A Kubernetes service is the solution to this problem.

Kubernetes services allow you to communicate with pods using a DNS routing system, which provides consistent DNS names instead of IP addresses. A service provides the domain name within the cluster that redirects traffic to a group of pods with the same labels.

As noted previously, the ephemeral nature of pods (which results in constantly changing IP addresses) makes network access within a cluster more restricted, and as such, conventional testing tools cannot be used.

Please note: While this article covers a lot of tools, there isn’t a standard tool for testing microservices at this time. curl has proven to be the most popular and most used solution to date, but some of its solutions are out of date, and newer tools have emerged to try and replace curl.

Ways to Test Microservices

In this section, you’ll be looking at various microservices and how you can test them. The following tools have been chosen based on their ease of use, installation experience, and developer support.

Speedscale CLI

The Speedscale CLI tool is a container-centric tool for recording traffic flowing to and from your applications. While other tools, like curl, give you the raw request and response data, Speedscale CLI does more by providing you with metadata, including request latency, encoding, and detected technologies.

Speedscale CLI uses a proxy to capture your microservices’ inbound and outbound traffic. This lets you obtain specific details about your microservice network but at a higher level than looking at packets when using tools like Wireshark. You’re able to view all calls going into and out of your microservice with details for various protocols, including gRPC and PostgreSQL. It also lets you detect slow API endpoints and high latency from a third-party tool or database, and you can visualize network communication. With the Speedscale CLI tool, you’re able to understand the relationship between your microservices and their external dependencies.

The tool is free to use, but additional features, like reporting and load testing, can be unlocked with a monthly subscription. The installation is simple, and the tool is easy to use.

To install, run the following commands on your terminal:

​​sh -c "$(curl -sL https://downloads.speedscale.com/speedscale-cli/install)"

Then initialize Speedscale and follow the instructions:

speedscale init

You can find more information on how to get started with Speedscale with the README file on GitHub.

curl

According to their official documentation, curl is “a command line tool and library for transferring data with URLs.”

curl is used to make HTTP and HTTPS API calls and, as previously stated, has been one of the most popular tool for testing microservices. However, newer tools—like Speedscale CLI, hey, and gRPCurl, with features like request authentication against APIs (technically possible in curl with some labor), JSON syntax highlighting for responses, script automation for tests, and versioning requests—have begun to replace curl.

curl is easy to install and use, and it has a lot of community support, so issues can be addressed quickly. It supports SSL certificates, HTTP, FTP uploading, HTTP form-based upload, proxies, HTTP/2, HTTP/3, cookies, user+password authentication, and more. curl is free to use, is open source, and has a large community of developers who actively maintain it.

curl is a useful command line tool, but it does not include features like encoding, traffic filtering, and measuring of CPU, requests per second, and latency, which tools like Speedscale CLI do support. With curl, you could measure the latency of your requests but only by adding the verbose “–trace-time” flag which adds timestamps, but all calculations are manual. In addition, you cannot capture requests made from the application itself, which makes it difficult to understand what is going out.

hey

hey is a lightweight tool written in Go that performs well and has the necessary functionalities to run load tests on a web application. It is useful for load testing and was designed as an alternative to ApacheBench (ab). In contrast to ab, hey supports HTTP/2 protocol and HTTP/2 adoption, which are much higher than previous protocols (like HTTP/1 or HTTP/1.1).

To install hey, visit the hey GitHub page and follow the instructions available. After you have installed, you can run a load test by simply writing a command line on your terminal. Here’s an example:

hey -n 30 -c 3 -m POST -T "application/x-www-form-urlencoded" -d 'username=admin&message=hello world' http://your-post-url/addNote

This opens three parallel connections and sends thirty requests. Each request consists of a post form with two parameters.

hey and Speedscale CLI are both great tools for load testing, and with either of them, you can perform different kinds of tests on your application with a single tool. However, using Speedscale CLI ensures you can also monitor your application in real time as it is load tested. With hey, you cannot monitor performance and detect slow requests like you can with Speedscale CLI.

gRPCurl

gRPCurl is a command line utility that allows you to interact with gRPC microservices. It allows you to call gRPC methods directly from the command line, similar to how you would interact with HTTP endpoints using curl. It supports all gRPC methods, including streaming and bidirectional streaming methods. gRPCurl supports secure/TLS and plain-text servers, and it has different options for TLS configuration.

For installation, go to the gRPCurl GitHub page and follow the instructions. Once installed, it is easy to get started with testing gRPC microservices. The following are some examples to get you started.

Here is a command to show you the usage doc:

grpcurl -help

To invoke a RPC on a trusted server, use the following code:

grpcurl grpc.myserver.com:443 my.grpc.server.Service/Method

To send a non-empty request, use a -d argument:

grpcurl -d '{"id":1002, "name": "John", lastname: "Doe"}'  grpc.myserver.com:443 my.grpc.server.Service/Method

The Speedscale CLI tool also lets you measure the flow of gRPC traffic within your application. You can process the data it captures further as you would any other HTTP traffic. Find more information on how to inspect outgoing gRPC requests on the gRPC website.

ApacheBench

ApacheBench (ab) is a command line program used to test the Apache HTTP server, but it is generic enough to test any web server supporting HTTP/1.0 or HTTP/1.1 protocols. It is installed on Mac by default.

ab -h

If using Windows, visit Apache Lounge and download the latest Apache binary version for Win64 as a zip file. Extract it to a directory on your system. Once extracted, ab can be used via the ab.exe.

However, even after completing the installation, ab still cannot be used until you complete the following steps:

• Open your terminal and go to the directory where you have ab.exe.
• Use the ab command to determine which URL you want to test.
• Use one of the following parameters to determine the testing method: -k, -n, or -c.

Here is an example:

  ab -k -n 200 -c 10 http://www.draft.dev/

Above, you performed 200 requests and used the HTTP keep-alive feature for Draft.dev.

Although ab is an easy tool to use, the capabilities are basic (ie single-threaded, failed requests, complete requests, etc.), which does not give your requests latency. With Speedscale CLI, you can visualize dependencies of your API and inspect message headers, message bodies, and more.

Conclusion

In this article, you learned about various tools that can be used to test microservices in Kubernetes and looked specifically at how those tools compared to the Speedscale CLI tool.

Speedscale helps you keep track of traffic flowing through your application by tracking snapshots of network traffic to and from your application so you can analyze it later. This is useful when testing microservices because it lets you monitor what is happening in between your services by giving you all the pieces of your requests (ie request headers, request body, etc.), from latency (ie request duration) to encoding (ie UTF-8), as well as the technologies used, like gRPC and PostgreSQL. You can learn more through the Speedscale tutorial.