Mocking Kubernetes Services On Demand

Introducing on-demand service mocking in Kubernetes!

Hosting mocks in Kubernetes is tough for numerous reasons. We’ve recently added a new feature to UP9 enabling developers to replace live Kubernetes services with autogenerated service mocks in just one click. Yes, you read that correctly:

Effortlessly replace any number of live Kubernetes services with autogenerated mocks in ONE CLICK

Assume you have a Kubernetes cluster already running. To properly debug and troubleshoot, you decide to replace a number of live services with service mocks so you can control their behavior while troubleshooting certain APIs.

Autocreate and continuously update service mocks for all services

If you don’t already have a UP9 account, see these instructions to install and run UP9 on your Kubernetes cluster.

Installing UP9 on your Kubernetes cluster will cause UP9 to observe the API traffic, build a model of your system, as well as create and maintain mock configurations for each and every service. The service mock configuration can be used by our Open Source mock engine, Mockintosh. Learn more about the Kubernetes-ready mock engine by visiting: https://mockintosh.io/.

Replace live services with autogenerated service mocks

Let us assume UP9 is installed on a Kubernetes cluster currently running a microservice application that includes ten services:

Kubernetes cluster

The above snapshot is taken from the UP9 dashboard, and is the result of the following execution:

Copy to clipboard
kubectl get pods -A

From the above list of Kubernetes services, let us say you want to replace the following two live services with auto-generated service mocks:

  • catalogue.sock-shop
  • carts.sock-shop

Once service replacements are chosen, you would use the following command:

Copy to clipboard
up9 mock:switch -w my-model -s catalogue.sock-shop -s carts.sock-shop -p 8000

The above command consumes the autogenerated mock configuration for the two services from a UP9 workspace named my-model, and replaces those two services with a service mock.

Let’s examine the outcome

A quick indication in UP9’s services map shows the two services - catalogue.sock-shop and carts.sock-shop - are now virtual.

Kuebernetes mocks

In the process, a new service was added to the Kubernetes cluster named: up9-mockintosh. This new service will now mock the two live services: catalogue.sock-shop and carts.sock-shop.

The mock’s control plane is accessible via the port that was provided in the mock:switch command. In this case, you can view the mock's control plane by pointing your browser to: https://localhost:8000.

Through the control plane, you can then view, debug, and change the mock configuration on the fly without having to restart the mock or the Kubernetes cluster.

Mock control plane

Reverting back

When you’d like to return the cluster to its original state, use the following command:

Copy to clipboard
up9 mock:switch -w my-model --reset --all

Conclusion

In situations where you’d like to control service behavior (usually for the purpose of troubleshooting and debugging certain behaviours), you may want to replace your live services with service mocks.

Mocking in a Kubernetes cluster can be a challenge when compared to classic mocking. UP9 enables you to point and click to services you’d like to replace with autogenerated mocks, keeping the process as effortless and automated as possible.