How to test my microservices before deploy to kubernetes?
I am creating a very small microservices environment for testing purpose. It looks as follows:
As you can see on the image, Istio is installed in the k8s cluster to use service mesh.
I wrote the BOO service, but do not know how to test the service, because it calls FOO and ZOO services.
I could mock FOO and ZOO services but when in the future the BOO services calls 10 further services, then it does make any sense then to mock all services.
What the best way to test my microservices before deploy to kubernetes?
Similar Questions
2 Answers
Deploy them to Kubernetes, but somewhere other than your production environment.
There are a couple of straightforward ways to get Kubernetes clusters. You can use tools like minikube or kind to get a Kubernetes cluster on your local system (in a VM or a Docker container, respectively); if you're in a cloud environment then offerings like Amazon EKS or Google GKE can give you a cluster as large or small as you want. Once you have the cluster you can install tools like Helm (v2) and Istio on it, and then run the exact same deployment scripts you normally do to deploy your services into that cluster.
If this becomes a large number of services, it could be useful to leave a test environment running all the time, and set up your CI system to deploy into both the production and test environments.
Even with this there is room for the mock approach you describe here: it is vastly easier to test and debug a service using its local unit-test tree than to deploy it somewhere. I generally write unit tests based on mock services, and then also write integration tests based on a deployed set of services (and if the integration tests fail, reproduce the issue with the mocks).
I use minikube in an old pc for development, I deploy almost the same kubernetes entities than in the production cluster.
A thing I do and I recommend during the the development/testing of a service is to have all the entities in individual files, this is helpful to have scripts that transform the files from production to development.
In my case the helper scripts change the namespace, some secrets, volume details, mount some paths, config maps, etc, this way I can have a new namespace for any feature or bug, when I am done with the feature I remove the namespace or destroy the minikube instance.
I have the main functionalities separated in a way that I only need to deploy to a new namespace the minimal functionality to work on a feature.
I have a cluster up and running that is opensource, you can check what I am talking about in the actual code and deploy it to you minikube cluster: repository
I have been working having everything replicated by namespace and separate the main functionalities, this has been really useful for me to move from feature to feature, I don't involve any CI during development, only transform production to dev and apply to minikube