added docs for testing

docs/pages/load-testing/results.mdx

@@ -0,0 +1,88 @@
+---
+title: Test results
+sidebar_label: Results
+---
+
+## Summary
+
+This is a TL;DR of the test results, the detailed results are further down. During our testing, k3s with sqlite has been trailing the other distributions when running high intensity loads. For less intensive usage however, it has been a little slower than the others but staying well within the usable range. The simplicity of its deployment comes with a few downsides.
+If you plan on having high api usage in your vClusters, we recommend using an etcd backed distribution as you will most likely experience timeouts or throttling with the sqlite backed distribution. For lesser usage, the k3s sqlite will be as adequate as the others.
+
+
+## API requests response time
+
+<figure>
+  <img src="/docs/media/diagrams/api-average-baseline.svg" alt="apiserver-avg-baseline" />
+  <figcaption>APIserver average response time (baseline)</figcaption>
+</figure>
+
+During our baseline testing (300 secrets, 30qps), the k3s with sqlite has been significantly slower than the other distributions, with an average of 0.17s while the other distributions were all around 0.05s. This however should not have an impact since 0.17 is still a relatively good average.
+
+
+<figure>
+  <img src="/docs/media/diagrams/api-average-intensive.svg" alt="apiserver-avg-intensive" />
+  <figcaption>APIserver average response time (intensive)</figcaption>
+</figure>
+
+For our more intensive testing (5000 secrets, 200qps), the differences between the distributions are more visible, with the k3s with sqlite trailing with 1.4s average response time while etcd k3s (pro distro) has an average response time of around 0.35s for both single node and HA setup. k0s and k8s are the fastest here with an average of around 0.15s. Below is also the cumulative distribution of request time.
+
+
+<figure>
+  <img src="/docs/media/diagrams/api-cumu-dist-intensive.svg" alt="apiserver-cumu-dist-intensive" />
+  <figcaption>Cumulative distribution of request time during the intensive testing</figcaption>
+</figure>
+
+## CPU usage
+
+During our testing, most distribution had similar cpu usage, with the exception of k3s with sqlite which had a higher CPU usage, most likely due to having to convert etcd requests into sqlite ones.
+
+<figure>
+  <img src="/docs/media/diagrams/cpu-usage-baseline.svg" alt="cpu usage (baseline)" />
+  <figcaption>CPU usage during the baseline test</figcaption>
+</figure>
+
+<figure>
+  <img src="/docs/media/diagrams/cpu-usage-intensive.svg" alt="cpu usage (intensive)" />
+  <figcaption>CPU usage during the intensive test</figcaption>
+</figure>
+
+<figure>
+  <img src="/docs/media/diagrams/cpu-usage-intensive-ha.svg" alt="cpu usage (intensive) for ha setups" />
+  <figcaption>CPU usage during the intensive test (ha setups)</figcaption>
+</figure>
+
+## Memory usage
+
+The memory usage has been relatively similar in all setups
+
+<figure>
+  <img src="/docs/media/diagrams/memusage-baseline.svg" alt="memory usage over time sn setup" />
+  <figcaption>Memory usage during the baseline test</figcaption>
+</figure>
+
+<figure>
+  <img src="/docs/media/diagrams/memusage-intensive.svg" alt="memory usage over time sn setup" />
+  <figcaption>Memory usage during the intensive test</figcaption>
+</figure>
+
+<figure>
+  <img src="/docs/media/diagrams/memusage-intensive-ha.svg" alt="memory usage over time sn setup" />
+  <figcaption>Memory usage during the intensive test with HA setups</figcaption>
+</figure>
+
+## Filesystem use
+
+The filesystem usage has been higher in the k3s sqlite version compared to all etcd backed versions in the intensive setup. In the baseline setup there was little to no usage of the filesystem
+
+<figure>
+  <img src="/docs/media/diagrams/fs-write.svg" alt="fs usage over time" />
+  <figcaption>Filesystem writes over time</figcaption>
+</figure>
+<figure>
+  <img src="/docs/media/diagrams/fs-read.svg" alt="memory usage over time sn setup" />
+  <figcaption>Filesystem reads over time</figcaption>
+</figure>
+
+## Pod latency
+
+kube-burner calculates some statistics on pods, however it uses the status of the pods which only has a precision of seconds. With this precision all the distribution had similar p50, p99, average and max for containerReady, Initialized, podScheduled and Ready.

docs/pages/load-testing/setup.mdx

@@ -0,0 +1,12 @@
+---
+title: Test setup
+sidebar_label: Setup
+---
+
+Our testing has been done through kube-burner, with an EKS cluster as the host cluster, in the eu-west-3 region. All the configuration files are located [here](https://github.com/loft-sh/vcluster/load-test). You will need to change the default storage class from gp2 to gp3.
+
+To monitor the metrics, you should install the [kube-prometheus](https://github.com/prometheus-operator/kube-prometheus) operator, and give it the permission to list the pods, services, endpoints and serviceMonitors modifying the `prometheus-k8s`clusterrole in the namespace you will deploy your vClusters in (or in all namespaces for a faster edit).
+
+The APIs should be exposed (using the `--expose` vCluster option). You can either create the service monitor manually or use the helm values, to have vCluster create it for you. Make sure that prometheus has done at least one scrap to your vCluster api before running kube-burner, as it would other result in missing data for some metrics.
+
+To run the tests, run `kubectl --namespace monitoring port-forward svc/prometheus-k8s 9090` to have the host cluster's prometheus forwarded to your local machine, then `vcluster create --expose -f yourConfig yourCluster` to start your vCluster. Once everything is ready and prometheus has detected your api servers you will be able to run `kube-burner init --metrics metrics.yaml -c config.yaml -u http://localhost:9090`

load-test/clusterconfig.yaml

@@ -0,0 +1,23 @@
+apiVersion: eksctl.io/v1alpha5
+kind: ClusterConfig
+metadata:
+  name: simple-cluster
+  region: eu-west-3
+
+nodeGroups:
+  - name: ng-1
+    instanceType: m5.large
+    desiredCapacity: 6
+    iam:
+      withAddonPolicies:
+        ebs: true
+iam:
+  withOIDC: true
+
+addons:
+- name: vpc-cni
+  attachPolicyARNs:
+  - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
+- name: aws-ebs-csi-driver
+  wellKnownPolicies:      # add IAM and service account
+    ebsCSIController: true

load-test/gp3.yaml

@@ -0,0 +1,13 @@
+apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+  annotations:
+    storageclass.kubernetes.io/is-default-class: "true"
+  creationTimestamp: "2023-11-15T09:35:19Z"
+  name: gp3
+parameters:
+  fsType: ext4
+  type: gp3
+provisioner: kubernetes.io/aws-ebs
+reclaimPolicy: Delete
+volumeBindingMode: WaitForFirstConsumer

load-test/ha-k8s.yaml

@@ -0,0 +1,23 @@
+
+# Enable HA mode
+enableHA: true
+
+# Scale up syncer replicas
+syncer:
+  replicas: 3
+
+# Scale up etcd
+etcd:
+  replicas: 3
+
+# Scale up controller manager
+controller:
+  replicas: 3
+
+# Scale up api server
+api:
+  replicas: 3
+
+# Scale up DNS server
+coredns:
+  replicas: 3