Skip to main content

Optional Replay Annotations

Just add annotations to your deployment and the operator will take care of the rest.

Here are additional annotations for customizing your replay

AnnotationDescription of the TrafficReplay Custom Resource tied to a replay for this workload of the Snapshot that is used to recreate traffic. of the test configuration used to recreate to traffic. (Default: standard) a unique tag, build hash, etc. to the Speedscale report. That way you can connect the report results to the version of the code that was tested. how a replay will test the system. Values are full-replay, responder-only, and generator-only (default: full-replay). full-replay will deploy generators to recreate observed requests, and responders to recreate observed responses. responder-only will create an infinitely running replay that responds to requests with observed responses. generator-only will recreate obeserved requests to the system under replay. a timeout for a replay. Ignored when replay mode is responder-only this setting to provide a list of secrets for the replay system to load (ex: JWT passwords). up provisioned resources after a traffic replay. Possible values: inventory, all, none (default: inventory). inventory will remove objects related to Speedscale's replay of traffic once finished, as well as reverting changes to the workload. all removes all replay objects, as well as the system under test. none will leave all resources on the system after a test run. this setting to override the URL the generator automatically determines (useful if you have customized your service definition). to "true" to collect logs from the system under test (default: true). to "true" to force the responder into a high efficiency/low data output mode. This is ideal for high volume performance tests. a timeout for a replay. Ignored when replay mode is responder-only

The operator will remove all listed replay annotations from the workload during admission review and move them into an associated TrafficReplay Custom Resource. This prevents side effects such as the operator observing and executing the same replay after it has finished. It also allows subsequent runs of the same replay by applying the same manifests, or incorporating the annotations into a GitOps workflow.


For version 2 of the operator, be sure to check the table of changes for updated annotations. Unless otherwise noted, these annotations can be applied prior to installing version 2 without interference.

Tag Annotation

Here a simple example from Gitlab where we use sed to insert the build tag into the yaml before deploying to the Kubernetes test cluster:

stage: deploy
- sed s/CIBuild/$(echo $CI_COMMIT_TAG)/g ./k8s/moto-api.yaml > ./k8s/moto-api-corrected.yaml
- kubectl -n mototest1 apply -f ./k8s/moto-api-corrected.yaml

Secret configuration

If your application uses short lived JWTs, you need to provide a JWT secret that Speedscale can use to resign tokens. For example, if your service receives HTTP calls that contain a JWT authorization with 10 minute expiration (exp) setting, that JWT will be invalid by the time it is used for replay. To solve this, add the following annotations (insert your own secret names): "jwtsecret,jwtsecret2,jwtsecret3"

This will cause the Kubernetes operator to add each secret (comma separated) to the generator. Note that you need to include the secret filename to the tokenizer configuration (ask Speedscale how to do this, it isn't in the docs yet). The filename for each secret in the tokenizer will be in the format


Environment Cleanup

The operator can be configured to automatically delete:

  • The Speedscale created components (generator, responder, etc.)
  • The System Under Test (i.e. your deployment)

You can stop this behavior to retain logs, etc by adding the following annotation to your deployment: "none"