This is repository contains load tests for Kubewarden's policy server. Load tests are done using locust.
The repository defined two types of tests, defined inside of these directories:
direct-connection: locust is going to hit Kubewarden's Policy Server directly. This test is useful to understand how well Policy Server is behaving.indirect-connection: locust is going to simulate a user making operations against the Kubernetes API server. These requests will cause the Kubernetes API server to reach out to the Policy Server. The requests per seconds (RPS) reported will be significantly lower in this case. This test has been created because initial versions of Policy Server were affected by a rare bug that caused the Policy Server to halt. This bug was reproducible only when the connections were originated by Kubernetes' API server. See this issue for more details.
Which test should you run? That depends on your scope. If you want to be sure
your changes didn't introduce any performance regression, then use direct-connection.
Deploy the Kubewarden stack ensuring:
- The stack is deployed inside of the
kubewardenNamespace - A
defaultPolicy Server exists
This can be achieved by following the quickstart documentation of Kubewarden.
Once the whole stack is up and running, deploy the following policies:
kubectl apply -f policies.yamlEnsure the default Policy Server instance is up and running:
kubectl get pods -n kubewardenTests are going to run inside of a Kubernetes cluster, the same cluster where the Kubewarden stack is deployed.
We're going to install locust using this helm chart.
Follow these steps:
helm repo add deliveryhero https://charts.deliveryhero.io/The containerized locust will then load the testing code from two ConfigMaps:
one holding the main.py and the other containing python support files or
fixtures.
First of all, let's create a Namespace for all the locust resources:
kubectl create ns locustThen, let's create the ConfigMaps used by the direct tests:
kubectl create configmap -n locust kubewarden-locustfile-direct --from-file direct-connection/main.py
kubectl create configmap -n locust kubewarden-locust-direct-lib --from-file direct-connection/libFinally, let's create the ConfigMaps used by the indirect tests:
kubectl create configmap -n locust kubewarden-locustfile-indirect --from-file indirect-connection/main.py
kubectl create configmap -n locust kubewarden-locust-indirect-lib --from-file indirect-connection/libNow we have to decide which kind of testing suite we want to run.
To perform the direct-connection test, execute the following command:
helm install -n locust locust deliveryhero/locust -f direct-connection/values.yamlTo perform the indirect-connection test, execute the following command:
helm install -n locust locust deliveryhero/locust -f indirect-connection/values.yamlTo perform the inderect tests, a special RBAC rule must be defined. This has to be done once, by executing the following command:
kubectl apply -f rbac.yamlThis RBAC rule grants admin
access to the resources defined inside of the default Namespace to the
Service Accounts associated with locust. This is required to fake user requests
inside of the default Namespace (where the AdmissionPolicy policies are
enforced) to the Kubewarden stack (which lives inside of a different Namespace).
To switch from the two tests, peform the a command similar to
to the next one, just pick the right values.yaml:
helm upgrade -n locust locust deliveryhero/locust --values indirect-connection/values.yamlThis command, for example, ensures the indirect-connection tests are going to be run.
To access locust's UI, execute the following command:
kubectl port-forward -n locust service/locust 8089:8089Leave the command running and open localhost:8089 with your browser.
Customize the load test settings and press "start swarming".
Note: ensure the right
Hosthas been populated, especially if you switched between the two different test suites.