The quick start guide helps to quickly deploy Gatling Operator and start a simple distributed load testing using Gatling Operator.
- Install kubectl and kind
- Clone the gatling-operator repository
Create a cluster using kind. 1.18 or higher version is recommended for the Kubernetes cluster. Node Images for kind can be found in the release notes.
kind create clusterkubectl apply -f https://github.com/st-tech/gatling-operator/releases/download/v0.9.0/gatling-operator.yamlExpected output would be like this:
namespace/gatling-system created
customresourcedefinition.apiextensions.k8s.io/gatlings.gatling-operator.tech.zozo.com created
serviceaccount/gatling-operator-controller-manager created
role.rbac.authorization.k8s.io/gatling-operator-leader-election-role created
clusterrole.rbac.authorization.k8s.io/gatling-operator-manager-role created
rolebinding.rbac.authorization.k8s.io/gatling-operator-leader-election-rolebinding created
clusterrolebinding.rbac.authorization.k8s.io/gatling-operator-manager-rolebinding created
deployment.apps/gatling-operator-controller-manager createdAll resources required for the Gatling operator, such as CRD and controller manager, are deployed using the command above. Now you're ready to deploy Gatling CR to run Gatling load testing.
The command above applies a Gatling Operator manifest of v0.9.0. Please change the version if necessary. You can check the version from the Release page.
Deploy a sample Gatling CR, as well as all resources required for the Gatling CR in the repository.
kustomize build config/samples | kubectl apply -f -
Expected output would be like this:
serviceaccount/gatling-operator-worker unchanged
role.rbac.authorization.k8s.io/pod-reader unchanged
rolebinding.rbac.authorization.k8s.io/read-pods configured
secret/gatling-notification-slack-secrets unchanged
gatling.gatling-operator.tech.zozo.com/gatling-sample01 createdAfter deploying the Gatling CR, Gatling Controller creates a Gatling Runner job. The job then runs the Gatling Runner Pods to execute Gatling load test scenario in parallel.
$ kubectl get gatling,job,pod
Expected output would be like this:
NAME RUNNED REPORTED NOTIFIED REPORTURL AGE
gatling.gatling-operator.tech.zozo.com/gatling-sample01 0/3 https://gatling-operator-reports.s3.amazonaws.com/gatling-sample01/318807881/index.html 24s
NAME COMPLETIONS DURATION AGE
job.batch/gatling-sample01-runner 0/3 24s 24s
NAME READY STATUS RESTARTS AGE
pod/gatling-sample01-runner-8rhl4 2/2 Running 0 24s
pod/gatling-sample01-runner-cg8rt 2/2 Running 0 24s
pod/gatling-sample01-runner-tkplh 2/2 Running 0 24s
You can also see from the Pod logs that Gatling is running.
kubectl logs gatling-sample01-runner-tkplh -c gatling-runner -f
Expected output would be like this:
Wait until 2022-11-28 00:34:56
GATLING_HOME is set to /opt/gatling
Simulation MyBasicSimulation started...
================================================================================
2022-11-28 00:37:17 5s elapsed
---- Requests ------------------------------------------------------------------
> Global (OK=2 KO=0 )
> request_1 (OK=1 KO=0 )
> request_1 Redirect 1 (OK=1 KO=0 )
---- Scenario Name -------------------------------------------------------------
[--------------------------------------------------------------------------] 0%
waiting: 0 / active: 1 / done: 0
================================================================================
================================================================================
2022-11-28 00:37:22 10s elapsed
---- Requests ------------------------------------------------------------------
> Global (OK=3 KO=0 )
> request_1 (OK=1 KO=0 )
> request_1 Redirect 1 (OK=1 KO=0 )
> request_2 (OK=1 KO=0 )
---- Scenario Name -------------------------------------------------------------
[--------------------------------------------------------------------------] 0%
waiting: 0 / active: 1 / done: 0
================================================================================
================================================================================
2022-11-28 00:37:27 14s elapsed
---- Requests ------------------------------------------------------------------
> Global (OK=6 KO=0 )
> request_1 (OK=1 KO=0 )
> request_1 Redirect 1 (OK=1 KO=0 )
> request_2 (OK=1 KO=0 )
> request_3 (OK=1 KO=0 )
> request_4 (OK=1 KO=0 )
> request_4 Redirect 1 (OK=1 KO=0 )
---- Scenario Name -------------------------------------------------------------
[##########################################################################]100%
waiting: 0 / active: 0 / done: 1
================================================================================
Simulation MyBasicSimulation completed in 15 secondsAs configured in the sample manifest, an aggregated Gatling HTML report is not created, nor a notification message is posted.
You can generate the Gatling HTML report by enabling .spec.generateReport flag and setting the .spec.cloudStorageSpec. Also you can posting the notification message by enabling .spec.notifyReport and setting .spec.notificationServiceSpec.
As a next step, let's generate the Gatling HTML reports for the Gatling load testing.
First of all, set .spec.generateReport in Gatling CR to true in order to generate an aggregated Gatling report. In addition, set .spec.cleanupAfterJobDone to true in order not to cleanup Gatling resources after the Gatling job done.
apiVersion: gatling-operator.tech.zozo.com/v1alpha1
kind: Gatling
metadata:
name: gatling-sample01
spec:
generateReport: true # The flag of generating Gatling report
generateLocalReport: false # The flag of generating Gatling report for each pod
notifyReport: false # The flag of notifying Gatling report
cleanupAfterJobDone: true # The flag of cleanup Gatling resources after the job doneThen, configure Cloud Storage Provider for storing Gatling reports in .spec.cloudStorageSpec. In this case, let's store the reports to Amazon S3 bucket.
Suppose that you want to store the reports to a bucket named gatling-operator-reports of Amazon S3 located in ap-northeast-1 region, configure each fields in .spec.cloudStorageSpec like this:
apiVersion: gatling-operator.tech.zozo.com/v1alpha1
kind: Gatling
metadata:
name: gatling-sample01
spec:
cloudStorageSpec:
provider: "aws"
bucket: "gatling-operator-reports"
region: "ap-northeast-1"You might want to add more configurations in .spec.cloudStorageSpec for Gatling Pods to access the Amazon S3 bucket. It depends on S3 authentication methods you choose. Please check Set Amazon S3 as Cloud Storage for more details.
📝 Note: There are multiple Cloud Storage Provider options. Currently Amazon S3, Google Cloud Storage, and Azure Blob Storage are supported. Please check User Guide for more details.
Once finish adding the Cloud Storage Provider configuration in the Gatling CR named gatling-sample01, deploy it and wait until it's done.
kustomize build config/samples | kubectl apply -f -You can obtain the Gatling report URL (reportUrl) by checking .status.
kubectl get gatling gatling-sample01 -o jsonpath='{@.status}' |jq
{
"reportCompleted": true
"reportStoragePath": "s3:gatling-operator-reports/gatling-sample01/318807881"
"reportUrl": "https://gatling-operator-reports.s3.amazonaws.com/gatling-sample01/318807881/index.html"
"reporterJobName": gatling-sample01-reporter
"reporterStartTime": 1669595852,
"runnerCompleted": true,
"runnerCompletions": "3/3",
"runnerJobName": "gatling-sample01-runner",
"runnerStartTime": 1669595687,
"succeeded": 3
}Here is a sample Gatling HTML report:
Finally, cleanup the Gatling CR manually
kubectl delete gatling gatling-sample01In this step, let's add Notification Service Provider configuration to the same Gatling CR named gatling-sample01 in order to notify Gatling load testing results via Slack.
First of all, set .spec.notifyReport to true in order to enable Notification Service Provider.
apiVersion: gatling-operator.tech.zozo.com/v1alpha1
kind: Gatling
metadata:
name: gatling-sample01
spec:
generateReport: true # The flag of generating Gatling report
generateLocalReport: false # The flag of generating Gatling report for each pod
notifyReport: true # The flag of notifying Gatling report
cleanupAfterJobDone: true # The flag of cleanup Gatling resources after the job doneThen, configure Notification Service Provider in .spec.notificationServiceSpec to notify Gatling load testing result via Slack. Suppose that you want to store credential info (Slack webhook URL) in Kubernetes Secret named gatling-notification-slack-secrets, you configure each fields in .spec.notificationServiceSpec like this:
apiVersion: gatling-operator.tech.zozo.com/v1alpha1
kind: Gatling
metadata:
name: gatling-sample01
spec:
notificationServiceSpec:
provider: "slack"
secretName: "gatling-notification-slack-secrets"You need to set Slack webhook URL value (in base64 encoded string) in the Secret for a Slack channel to which you want to deliver the message. The key name for the Slack webhook URL must be incoming-webhook-url.
apiVersion: v1
data:
incoming-webhook-url: <base64 encoded Webhook-URL string>
kind: Secret
metadata:
name: gatling-notification-slack-secrets
type: OpaqueOnce finish adding the Notification Service Provider configuration in the Gatling CR named gatling-sample01, deploy it again in the same way you did previously and wait until it's done.
kustomize build config/samples | kubectl apply -f -You'll get a Slack message like this:
Please check User Guide for more details on Gatling CR configurations.