Extensões do Chaos Toolkit para Kubernetes

Este projeto contém atividades, como sondas e ações, que você pode chamar a partir do seu experimento por meio do Chaos Toolkit para realizar Chaos Engineering contra a API do Kubernetes: matando um pod, removendo um statefulset ou nó...

Instalação

Para ser usado a partir do seu experimento, este pacote deve ser instalado no ambiente Python onde o chaostoolkit já existe.

$ pip install chaostoolkit-kubernetes

Uso

Para usar as sondas e ações deste pacote, adicione o seguinte ao seu arquivo de experimento:

{
    "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
            }
        }
    ]
}

Só isso! Note como a ação oferece a você a maneira de matar um pod aleatoriamente.

Explore a documentação para ver as sondas e ações existentes.

Injeções de falhas de baixo nível

Observe que, para os estressores de rede, cpu e memória, contamos com o fantástico projeto Chaos Mesh, que fornece uma ótima interface para injetar essas falhas.

Você precisará instalar o Chaos Mesh primeiro no seu cluster para usá-los.

Configuração

Usar ~/.kube/config

Se você tiver uma entrada válida no arquivo ~/.kube/config para o cluster que deseja atingir, então não há nada a fazer.

Você pode especificar KUBECONFIG para indicar um local diferente.

$ export KUBECONFIG=/tmp/my-config

Especificar o contexto do Kubernetes

Com frequência, sua configuração do Kubernetes contém várias entradas, e você precisa definir qual usar como contexto padrão quando ele não for fornecido explicitamente.

Você pode, é claro, alterar seu padrão usando kubectl config use-context KUBERNETES_CONTEXT, mas também pode ser explícito em seu experimento da seguinte forma:

{
    "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
            }
        }
    ]
}

Você precisa especificar a chave secreta KUBERNETES_CONTEXT com o nome do contexto que deseja que o experimento use. Certifique-se também de informar às ações e sondas sobre as entradas secretas que devem ser passadas "secrets": ["k8s"].

Usar a service account de um Pod

Ao executar a partir de um pod (não da sua máquina local ou de um CI, por exemplo), o arquivo ./.kube/config não existe. Em vez disso, as credenciais podem ser encontradas em /var/run/secrets/kubernetes.io/serviceaccount/token.

Para informar isso à extensão, basta definir CHAOSTOOLKIT_IN_POD na variável de ambiente da especificação do pod:

env:
- name: CHAOSTOOLKIT_IN_POD
  value: "true"

Ao usar esta variável de ambiente, presume-se que o experimento tenha como alvo o mesmo cluster a partir do qual o experimento está sendo executado. Se o seu experimento tiver como alvo um cluster diferente, você não deve definir esta variável. Em vez disso, você pode montar um volume com uma configuração do Kubernetes para o cluster de destino e definir KUBECONFIG para apontar para ele.

Passar todas as credenciais no experimento

Por fim, você pode passar explicitamente todas as informações de credenciais necessárias para o experimento da seguinte forma:

Usando uma chave de API

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

Usando um nome de usuário/senha

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

Usando uma chave/certificado TLS

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

Autenticação em Clusters Kubernetes Gerenciados

Em alguns clusters Kubernetes gerenciados, você também precisa autenticar-se na própria plataforma, pois a autenticação do Kubernetes é delegada a ela.

Google Cloud Platform

Além das suas credenciais do Kubernetes (por meio do arquivo ~/.kube/config), você precisa autenticar-se na própria Google Cloud Platform. Normalmente, isso é feito via:

$ gcloud auth login

Mas também pode ser feito definindo a variável de ambiente GOOGLE_APPLICATION_CREDENTIALS.

Contribua

Se você deseja contribuir com mais funções para este pacote, fique mais do que à vontade. Por favor, faça um fork deste projeto, escreva testes unitários para cobrir as alterações propostas, implemente as alterações, garanta que elas atendam aos padrões de formatação e, em seguida, abra um PR no repositório para revisão.

Consulte a seção formatação para obter mais informações sobre os padrões de formatação.

Os projetos do Chaos Toolkit exigem que todos os contribuidores assinem um Developer Certificate of Origin em cada commit que desejem mesclar no branch master do repositório. Certifique-se de que você pode cumprir as regras do DCO antes de enviar um PR.

Desenvolver

Se você deseja desenvolver neste projeto, certifique-se de instalar as dependências de desenvolvimento. Mas primeiro, instale o PDM e depois instale as dependências.

$ pdm install

Agora, você pode editar os arquivos, e eles serão automaticamente vistos pelo seu ambiente, mesmo ao executar o comando chaos localmente.

Testes

Para executar os testes do projeto, execute o seguinte:

$ pdm run tests

Formatação e Linting

Usamos o ruff para fazer lint e formatar o código deste repositório.

Antes de abrir um Pull Request, recomendamos que você execute a formatação no seu código com:

$ pdm run format

Isso formatará automaticamente qualquer código que não esteja em conformidade com os padrões de formatação.

Como algumas coisas não são detectadas pela formatação, também recomendamos que você execute:

$ pdm run lint

Para garantir que quaisquer declarações de importação não utilizadas/strings muito longas, etc., também sejam detectadas.