Chaos Workflow
Chaos Workflow is a set of different operations coupled together to achieve desired chaos impact on a Kubernetes Cluster.
It is useful in automating a series of pre-conditioning steps or action which is necessary to be performed before triggering the chaos injection.
A Chaos Workflow can also be used to perform different operations parallelly to achieve a desired chaos injection scenario.
Prerequisites#
The following should be required before creating a Chaos Workflow:
How do we define and execute a workflow?#
LitmusChaos leverages the popular workflow and GitOps tool Argo to achieve this goal. Argo enables the creation of different chaos scenarios together in from of workflows which are extremly simple and efficient to use.
With the help of ChaosCenter, workflows with different type of experiments can be created. In a Chaos Workflow, the experiments can be added in a parallel way and the user can tune the workflow by adding additional steps to simulate a desired fault that might occur in production stage.
Life Cycle of a Chaos Workflow#
Here is a sample pod-delete chaos workflow from ChaosCenter.
apiVersion: argoproj.io/v1alpha1kind: Workflowmetadata: name: custom-chaos-workflow-1627980541 namespace: litmus labels: subject: custom-chaos-workflow_litmusspec: arguments: parameters: - name: adminModeNamespace value: litmus entrypoint: custom-chaos securityContext: runAsNonRoot: true runAsUser: 1000 serviceAccountName: argo-chaos templates: - name: custom-chaos steps: - - name: install-chaos-experiments template: install-chaos-experiments - - name: pod-delete template: pod-delete - - name: revert-chaos template: revert-chaos - name: install-chaos-experiments inputs: artifacts: - name: pod-delete path: /tmp/pod-delete.yaml raw: data: > apiVersion: litmuschaos.io/v1alpha1
description: message: | Deletes a pod belonging to a deployment/statefulset/daemonset kind: ChaosExperiment
metadata: name: pod-delete labels: name: pod-delete app.kubernetes.io/part-of: litmus app.kubernetes.io/component: chaosexperiment app.kubernetes.io/version: 1.13.8 spec: definition: scope: Namespaced permissions: - apiGroups: - "" - apps - apps.openshift.io - argoproj.io - batch - litmuschaos.io resources: - deployments - jobs - pods - pods/log - replicationcontrollers - deployments - statefulsets - daemonsets - replicasets - deploymentconfigs - rollouts - pods/exec - events - chaosengines - chaosexperiments - chaosresults verbs: - create - list - get - patch - update - delete - deletecollection image: litmuschaos/go-runner:1.13.8 imagePullPolicy: Always args: - -c - ./experiments -name pod-delete command: - /bin/bash env: - name: TOTAL_CHAOS_DURATION value: "15" - name: RAMP_TIME value: "" - name: FORCE value: "true" - name: CHAOS_INTERVAL value: "5" - name: PODS_AFFECTED_PERC value: "" - name: LIB value: litmus - name: TARGET_PODS value: "" - name: SEQUENCE value: parallel labels: name: pod-delete app.kubernetes.io/part-of: litmus app.kubernetes.io/component: experiment-job app.kubernetes.io/version: 1.13.8 container: args: - kubectl apply -f /tmp/pod-delete.yaml -n {{workflow.parameters.adminModeNamespace}} | sleep 30 command: - sh - -c image: litmuschaos/k8s:latest - name: pod-delete inputs: artifacts: - name: pod-delete path: /tmp/chaosengine-pod-delete.yaml raw: data: | apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: namespace: "{{workflow.parameters.adminModeNamespace}}" generateName: pod-delete labels: instance_id: 86a4f130-d99b-4e91-b34b-8f9eee22cb63 spec: appinfo: appns: default applabel: app=nginx appkind: deployment jobCleanUpPolicy: retain engineState: active chaosServiceAccount: litmus-admin experiments: - name: pod-delete spec: components: env: - name: TOTAL_CHAOS_DURATION value: "30" - name: CHAOS_INTERVAL value: "10" - name: FORCE value: "false" - name: PODS_AFFECTED_PERC value: "" container: args: - -file=/tmp/chaosengine-pod-delete.yaml - -saveName=/tmp/engine-name image: litmuschaos/litmus-checker:latest - name: revert-chaos container: image: litmuschaos/k8s:latest command: - sh - -c args: - "kubectl delete chaosengine -l 'instance_id in (86a4f130-d99b-4e91-b34b-8f9eee22cb63, )' -n {{workflow.parameters.adminModeNamespace}} " podGC: strategy: OnWorkflowCompletionThe structure of a chaos workflow is similar to that of a Kubernetes Object. It consists of the mandatory fields like apiVersion, kind, metadata, spec.
The spec in a Chaos Workflow is where the different steps are mentioned and the overall life cycle of the workflow is described.
We can see different templates are present in the spec of a chaos workflow.
templates: - name: custom-chaos steps: - - name: install-chaos-experiments template: install-chaos-experiments - - name: pod-delete template: pod-delete - - name: revert-chaos template: revert-chaosHere in this template, we can see different steps are present. These include installing the chaos experiments, executing the chaos engine of the experiment and at the end we have the revert chaos step which deletes/removes the resources that were created as part of the workflow.
Some additional checks can be added with the experiments in the form of probes. These probes are defined in the ChaosEngines of the experiment and are updated when the experiment execution takes place.
The overall workflow result can be viewed with the ChaosResult CRD which contains the verdict and the probeSuccessPercentage (a ratio of successful checks v/s total probes).
What is a run?#
A workflow run can be defined as single/one-time execution of the workflow. There can be multiple runs of a single workflow. If the workflow consists of a cron syntax, it will run periodically according to the cron provided in the workflow.
What is Resiliency Score?#
Resiliency score is the measure of how resilient is the workflow when different chaos scenarios are performed on the Kubernetes System.
While creating a workflow, certain weights are assigned to all the experiments present in the workflow. These weights signify the priority/importance of the experiment. The higher the weight, the more significant is the experiment.
In ChaosCenter, the weight priority is generally divided into three sections:
- 0-3: Low Priority
- 4-6: Medium Priority
- 7-10: High Priority
Once a weight has been assigned to the experiment, we look for the Probe Success Percentage for that experiment itself (Post Chaos) and calculate the total resilience result for that experiment as a multiplication of the weight given and the probe success percentage returned after the Chaos Run.
Total Resilience for one single experiment = (Weight Given to that experiment * Probe Success Percentage)Overall Resilience Score = Total Test Result / Sum of the assigned weights of the experimentsWhat is a Cron Workflow?#
Cron Workflow is a type of workflow that runs on a pre-defined schedule. It consists of a mandatory field spec.schedule. A cron syntax is provided in this field at which the workflow execution takes
place.
Here's a sample CronWorkflow for Podtato-Head application:
apiVersion: argoproj.io/v1alpha1kind: CronWorkflowmetadata: name: podtato-head-1628058291 namespace: litmus labels: subject: podtato-head_litmusspec: schedule: 10 0-23 * * * concurrencyPolicy: Forbid startingDeadlineSeconds: 0 workflowSpec: entrypoint: argowf-chaos serviceAccountName: argo-chaos securityContext: runAsUser: 1000 runAsNonRoot: true arguments: parameters: - name: adminModeNamespace value: litmus templates: - name: argowf-chaos steps: - - name: install-application template: install-application - - name: install-chaos-experiments template: install-chaos-experiments - - name: pod-delete template: pod-delete - - name: revert-chaos template: revert-chaos - name: delete-application template: delete-application - name: install-application container: image: litmuschaos/litmus-app-deployer:latest args: - -namespace={{workflow.parameters.adminModeNamespace}} - -typeName=resilient - -operation=apply - -timeout=400 - -app=podtato-head - -scope=namespace - name: install-chaos-experiments container: image: litmuschaos/k8s:latest command: - sh - -c args: - kubectl apply -f https://hub.litmuschaos.io/api/chaos/1.13.7?file=charts/generic/experiments.yaml -n {{workflow.parameters.adminModeNamespace}} ; sleep 30 - name: pod-delete inputs: artifacts: - name: pod-delete path: /tmp/chaosengine.yaml raw: data: > apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata: namespace: "{{workflow.parameters.adminModeNamespace}}" labels: instance_id: 1b7ec920-75f9-4398-b4c3-9c3a5d7fd5c2 generateName: podtato-main-pod-delete-chaos spec: appinfo: appns: "{{workflow.parameters.adminModeNamespace}}" applabel: name=podtato-main appkind: deployment engineState: active chaosServiceAccount: litmus-admin jobCleanUpPolicy: retain components: runner: imagePullPolicy: Always experiments: - name: pod-delete spec: probe: - name: check-podtato-main-access-url type: httpProbe httpProbe/inputs: url: http://podtato-main.{{workflow.parameters.adminModeNamespace}}.svc.cluster.local:9000 insecureSkipVerify: false method: get: criteria: == responseCode: "200" mode: Continuous runProperties: probeTimeout: 1 interval: 1 retry: 1 components: env: - name: TOTAL_CHAOS_DURATION value: "30" - name: CHAOS_INTERVAL value: "10" - name: FORCE value: "false" container: image: litmuschaos/litmus-checker:latest args: - -file=/tmp/chaosengine.yaml - -saveName=/tmp/engine-name - name: delete-application container: image: litmuschaos/litmus-app-deployer:latest args: - -namespace={{workflow.parameters.adminModeNamespace}} - -typeName=resilient - -operation=delete - -app=podtato-head - name: revert-chaos container: image: litmuschaos/k8s:latest command: - sh - -c args: - "kubectl delete chaosengine -l 'instance_id in (1b7ec920-75f9-4398-b4c3-9c3a5d7fd5c2, )' -n {{workflow.parameters.adminModeNamespace}} " timezone: Asia/CalcuttaIn the above workflow, we can see the cron syntax at spec.schedule is
spec: schedule: 10 0-23 * * *This means the workflow will be executed at the 10th minute of every hour.
A workflow can be changed into CronWorkflow from the ChaosCenter.
While scheduling a workflow, in the Schedule step, there are few options as part of Recurring Schedules. These include:
- Every hour
- Every Day
- Every Week
- Every Month
Summary#
Chaos Workflow is combination of different steps combined together to perfrom a specific chaos use-case on a Kubernetes system. These steps can include install experiment steps, ChaosEngine CR for target selection, revert-chaos steps etc. Chaos Workflows can be scheduled for a later time with the help of Cron Workflows. These workflows consist of a cron syntax that is used for scheduling a workflow. Once the workflow execution is completed, the resiliency of the targeted application is calculated. Several weights are assigned to different experiments in the workflow. These weights are used along with the ProbeSuccessPercentage to find out the resiliency score.