In this post, I will talk about what you need to pay attention to after migrating your application to an infrastructure managed by Kubernetes. Here I will list the main steps to follow no matter what your application is about.
Your team may insist that no testing is required. After all, Kubernetes is designed to increase the stability of the application. But it may happen that at a crucial moment a failure occurs and it turns out that the problem, which was previously solved in a couple of minutes, will be practically unsolvable in Kubernetes. Therefore, you need to check everything while everything is calm.
Get to know Kubernetes
The very first thing you need to do is learn what kubernetes is and how to interact with it. To do this, firstly, you can read the information on the official website. You will also find a bunch of videos explaining what Kubernetes is and how to use it.
What you need to know before you start testing the Kubernetes environment:
- what is Docker, containers and images
- what a pod is and why it’s not the same as container or server
- Kubernetes components: deployments, replicasSets, services, clusters
- kubectl commands
- optional but very useful: create your own cluster with minikube
Regression
The main thing to do after migrating to Kubernetes is to make sure that the application works the same as before. So forget for a while where your application is running and focus on finding new bugs. Explore your application again and understand how it works now. Find differences and find out if the new behavior is expected.
Access
Ensure that any team member can access the new infrastructure. At this stage, you are not testing the application or Kubernetes features, but the processes within the team. It may turn out that no automation is configured for this. In this case, it will take several days and unsuccessful attempts to provide the developer with access to the infrastructure.
Configuration
Before migrating to Kubernetes, managing your application settings was a simple task. All that had to be done was to go to the server where the application is running and change the contents of the configuration files and environment variables.
Now this process has changed. The first thing to do is make sure that changing the configuration is possible at all and that the settings are not hardcoded somewhere. Also make sure there are access levels that allow someone to change the configuration. It would be ideal if there were instructions on how to do this now.
The second thing to check is that the configuration change applies to the application. There may be cases when some settings need to be changed strictly in a certain place, and changing them in other places will not change anything. Also, it is worth checking that all discrepancies found will be reflected in the instructions.
Do not test Kubernetes
Kubernetes provides a large number of features that increase the stability of your application. This is most likely why your team decided to migrate. You will be very tempted to test Kubernetes features. And this aspiration is correct. The main thing to understand is that you are not testing the feature itself, but you are testing the correctness of setting up your application to use these features. As a simple example, let’s look at two simple tests:
- Kill a pod by hand and make sure that the Kubernetes will raise a new pod in place of the killed one. This is a great test for Kubernetes testers. But you already got it tested (I hope).
- Load the pod so that it stops responding to incoming requests and check that Kubernetes will launch a new pod instead. This test verifies that pod health monitoring is configured correctly and Kubernetes receives the right signal to act in time.
Finally
Your team may decide to use or not use any of the Kubernetes features. Therefore, the specific list of checks depends on the chosen Kubernetes configuration.
Keep in mind that when migrating to Kubernetes, you will most likely use additional tools that make it easier to interact with Kubernetes environment or manage the build process. Ask the team for the full list and see how you can test them.
