Simply use a few annotations to replay your traffic snapshot using the Kubernetes operator.
Once you have created a snapshot report, you can replay it at any time in your own environment.
When you replay these are the key ingredients that you will use:
|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 |
|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.|
|TrafficReplay||A Kubernetes Custom Resource that tracks the state of a running replay.|
|(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:
replay.speedscale.com/snapshot-id: <snapshot ID>
replay.speedscale.com/testconfig-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.
When running a snapshot, the default behavior is to deploy both a Responder and a Generator. This is represented by the following annotation:
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.
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.
- 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:
- name: moto-api
- containerPort: 8079
- name: DEBUG