From 6e94df9cfca1d751b6615f8e503617bb7392247d Mon Sep 17 00:00:00 2001 From: Paige Patton Date: Thu, 22 May 2025 13:25:33 -0400 Subject: [PATCH] removing all docs Signed-off-by: Paige Patton --- docs/SLOs_validation.md | 48 ----- docs/_config.yml | 1 - docs/application_outages.md | 17 -- docs/cloud_setup.md | 102 --------- docs/cluster_shut_down_scenarios.md | 19 -- docs/config.md | 61 ------ docs/container_scenarios.md | 40 ---- docs/contribute.md | 95 -------- docs/getting_started.md | 51 ----- docs/health_checks.md | 59 ----- docs/hog_scenarios.md | 51 ----- docs/index.md | 311 --------------------------- docs/installation.md | 45 ---- docs/managedcluster_scenarios.md | 36 ---- docs/network_chaos.md | 49 ----- docs/node_scenarios.md | 116 ---------- docs/performance_dashboards.md | 12 -- docs/pod_network_scenarios.md | 46 ---- docs/pod_scenarios.md | 37 ---- docs/pvc_scenario.md | 26 --- docs/scenario_plugin_api.md | 136 ------------ docs/scenario_plugin_pycharm.gif | Bin 348390 -> 0 bytes docs/service_disruption_scenarios.md | 66 ------ docs/service_hijacking_scenarios.md | 80 ------- docs/signal.md | 71 ------ docs/syn_flood_scenarios.md | 33 --- docs/test_your_changes.md | 44 ---- docs/time_scenarios.md | 33 --- docs/zone_outage.md | 28 --- 29 files changed, 1713 deletions(-) delete mode 100644 docs/SLOs_validation.md delete mode 100644 docs/_config.yml delete mode 100644 docs/application_outages.md delete mode 100644 docs/cloud_setup.md delete mode 100644 docs/cluster_shut_down_scenarios.md delete mode 100644 docs/config.md delete mode 100644 docs/container_scenarios.md delete mode 100644 docs/contribute.md delete mode 100644 docs/getting_started.md delete mode 100644 docs/health_checks.md delete mode 100644 docs/hog_scenarios.md delete mode 100644 docs/index.md delete mode 100644 docs/installation.md delete mode 100644 docs/managedcluster_scenarios.md delete mode 100644 docs/network_chaos.md delete mode 100644 docs/node_scenarios.md delete mode 100644 docs/performance_dashboards.md delete mode 100644 docs/pod_network_scenarios.md delete mode 100644 docs/pod_scenarios.md delete mode 100644 docs/pvc_scenario.md delete mode 100644 docs/scenario_plugin_api.md delete mode 100644 docs/scenario_plugin_pycharm.gif delete mode 100644 docs/service_disruption_scenarios.md delete mode 100644 docs/service_hijacking_scenarios.md delete mode 100644 docs/signal.md delete mode 100644 docs/syn_flood_scenarios.md delete mode 100644 docs/test_your_changes.md delete mode 100644 docs/time_scenarios.md delete mode 100644 docs/zone_outage.md diff --git a/docs/SLOs_validation.md b/docs/SLOs_validation.md deleted file mode 100644 index dbe9f8d7..00000000 --- a/docs/SLOs_validation.md +++ /dev/null @@ -1,48 +0,0 @@ -## SLOs validation - -Pass/fail based on metrics captured from the cluster is important in addition to checking the health status and recovery. Kraken supports: - -### Checking for critical alerts post chaos -If enabled, the check runs at the end of each scenario ( post chaos ) and Kraken exits in case critical alerts are firing to allow user to debug. You can enable it in the config: - -``` -performance_monitoring: - check_critical_alerts: False # When enabled will check prometheus for critical alerts firing post chaos -``` - -### Validation and alerting based on the queries defined by the user during chaos -Takes PromQL queries as input and modifies the return code of the run to determine pass/fail. It's especially useful in case of automated runs in CI where user won't be able to monitor the system. This feature can be enabled in the [config](https://github.com/redhat-chaos/krkn/blob/main/config/config.yaml) by setting the following: - -``` -performance_monitoring: - prometheus_url: # The prometheus url/route is automatically obtained in case of OpenShift, please set it when the distribution is Kubernetes. - prometheus_bearer_token: # The bearer token is automatically obtained in case of OpenShift, please set it when the distribution is Kubernetes. This is needed to authenticate with prometheus. - enable_alerts: True # Runs the queries specified in the alert profile and displays the info or exits 1 when severity=error. - alert_profile: config/alerts.yaml # Path to alert profile with the prometheus queries. -``` - -#### Alert profile -A couple of [alert profiles](https://github.com/redhat-chaos/krkn/tree/main/config) [alerts](https://github.com/redhat-chaos/krkn/blob/main/config/alerts.yaml) are shipped by default and can be tweaked to add more queries to alert on. User can provide a URL or path to the file in the [config](https://github.com/redhat-chaos/krkn/blob/main/config/config.yaml). The following are a few alerts examples: - -``` -- expr: avg_over_time(histogram_quantile(0.99, rate(etcd_disk_wal_fsync_duration_seconds_bucket[2m]))[5m:]) > 0.01 - description: 5 minutes avg. etcd fsync latency on {{$labels.pod}} higher than 10ms {{$value}} - severity: error - -- expr: avg_over_time(histogram_quantile(0.99, rate(etcd_network_peer_round_trip_time_seconds_bucket[5m]))[5m:]) > 0.1 - description: 5 minutes avg. etcd network peer round trip on {{$labels.pod}} higher than 100ms {{$value}} - severity: info - -- expr: increase(etcd_server_leader_changes_seen_total[2m]) > 0 - description: etcd leader changes observed - severity: critical -``` - -Krkn supports setting the severity for the alerts with each one having different effects: - -``` -info: Prints an info message with the alarm description to stdout. By default all expressions have this severity. -warning: Prints a warning message with the alarm description to stdout. -error: Prints a error message with the alarm description to stdout and sets Krkn rc = 1 -critical: Prints a fatal message with the alarm description to stdout and exits execution inmediatly with rc != 0 -``` diff --git a/docs/_config.yml b/docs/_config.yml deleted file mode 100644 index 277f1f2c..00000000 --- a/docs/_config.yml +++ /dev/null @@ -1 +0,0 @@ -theme: jekyll-theme-cayman diff --git a/docs/application_outages.md b/docs/application_outages.md deleted file mode 100644 index 7a56c6da..00000000 --- a/docs/application_outages.md +++ /dev/null @@ -1,17 +0,0 @@ -### Application outages -Scenario to block the traffic ( Ingress/Egress ) of an application matching the labels for the specified duration of time to understand the behavior of the service/other services which depend on it during downtime. This helps with planning the requirements accordingly, be it improving the timeouts or tweaking the alerts etc. - -##### Sample scenario config -``` -application_outage: # Scenario to create an outage of an application by blocking traffic - duration: 600 # Duration in seconds after which the routes will be accessible - namespace: # Namespace to target - all application routes will go inaccessible if pod selector is empty - pod_selector: {app: foo} # Pods to target - block: [Ingress, Egress] # It can be Ingress or Egress or Ingress, Egress -``` - -##### Debugging steps in case of failures -Kraken creates a network policy blocking the ingress/egress traffic to create an outage, in case of failures before reverting back the network policy, you can delete it manually by executing the following commands to stop the outage: -``` -$ oc delete networkpolicy/kraken-deny -n -``` diff --git a/docs/cloud_setup.md b/docs/cloud_setup.md deleted file mode 100644 index a1b4f858..00000000 --- a/docs/cloud_setup.md +++ /dev/null @@ -1,102 +0,0 @@ -Supported Cloud Providers: - -- [AWS](#aws) -- [GCP](#gcp) -- [Openstack](#openstack) -- [Azure](#azure) -- [Alibaba](#alibaba) -- [VMware](#vmware) -- [IBMCloud](#ibmcloud) - -## AWS - -**NOTE**: For clusters with AWS make sure [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) is installed and properly [configured](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html) using an AWS account - -## GCP - -In order to set up Application Default Credentials (ADC) for use by Cloud Client Libraries, you can provide either service account credentials or the credentials associated with your user acccount: - -- Using service account credentials: - - A google service account is required to give proper authentication to GCP for node actions. See [here](https://cloud.google.com/docs/authentication/getting-started) for how to create a service account. - - **NOTE**: A user with 'resourcemanager.projects.setIamPolicy' permission is required to grant project-level permissions to the service account. - - After creating the service account you will need to enable the account using the following: ```export GOOGLE_APPLICATION_CREDENTIALS=""``` - -- Using the credentials associated with your user acccount: - - 1. Make sure that the [GCP CLI](https://cloud.google.com/sdk/docs/install#linux) is installed and [initialized](https://cloud.google.com/sdk/docs/initializing) by running: - - ```gcloud init``` - - 2. Create local authentication credentials for your user account: - - ```gcloud auth application-default login``` - -## Openstack - -**NOTE**: For clusters with Openstack Cloud, ensure to create and source the [OPENSTACK RC file](https://docs.openstack.org/newton/user-guide/common/cli-set-environment-variables-using-openstack-rc.html) to set the OPENSTACK environment variables from the server where Kraken runs. - -## Azure - -**NOTE**: You will need to create a service principal and give it the correct access, see [here](https://docs.openshift.com/container-platform/4.5/installing/installing_azure/installing-azure-account.html) for creating the service principal and setting the proper permissions. - -To properly run the service principal requires “Azure Active Directory Graph/Application.ReadWrite.OwnedBy” api permission granted and “User Access Administrator”. - -Before running you will need to set the following: - -1. ```export AZURE_SUBSCRIPTION_ID=``` - -2. ```export AZURE_TENANT_ID=``` - -3. ```export AZURE_CLIENT_SECRET=``` - -4. ```export AZURE_CLIENT_ID=``` - -## Alibaba - -See the [Installation guide](https://www.alibabacloud.com/help/en/alibaba-cloud-cli/latest/installation-guide) to install alicloud cli. - -1. ```export ALIBABA_ID=``` - -2. ```export ALIBABA_SECRET=``` - -3. ```export ALIBABA_REGION_ID=``` - -Refer to [region and zone page](https://www.alibabacloud.com/help/en/elastic-compute-service/latest/regions-and-zones#concept-2459516) to get the region id for the region you are running on. - -Set cloud_type to either alibaba or alicloud in your node scenario yaml file. - -## VMware - -Set the following environment variables - -1. ```export VSPHERE_IP=``` - -2. ```export VSPHERE_USERNAME=``` - -3. ```export VSPHERE_PASSWORD=``` - -These are the credentials that you would normally use to access the vSphere client. - -## IBMCloud - -If no API key is set up with proper VPC resource permissions, use the following to create it: - -* Access group -* Service id with the following access - * With policy **VPC Infrastructure Services** - * Resources = All - * Roles: - * Editor - * Administrator - * Operator - * Viewer -* API Key - -Set the following environment variables - -1. ```export IBMC_URL=https://.iaas.cloud.ibm.com/v1``` - -2. ```export IBMC_APIKEY=``` diff --git a/docs/cluster_shut_down_scenarios.md b/docs/cluster_shut_down_scenarios.md deleted file mode 100644 index 1baed38e..00000000 --- a/docs/cluster_shut_down_scenarios.md +++ /dev/null @@ -1,19 +0,0 @@ -#### Kubernetes cluster shut down scenario -Scenario to shut down all the nodes including the masters and restart them after specified duration. 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](https://github.com/krkn-chaos/krkn/blob/main/scenarios/cluster_shut_down_scenario.yml) config file. - -Refer to [cloud setup](cloud_setup.md) to configure your cli properly for the cloud provider of the cluster you want to shut down. - -Current accepted cloud types: -* [Azure](cloud_setup.md#azure) -* [GCP](cloud_setup.md#gcp) -* [AWS](cloud_setup.md#aws) -* [Openstack](cloud_setup.md#openstack) -* [IBMCloud](cloud_setup.md#ibmcloud) - - -``` -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. -``` diff --git a/docs/config.md b/docs/config.md deleted file mode 100644 index 62ab8eb8..00000000 --- a/docs/config.md +++ /dev/null @@ -1,61 +0,0 @@ -### Config -Set the scenarios to inject and the tunings like duration to wait between each scenario in the config file located at [config/config.yaml](https://github.com/redhat-chaos/krkn/blob/main/config/config.yaml). - -**NOTE**: [config](https://github.com/redhat-chaos/krkn/blob/main/config/config_performance.yaml) can be used if leveraging the [automated way](https://github.com/redhat-chaos/krkn#setting-up-infrastructure-dependencies) to install the infrastructure pieces. - -Config components: -* [Kraken](#kraken) -* [Cerberus](#cerberus) -* [Performance Monitoring](#performance-monitoring) -* [Tunings](#tunings) - -# Kraken -This section defines scenarios and specific data to the chaos run - -## Exit on failure -**exit_on_failure**: Exit when a post action check or cerberus run fails - -## Publish kraken status -**publish_kraken_status**: Can be accessed at http://0.0.0.0:8081 (or what signal_address and port you set in signal address section) -**signal_state**: State you want kraken to start at; will wait for the RUN signal to start running a chaos iteration. When set to PAUSE before running the scenarios, refer to [signal.md](signal.md) for more details - -## Signal Address -**signal_address**: Address to listen/post the signal state to -**port**: port to listen/post the signal state to - -## Chaos Scenarios - -**chaos_scenarios**: List of different types of chaos scenarios you want to run with paths to their specific yaml file configurations - -If a scenario has a post action check script, it will be run before and after each scenario to validate the component under test starts and ends at the same state - -Currently the scenarios are run one after another (in sequence) and will exit if one of the scenarios fail, without moving onto the next one - -Chaos scenario types: -- container_scenarios -- plugin_scenarios -- node_scenarios -- time_scenarios -- cluster_shut_down_scenarios -- namespace_scenarios -- zone_outages -- application_outages -- pvc_scenarios -- network_chaos - - -# Cerberus -Parameters to set for enabling of cerberus checks at the end of each executed scenario. The given url will pinged after the scenario and post action check have been completed for each scenario and iteration. -**cerberus_enabled**: Enable it when cerberus is previously installed -**cerberus_url**: When cerberus_enabled is set to True, provide the url where cerberus publishes go/no-go signal -**check_applicaton_routes**: When enabled will look for application unavailability using the routes specified in the cerberus config and fails the run - - -# Performance Monitoring -There are 2 main sections defined in this part of the config [metrics](metrics.md) and [alerts](alerts.md); read more about each of these configurations in their respective docs - -# Tunings -**wait_duration**: Duration to wait between each chaos scenario -**iterations**: Number of times to execute the scenarios -**daemon_mode**: True or False; If true, iterations are set to infinity which means that the kraken will cause chaos forever and number of iterations is ignored - diff --git a/docs/container_scenarios.md b/docs/container_scenarios.md deleted file mode 100644 index af888920..00000000 --- a/docs/container_scenarios.md +++ /dev/null @@ -1,40 +0,0 @@ -### Container Scenarios -Kraken uses the `oc exec` command to `kill` specific containers in a pod. -This can be based on the pods namespace or labels. If you know the exact object you want to kill, you can also specify the specific container name or pod name in the scenario yaml file. -These scenarios are in a simple yaml format that you can manipulate to run your specific tests or use the pre-existing scenarios to see how it works. - -#### Example Config -The following are the components of Kubernetes for which a basic chaos scenario config exists today. - -``` -scenarios: -- name: "" - namespace: "" # can specify "*" if you want to find in all namespaces - label_selector: "