How to test internal microservices in a kubernetes cluster

Hello guys, I have been working with kubernetes, docker, postman and newman a lot lately due some tests on internal microservices. To test these internal microservices I am running postman scripts in the same kubernetes cluster where the services are running.

Kubernetes is an open source container orchestrator, which means you can group together all the containers (services) that share information. You don’t need to expose their endpoints for them to be available among themselves. PS: This is just my brief explanation, but feel free to explore a bit more.

To be able to run tests on internal microservices that are inside a Kubernetes cluster I created a Postman collection and together with Newman run the tests pointing to these services without the need to expose the endpoints.

Creating the postman script

– You will need to have postman installed to create the script

– I am not going through the details of this part, because this is not the aim of this post, but after you create the script on postman you will need to export to api/collections folder.

– Also, you will need to export the environment variables that you create it and save it in the api/envs folder.

– You can see an example of the collection here and an example of the environment variable here. Remember that the hostname needs to be the name of the deployment of your service in kubernetes.

Creating the docker file

– I am using this docker image as base, but you can use any other, you just need to install newman.

– Then we need to build a Docker image containing the postman collection, environment and global variables, data files, etc.

– After this we need to create a jenkins file that will build and push the image to the docker hub, the best practice is you to have a separate pipeline just to build the image (so the tests contains just the tests and don’t take longer than necessary to run), but in this example I am going to have just a separate stage to build the image and another to run the tests.

dockerfile:

FROM postman/newman
WORKDIR /etc/newman/
COPY . /etc/newman/
RUN chmod -R 700 /etc/newman

Creating the kubernetes deployment

– Now we need to create the jenkins file to build and push the docker image to docker hub.

– You can get the full code here.

– But this is the important part, the command below will create a kubernetes deployment in the namespace and run the tests from the image that we have just pushed.

kubectl run microservices-tests -i --rm --namespace=${ENVIRONMENT} --restart=Never --image=${IMAGE}:latest --image-pull-policy=Always -- run /etc/newman/api/collections/collection.postman_collection.json -e /etc/newman/api/envs/${ENVIRONMENT}.postman_environment.json --reporters cli --reporter-cli-no-failures

  • microservices-tests is the name of the deployment that you are going to create.
  • -i Keep stdin open on the container.
  • --rm is the argument that says to delete this deployment once the command is finished.
  • --namespace=${ENVIRONMENT} is the name of the namespace (environment) that you will run this deployment, so it needs to be the same as your services are running.
  • --restart=Never is the argument that says to not restart the deployment once is finished. You don’t want your tests running over and over again forever.
  • --image=${IMAGE}:latest is the image that kubernetes is going to pull.
  • --image-pull-policy=Always this is to ensure that kubernetes is always pull the image even thought you have pulled before (this is to ensure you have always the latest).
  • -- this is to mark the end of the kubernetes commands and everything after is going to be the newman commands/arguments to run the postman script.

So, creating this deployment in the same namespace of your internal services, you can hit them and test the endpoints even though they are not external.

You should see something like this on your console:

This means that your script is running as expected in the cluster.

Thank you guys ! See you next time !

5 thoughts on “How to test internal microservices in a kubernetes cluster

  1. Rafa, i’m trying to make something simmilar in my kubernetes cluster using a CD pipeline.
    Can you control when the service starts receiving requests based on the test results?
    In my scenario when I apply my deployment it starts “replacing” the pods with the new ones, and a test would be possible only after the new api is already serving request users, and if it is misbehaving, the user is being affected.

    Please, as an experienced professional, what would you suggest me?
    Tks!

    1. Hi Andre, so you have a pod running your tests that is started after your other pod with the api is created ? Or your pod runs the api and the tests together ? I believe you can add a retry mechanism if the pod is the same, or add a trigger to run the tests just after you get the log from the api that is up and running, if the pods are different, I would say to check if the other pod has the running state, something like this:

      kubectl get pods –field-selector=status.phase=Running

  2. Hello Rafa, can we have automated tests that can talk between microservices deployed in different namespaces, rather than same namespace ?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.