- Basic structure
- Note on self-destruction
Policies describe the chaos experiments for powerfulseal to execute in autonomous mode. The syntax is formally defined here. If you want to browse the available options, see below:
A policy file is a yaml file. The most basic policy you can write is the following:
It will validate, but will not do anything interesting.
If you’d like to see all possible options in an example config, you this policy. We use it to test that it validates to detect any regressions when new features are added.
Every scenario has a name and an array of steps to do. For example:
scenarios: - name: Example scenario description: > A longer description of the scenario. Can have multiple lines etc. steps: 
The steps will be executed in the order specified.
You can also tweak certain parameters directly from the policy file.
For example, by default the seal will continuosly run your scenario and only stop on errors.
If you’d like to run an experiment as part of your CI pipeline, you might want to run it a single time and then exit. The return code will tell you whether the experiment succeeded or not.
config: runStrategy: runs: 1 scenarios: 
By default, the seal runs the scenarios in the order specified (
round-robin). You can change that to run them in a random order:
config: runStrategy: strategy: random scenarios: 
By default, if a scenario fails, the seal will report the error so that you can alert on it, and keep going.
If you’d like it to exit (for example if you’re running it as a job), you can use the
fail-fast exit strategy:
config: exitStrategy: strategy: fail-fast scenarios: 
To see examples of policies, use the menu on the left.
With great power comes great responsibility, and sometimes it’s easy to take down the wrong pod or node and kill the Seal by accident.
That’s not ideal, because it might result in nodes staying down, or incomplete experiments.
To avoid that, PowerfulSeal honors two variables, that it will filter out from killing:
env: # in order to allow PowerfulSeal to not accidentally self-destruct # give it the pod name - name: POD_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.name # and the host ip - name: HOST_IP valueFrom: fieldRef: apiVersion: v1 fieldPath: status.hostIP
Any pods with this name, and any hosts with that IP will be spared.
Table of contents
- New pod startup SLO
- Pods reschedule SLO
- Taking VMs down
- Deployment redundancy
- Verify pod status
- Mixing nodes and pods
- Different proxies for probes
- Stop a host running particular pod
- Clone deployment and add slowness with tc
- Clone deployment and add network failure with toxiproxy