Start Replay (Kubernetes)
Simply use a few annotations to replay your traffic snapshot using the Kubernetes operator.

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:
Ingredient
Description
Snapshot
A recording of inbound and outbound traffic. You should have created this in the Create Snapshot step.
Configuration
Use 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.
Generator
This is a job that will be replay the traffic into the Service Under Test.
Forwarder
This container forwards test results to the Speedscale datastore.
(optional) Responder
This is an optional container that can simulate the downstream dependencies behind the SUT.
(optional) Collector
This is an optional container that will collect logs and other telemetry from the SUT. This container only works in Kubernetes environments.
(optional) Operator
This 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:
1
test.speedscale.com/scenarioid: <scenarioID>
2
test.speedscale.com/testconfigid: <test config ID>
Copied!

Deployment Modes

When deploying a snapshot, the default behavior is to deploy the Speedscale traffic generator, but not the responder. This will mean that all external requests and services will still be accessible as they normally would be during traffic record time. In order to enable the Speedscale responder for external service mocking, the following annotation may be added:
1
test.speedscale.com/deployResponder: "true"
Copied!
Some instances may not require the use of the Speedscale traffic generator, which is different the default deployment behavior where the traffic generator is deployed automatically. To disable deploying the generator, use the following annotation:
1
test.speedscale.com/deployGenerator: "false"
Copied!
There are additional options that can be toggled depending on your specific needs for snapshot replay.

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:
1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
name: moto-api
5
annotations:
6
test.speedscale.com/scenarioid: "a08532d90041-4e0f-bc69-d88103aef564"
7
test.speedscale.com/testconfigid: "standard"
8
labels:
9
app: moto-api
10
spec:
11
replicas: 1
12
selector:
13
matchLabels:
14
app: moto-api
15
template:
16
metadata:
17
labels:
18
app: moto-api
19
spec:
20
containers:
21
- name: moto-api
22
image: gcr.io/speedscale-demos/moto-api:latest
23
imagePullPolicy: Always
24
ports:
25
- containerPort: 8079
26
env:
27
- name: DEBUG
28
value: express-session
29
securityContext:
30
runAsNonRoot: true
31
runAsUser: 10001
32
capabilities:
33
drop:
34
- all
35
readOnlyRootFilesystem: true
36
nodeSelector:
37
beta.kubernetes.io/os: linux
Copied!
Last modified 24d ago