This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Power Outage Scenarios

This scenario shuts down Kubernetes/OpenShift cluster for the specified duration to simulate power outages, brings it back online and checks if it’s healthy.

How to Run Power Outage Scenarios

Choose your preferred method to run power outage scenarios:

Power Outage/ Cluster shut down scenario can be injected by placing the shut_down config file under cluster_shut_down_scenario option in the kraken config. Refer to cluster_shut_down_scenario config file.

Example scenario file: cluster_shut_down_scenario.yml

Refer to cloud setup to configure your cli properly for the cloud provider of the cluster you want to shut down.

Current accepted cloud types:

cluster_shut_down_scenario:                          # Scenario to stop all the nodes for specified duration and restart the nodes.
  runs: 1                                            # Number of times to execute the cluster_shut_down scenario.
  shut_down_duration: 120                            # Duration in seconds to shut down the cluster.
  cloud_type: aws                                    # Cloud type on which Kubernetes/OpenShift runs.

How to Use Plugin Name

Add the plugin name to the list of chaos_scenarios section in the config/config.yaml file

kraken:
    kubeconfig_path: ~/.kube/config                     # Path to kubeconfig
    ..
    chaos_scenarios:
        - cluster_shut_down_scenarios:
            - scenarios/<scenario_name>.yaml

Note

You can specify multiple scenario files of the same type by adding additional paths to the list:

kraken:
    chaos_scenarios:
        - cluster_shut_down_scenarios:
            - scenarios/power-outage-1.yaml
            - scenarios/power-outage-2.yaml
            - scenarios/power-outage-3.yaml

You can also combine multiple different scenario types in the same config.yaml file. Scenario types can be specified in any order, and you can include the same scenario type multiple times:

kraken:
    chaos_scenarios:
        - cluster_shut_down_scenarios:
            - scenarios/power-outage.yaml
        - pod_disruption_scenarios:
            - scenarios/pod-kill.yaml
        - node_scenarios:
            - scenarios/node-reboot.yaml
        - cluster_shut_down_scenarios:  # Same type can appear multiple times
            - scenarios/power-outage-2.yaml

Run

python run_kraken.py --config config/config.yaml

This scenario shuts down Kubernetes/OpenShift cluster for the specified duration to simulate power outages, brings it back online and checks if it’s healthy. More information can be found here

Right now power outage and cluster shutdown are one in the same. We originally created this scenario to stop all the nodes and then start them back up how a customer would shut their cluster down.

In a real life chaos scenario though, we figured this scenario was close to if the power went out on the aws side so all of our ec2 nodes would be stopped/powered off. We tried to look at if aws cli had a way to forcefully poweroff the nodes (not gracefully) and they don’t currently support so this scenario is as close as we can get to “pulling the plug”

Run

If enabling Cerberus to monitor the cluster and pass/fail the scenario post chaos, refer docs. Make sure to start it before injecting the chaos and set CERBERUS_ENABLED environment variable for the chaos injection container to autoconnect.

$ podman run \
  --name=<container_name> \
  --net=host \
  --pull=always \
  --env-host=true \
  -v <path-to-kube-config>:/home/krkn/.kube/config:Z \
  -d containers.krkn-chaos.dev/krkn-chaos/krkn-hub:power-outages
$ podman logs -f <container_name or container_id> # Streams Kraken logs
$ podman inspect <container-name or container-id> \
  --format "{{.State.ExitCode}}" # Outputs exit code which can considered as pass/fail for the scenario

Note

–env-host: This option is not available with the remote Podman client, including Mac and Windows (excluding WSL2) machines. Without the –env-host option you’ll have to set each environment variable on the podman command line like -e <VARIABLE>=<value>

$ docker run $(./get_docker_params.sh) \
  --name=<container_name> \
  --net=host \
  --pull=always \
  -v <path-to-kube-config>:/home/krkn/.kube/config:Z \
  -d containers.krkn-chaos.dev/krkn-chaos/krkn-hub:power-outages
$ docker run \
  -e <VARIABLE>=<value> \
  --name=<container_name> \
  --net=host \
  --pull=always \
  -v <path-to-kube-config>:/home/krkn/.kube/config:Z \
  -d containers.krkn-chaos.dev/krkn-chaos/krkn-hub:power-outages

$ docker logs -f <container_name or container_id> # Streams Kraken logs
$ docker inspect <container-name or container-id> \
  --format "{{.State.ExitCode}}" # Outputs exit code which can considered as pass/fail for the scenario

