All Projects → chaostoolkit → Chaostoolkit Kubernetes

chaostoolkit / Chaostoolkit Kubernetes

Licence: apache-2.0
Kubernetes driver extension of the Chaos Toolkit probes and actions API

Programming Languages

python
139335 projects - #7 most used programming language

Projects that are alternatives of or similar to Chaostoolkit Kubernetes

Litmus
Litmus helps SREs and developers practice chaos engineering in a Cloud-native way. Chaos experiments are published at the ChaosHub (https://hub.litmuschaos.io). Community notes is at https://hackmd.io/a4Zu_sH4TZGeih-xCimi3Q
Stars: ✭ 2,377 (+1453.59%)
Mutual labels:  cloud-native, chaos-engineering
Mangle
Git Repository for the Mangle tool
Stars: ✭ 125 (-18.3%)
Mutual labels:  cloud-native, chaos-engineering
Chaos Mesh
A Chaos Engineering Platform for Kubernetes.
Stars: ✭ 4,265 (+2687.58%)
Mutual labels:  cloud-native, chaos-engineering
Powerfulseal
A powerful testing tool for Kubernetes clusters.
Stars: ✭ 1,725 (+1027.45%)
Mutual labels:  chaos-engineering
Dubbo Go Pixiu
Based on the proxy gateway service of dubbo-go, it solves the problem that the external protocol calls the internal Dubbo cluster. At present, it supports HTTP and gRPC[developing].
Stars: ✭ 124 (-18.95%)
Mutual labels:  cloud-native
Vpp Agent
⚡️ Control plane management agent for FD.io's VPP
Stars: ✭ 137 (-10.46%)
Mutual labels:  cloud-native
Fluvio
Cloud-native distributed data streaming platform, written in Rust
Stars: ✭ 149 (-2.61%)
Mutual labels:  cloud-native
Book Cicd Docker Kubernetes
A book on CI/CD with Docker, Kubernetes and Semaphore
Stars: ✭ 122 (-20.26%)
Mutual labels:  cloud-native
Pathivu
An efficient log ingestion and log aggregation system https://pathivu.io/
Stars: ✭ 146 (-4.58%)
Mutual labels:  cloud-native
Curiefense
Curiefense is a unified, open source platform protecting cloud native applications.
Stars: ✭ 136 (-11.11%)
Mutual labels:  cloud-native
Spring Cloud Config
External configuration (server and client) for Spring Cloud
Stars: ✭ 1,740 (+1037.25%)
Mutual labels:  cloud-native
Booster
Booster Cloud Framework
Stars: ✭ 136 (-11.11%)
Mutual labels:  cloud-native
Rafter
Kubernetes-native S3-like files/assets store based on CRDs and powered by MinIO
Stars: ✭ 145 (-5.23%)
Mutual labels:  cloud-native
Cheekymonkey
🐵 Literally a Chaos Monkey for your Kubernetes clusters
Stars: ✭ 133 (-13.07%)
Mutual labels:  chaos-engineering
Azkarra Streams
🚀 Azkarra is a lightweight java framework to make it easy to develop, deploy and manage cloud-native streaming microservices based on Apache Kafka Streams.
Stars: ✭ 146 (-4.58%)
Mutual labels:  cloud-native
Rudr
A Kubernetes implementation of the Open Application Model specification
Stars: ✭ 1,553 (+915.03%)
Mutual labels:  cloud-native
Kubernetes Vagrant Centos Cluster
Setting up a distributed Kubernetes cluster along with Istio service mesh locally with Vagrant and VirtualBox, only PoC or Demo use.
Stars: ✭ 1,750 (+1043.79%)
Mutual labels:  cloud-native
Coolstore Microservices
A full-stack .NET microservices build on Dapr and Tye
Stars: ✭ 1,903 (+1143.79%)
Mutual labels:  cloud-native
Hazelcast Kubernetes
Kubernetes Discovery for Hazelcast
Stars: ✭ 151 (-1.31%)
Mutual labels:  cloud-native
Beetle
🔥 Kubernetes multi-cluster deployment automation service.
Stars: ✭ 149 (-2.61%)
Mutual labels:  cloud-native

Chaos Toolkit Extensions for Kubernetes

Build Status codecov Python versions Downloads

This project contains activities, such as probes and actions, you can call from your experiment through the Chaos Toolkit to perform Chaos Engineering against the Kubernetes API: killing a pod, removing a statefulset or node...

Install

To be used from your experiment, this package must be installed in the Python environment where chaostoolkit already lives.

$ pip install chaostoolkit-kubernetes

Usage

To use the probes and actions from this package, add the following to your experiment file:

{
    "title": "Do we remain available in face of pod going down?",
    "description": "We expect Kubernetes to handle the situation gracefully when a pod goes down",
    "tags": ["kubernetes"],
    "steady-state-hypothesis": {
        "title": "Verifying service remains healthy",
        "probes": [
            {
                "name": "all-our-microservices-should-be-healthy",
                "type": "probe",
                "tolerance": true,
                "provider": {
                    "type": "python",
                    "module": "chaosk8s.probes",
                    "func": "microservice_available_and_healthy",
                    "arguments": {
                        "name": "myapp"
                    }
                }
            }
        ]
    },
    "method": [
        {
            "type": "action",
            "name": "terminate-db-pod",
            "provider": {
                "type": "python",
                "module": "chaosk8s.pod.actions",
                "func": "terminate_pods",
                "arguments": {
                    "label_selector": "app=my-app",
                    "name_pattern": "my-app-[0-9]$",
                    "rand": true
                }
            },
            "pauses": {
                "after": 5
            }
        }
    ]
}

That's it! Notice how the action gives you the way to kill one pod randomly.

Please explore the documentation to see existing probes and actions.

Configuration

Use ~/.kube/config

If you have a valid entry in your ~/.kube/config file for the cluster you want to target, then there is nothing to be done.

You may specify KUBECONFIG to specify a different location.

$ export KUBECONFIG=/tmp/my-config

Specify the Kubernetes context

Quite often, your Kubernetes configuration contains several entries and you need to define the one to use as a default context when not it isn't explicitely provided.

You may of course change your default using kubectl config use-context KUBERNETES_CONTEXT but you can also be explicit in your experiment as follows:

{
    "title": "Do we remain available in face of pod going down?",
    "description": "We expect Kubernetes to handle the situation gracefully when a pod goes down",
    "tags": ["kubernetes"],
    "secrets": {
        "k8s": {
            "KUBERNETES_CONTEXT": "..."
        }
    },
    "steady-state-hypothesis": {
        "title": "Verifying service remains healthy",
        "probes": [
            {
                "name": "all-our-microservices-should-be-healthy",
                "type": "probe",
                "tolerance": true,
                "secrets": ["k8s"],
                "provider": {
                    "type": "python",
                    "module": "chaosk8s.probes",
                    "func": "microservice_available_and_healthy",
                    "arguments": {
                        "name": "myapp"
                    }
                }
            }
        ]
    },
    "method": [
        {
            "type": "action",
            "name": "terminate-db-pod",
            "secrets": ["k8s"],
            "provider": {
                "type": "python",
                "module": "chaosk8s.pod.actions",
                "func": "terminate_pods",
                "arguments": {
                    "label_selector": "app=my-app",
                    "name_pattern": "my-app-[0-9]$",
                    "rand": true
                }
            },
            "pauses": {
                "after": 5
            }
        }
    ]
}

You need to specify the KUBERNETES_CONTEXT secret key to the name of the context you want the experiment to use. Make sure to also inform the actions and probes about the secret entries they should be passed "secrets": ["k8s"].

Use a Pod's service account

When running from a pod (not your local machine or a CI for instance), the ./.kube/config file does not exist. Instead, the credentials can be found at /var/run/secrets/kubernetes.io/serviceaccount/token.

To let the extension know about this, simply set CHAOSTOOLKIT_IN_POD from the environment variable of the pod specification:

env:
- name: CHAOSTOOLKIT_IN_POD
  value: "true"

Pass all credentials in the experiment

Finally, you may pass explicitely all required credentials information to the experiment as follows:

Using an API key

{
    "secrets": {
        "kubernetes": {
            "KUBERNETES_HOST": "http://somehost",
            "KUBERNETES_API_KEY": {
                "type": "env",
                "key": "SOME_ENV_VAR"
            }
        }
    }
}

Using a username/password

{
    "secrets": {
        "kubernetes": {
            "KUBERNETES_HOST": "http://somehost",
            "KUBERNETES_USERNAME": {
                "type": "env",
                "key": "SOME_ENV_VAR"
            },
            "KUBERNETES_PASSWORD": {
                "type": "env",
                "key": "SOME_ENV_VAR"
            }
        }
    }
}

Using a TLS key/certificate

{
    "secrets": {
        "kubernetes": {
            "KUBERNETES_HOST": "http://somehost",
            "KUBERNETES_CERT_FILE": {
                "type": "env",
                "key": "SOME_ENV_VAR"
            },
            "KUBERNETES_KEY_FILE": {
                "type": "env",
                "key": "SOME_ENV_VAR"
            }
        }
    }
}

Managed Kubernetes Clusters Authentication

On some managed Kubernetes clusters, you also need to authenticate against the platform itself because the Kubernetes authentication is delegated to it.

Google Cloud Platform

In addition to your Kubernetes credentials (via the ~/.kube/config file), you need to authenticate against the Google Cloud Platform itself. Usually this is done via:

$ gcloud auth login

But can also be achieved by defining the GOOGLE_APPLICATION_CREDENTIALS environment variable.

Contribute

If you wish to contribute more functions to this package, you are more than welcome to do so. Please fork this project, make your changes following the usual PEP 8 code style, add appropriate tests and submit a PR for review.

The Chaos Toolkit projects require all contributors must sign a Developer Certificate of Origin on each commit they would like to merge into the master branch of the repository. Please, make sure you can abide by the rules of the DCO before submitting a PR.

Develop

If you wish to develop on this project, make sure to install the development dependencies. But first, create a virtual environment and then install those dependencies.

$ pip install -r requirements-dev.txt -r requirements.txt

Then, point your environment to this directory:

$ pip install -e .

Now, you can edit the files and they will be automatically be seen by your environment, even when running from the chaos command locally.

Test

To run the tests for the project execute the following:

$ pytest
Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].