Skip to main content

Start Replay (Kubernetes)

For those who cannot start a replay from the dashboard, Kubernetes resource annotations may be modified directly to achieve the same result.

The Speedscale Kubernetes Operator must be installed.

Key Ingredients

Once you have created a snapshot report, you can replay it at any time in your own environment.

Test environment with all components deployed

When you replay these are the key ingredients that you will use:

SnapshotA recording of inbound and outbound traffic. You should have created this in the Create Snapshot step.
ConfigurationUse this to customize how traffic will be replayed. There are some built-in configurations, the standard one should replay the same way it was captured.
Service Under Test (SUT)This is your application that you want to test, it should be described in a manifest already, such as a deployment yaml.
GeneratorThis is a job that will be replay the traffic into the Service Under Test.
ForwarderThis container forwards test results to the Speedscale datastore.
TrafficReplayA Kubernetes Custom Resource that tracks the state of a running replay.
(optional) ResponderThis is an optional container that can simulate the downstream dependencies behind the SUT.
(optional) CollectorThis is an optional container that will collect logs and other telemetry from the SUT. This container only works in Kubernetes environments.
(optional) OperatorThis is an optional container that will orchestrate your replay in a Kubernetes environment. You can also manually deploy components without the Operator.

For the rest of these instructions it is assumed that the operator and forwarder are deployed per the installation instructions.


Readiness Probe: Your deployment should have a readiness probe configured in Kubernetes, this lets the operator know exactly when the pod is ready to receive traffic.

Starting a Replay

Add these annotations to your deployment (or job or stateful set or daemon set) to tell the operator to take action: <snapshot ID> <test config ID>

If this is the first time you are running a replay, you should start with the standard test config ID. Running this test config usually works. If it doesn't the report will give you an idea of how to configuration the data transformation. For more information about test configs see the docs.

Deployment Modes

When running a snapshot, the default behavior is to deploy both a Responder and a Generator. This is represented by the following annotation: full-replay

In this mode, traffic will be generated that matches traffic observed in your capture. Additionally, the Responder will reply for calls to external services.

You may only want a Generator or a Responder for a given test. In that case, you may deploy one or the other with the following annotations on your workload. responder-only generator-only

There are additional options that can be toggled depending on your specific needs for snapshot replay. See the full list of Replay annotations for options.

Extra info

  • The operator currently only watches for deployments, stateful sets, jobs and daemon sets
  • The operator technically will watch for updates as well as new deployments, but you need to make sure the rest of the test environment is prepared

Example deployment yaml

Here is a full example of a test deployment yaml for reference:

apiVersion: apps/v1
kind: Deployment
name: moto-api
annotations: "a08532d90041-4e0f-bc69-d88103aef564" "standard"
app: moto-api
replicas: 1
app: moto-api
app: moto-api
- name: moto-api
imagePullPolicy: Always
- containerPort: 8079
- name: DEBUG
value: express-session
runAsNonRoot: true
runAsUser: 10001
- all
readOnlyRootFilesystem: true
nodeSelector: linux