Tip

Because the container runs with a non-root user, ensure the kube config is globally readable before mounting it in the container. You can achieve this with the following commands:

kubectl config view --flatten > ~/kubeconfig && chmod 444 ~/kubeconfig && docker run $(./get_docker_params.sh) --name=<container_name> --net=host --pull=always -v ~/kubeconfig:/home/krkn/.kube/config:Z -d containers.krkn-chaos.dev/krkn-chaos/krkn-hub:<scenario>

Supported parameters

The following environment variables can be set on the host running the container to tweak the scenario/faults being injected:

example: export <parameter_name>=<value>

See list of variables that apply to all scenarios here that can be used/set in addition to these scenario specific variables

Parameter	Description	Type	Default
SHUTDOWN_DURATION	Duration in seconds to shut down the cluster	number	1200
CLOUD_TYPE	Cloud platform on top of which cluster is running, supported cloud platforms	enum	aws
TIMEOUT	Time in seconds to wait for each node to be stopped or running after the cluster comes back	number	180
SCENARIO_TYPE	Plugin key krkn dispatches the scenario on. Fixed by the container image, not a knob to change.	-	cluster_shut_down_scenarios
SCENARIO_FILE	Path to the scenario file baked into the container image. Fixed by the image, not a knob to change.	-	scenarios/cluster_shut_down_scenario.yml

The following environment variables need to be set for the scenarios that requires interacting with the cloud platform API to perform the actions:

Amazon Web Services

$ export AWS_ACCESS_KEY_ID=<>
$ export AWS_SECRET_ACCESS_KEY=<>
$ export AWS_DEFAULT_REGION=<>

Google Cloud Platform

TBD

Azure

TBD

OpenStack

TBD

Baremetal

TBD

Note

In case of using custom metrics profile or alerts profile when CAPTURE_METRICS or ENABLE_ALERTS is enabled, mount the metrics profile from the host on which the container is run using podman/docker under /home/krkn/kraken/config/metrics-aggregated.yaml and /home/krkn/kraken/config/alerts.

For example:

$ podman run \
  --name=<container_name> \
  --net=host \
  --pull=always \
  --env-host=true \
  -v <path-to-custom-metrics-profile>:/home/krkn/kraken/config/metrics-aggregated.yaml \
  -v <path-to-custom-alerts-profile>:/home/krkn/kraken/config/alerts \
  -v <path-to-kube-config>:/home/krkn/.kube/config:Z \
  -d containers.krkn-chaos.dev/krkn-chaos/krkn-hub:power-outages

krknctl run power-outages [--<parameter> <value>]

Can also set any global variable listed here

Scenario specific parameters:

Parameter	Description	Type	Default	Possible Values
--shutdown-duration	Duration in seconds to shut down the cluster	number	1200
--cloud-type	Cloud platform on top of which cluster is running, supported platforms - aws, azure, gcp, vmware, ibmcloud, bm	enum	aws	aws/azure/gcp/vmware/ibmcloud/bm
--timeout	Time in seconds to wait for each node to be stopped or running after the cluster comes back	number	600
--vsphere-ip	vSphere IP address	string	`""`
--vsphere-username	vSphere username	string (secret)	`""`
--vsphere-password	vSphere password	string (secret)	`""`
--aws-access-key-id	AWS Access Key Id	string (secret)	`""`
--aws-secret-access-key	AWS Secret Access Key	string (secret)	`""`
--aws-default-region	AWS default region	string (secret)	`""`
--bmc-user	Only needed for Baremetal ( bm ) - IPMI/bmc username	string (secret)	`""`
--bmc-password	Only needed for Baremetal ( bm ) - IPMI/bmc password	string (secret)	`""`
--bmc-address	Only needed for Baremetal ( bm ) - IPMI/bmc address	string	`""`
--ibmc-address	IBM Cloud URL	string	`""`
--ibmc-api-key	IBM Cloud API Key	string (secret)	`""`
--azure-tenant	Azure Tenant	string (secret)	`""`
--azure-client-secret	Azure Client Secret	string (secret)	`""`
--azure-client-id	Azure Client ID	string (secret)	`""`
--azure-subscription-id	Azure Subscription ID	string	`""`
--gcp-application-credentials	GCP application credentials file location	file	-

NOTE: The secret string types will be masked when scenario is ran

To see all available scenario options

krknctl run power-outages --help

Demo

See a demo of this scenario: