O kube-monkey é uma implementação do Chaos Monkey da Netflix para clusters Kubernetes. Ele exclui aleatoriamente pods do Kubernetes (k8s) no cluster, incentivando e validando o desenvolvimento de serviços resilientes a falhas.

Junte-se a nós em #kube-monkey no Slack do Kubernetes.

O kube-monkey é executado em um horário pré-configurado (run_hour, padrão às 8h) nos dias úteis e cria um cronograma de deployments que sofrerão uma morte aleatória de Pod em algum momento do mesmo dia. A faixa horária do dia em que a morte aleatória de pod pode ocorrer é configurável e o padrão é das 10h às 16h.

O kube-monkey pode ser configurado com uma lista de namespaces

para incluir na lista negra (nenhum deployment em um namespace na lista negra será tocado)

Para desativar a lista negra, forneça [""] no parâmetro de configuração blacklisted_namespaces.

Adesão ao Caos

O kube-monkey funciona com um modelo de adesão (opt-in) e só programará terminações para aplicativos Kubernetes (k8s) que concordaram explicitamente em ter seus pods terminados pelo kube-monkey.

A adesão é feita definindo os seguintes labels em um aplicativo k8s:

kube-monkey/enabled: Defina como "enabled" para aderir ao kube-monkey
kube-monkey/mtbf: Tempo médio entre falhas, como um número inteiro e uma unidade: d para dias, h para horas ou m para minutos. Por exemplo, se definido como "3d", o aplicativo k8s pode esperar ter um Pod morto aproximadamente a cada terceiro dia útil; se definido como "2h", pode esperar perder um Pod a cada duas horas. Um valor sem unidade é interpretado como dias, então "3" e "3d" significam a mesma coisa. O menor tempo médio entre falhas é um minuto. Observe que todas as terminações acontecem dentro da janela de execução diária (veja start_hour e end_hour), portanto um mtbf mais curto que um dia concentra as terminações desse dia nessa janela. : Um identificador exclusivo para os aplicativos k8s. Ele é usado para identificar os pods que pertencem a um aplicativo k8s, pois os Pods herdam labels do seu aplicativo k8s. Assim, se o kube-monkey detectar que o aplicativo se cadastrou como vítima, o kube-monkey procurará todos os pods que tenham o label para determinar quais pods são candidatos a serem mortos. A recomendação é definir esse valor como o mesmo nome do aplicativo. : O comportamento padrão é o kube-monkey matar apenas UM pod do seu aplicativo. Você pode substituir esse comportamento definindo o valor para:

kill-all se você quiser que o kube-monkey mate TODOS os seus pods, independentemente do status (incluindo pods não prontos e não em execução). Não exige kill-value. Use este label com cuidado.
fixed se você quiser matar um número específico de pods em execução com kill-value. Se você especificar a mais, ele matará todos os pods em execução e emitirá um aviso.
random-max-percent para especificar um % máximo com kill-value que pode ser morto. No horário agendado, uma porcentagem uniforme especificada aleatoriamente dos pods em execução será terminada.
fixed-percent para especificar um % fixo com kill-value que pode ser morto. No horário agendado, uma porcentagem especificada fixa dos pods em execução será terminada.

kube-monkey/kill-value: Especifique o valor para o kill-mode

se fixed, informe um inteiro de pods para matar
se random-max-percent, informe um número de 0 a 100 para especificar o % máximo de pods que o kube-monkey pode matar
se fixed-percent, informe um número de 0 a 100 para especificar o % de pods para matar

Exemplo de Deployment que aderiu matando um pod por purga

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: monkey-victim
  namespace: app-namespace
spec:
  template:
    metadata:
      labels:
        kube-monkey/enabled: enabled
        kube-monkey/identifier: monkey-victim
        kube-monkey/mtbf: '2'
        kube-monkey/kill-mode: "fixed"
        kube-monkey/kill-value: '1'
[... omitted ...]

Para versões mais recentes do kubernetes, pode ser necessário adicionar os labels também aos metadados do aplicativo k8s.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: monkey-victim
  namespace: app-namespace
  labels:
    kube-monkey/enabled: enabled
    kube-monkey/identifier: monkey-victim
    kube-monkey/mtbf: '2'
    kube-monkey/kill-mode: "fixed"
    kube-monkey/kill-value: '1'
spec:
  template:
    metadata:
      labels:
        kube-monkey/enabled: enabled
        kube-monkey/identifier: monkey-victim
[... omitted ...]

Substituindo o apiserver

Casos de uso:

Como o client-go não suporta cluster dns explicitamente, com uma nota // TODO: switch to using cluster DNS. no código, talvez seja necessário substituir o apiserver.
Se você estiver executando um sistema não autenticado, talvez seja necessário forçar o endpoint http do apiserver.

Para substituir o apiserver, especifique no arquivo config.toml

[kubernetes]
host="https://your-apiserver-url.com:apiport"

Como o kube-monkey funciona

Horário de agendamento

O agendamento acontece uma vez por dia, nos dias úteis - é quando o cronograma de terminações do dia atual é gerado. Durante o agendamento, o kube-monkey:

Gera uma lista de aplicativos k8s elegíveis (aplicativos k8s que aderiram e não estão na lista negra, se especificada, e estão na lista branca, se especificada)
Para cada aplicativo k8s elegível, calcula quantos pods matar hoje com base em kube-monkey/mtbf. Um aplicativo é morto 24h/mtbf vezes por dia, portanto, um mtbf de um dia ou mais resulta em no máximo uma terminação, e um mais curto resulta em várias
Para cada terminação, calcula um horário aleatório em que um pod será morto

Horário de terminação

Este é o horário gerado aleatoriamente durante o dia em que um aplicativo k8s vítima terá um pod morto. No horário de terminação, o kube-monkey:

Verifica se o aplicativo k8s ainda é elegível (não optou por sair, não foi colocado na lista negra nem removido da lista branca desde o agendamento)
Verifica se o aplicativo k8s atualizou o kill-mode e o kill-value
Dependendo do kill-mode e do kill-value, executa os pods

Imagens Docker

As imagens Docker do kube-monkey podem ser encontradas no DockerHub

Compilação

Clone o repositório e construa o container.

go get github.com/asobti/kube-monkey
cd $GOPATH/src/github.com/asobti/kube-monkey
make build
make container

Configuração

O kube-monkey é configurado por variáveis de ambiente ou por um arquivo toml localizado em /etc/kube-monkey/config.toml e espera que o configmap exista antes do deployment do kube-monkey.

As chaves de configuração e as descrições podem ser encontradas em config/param/param.go

Exemplo de arquivo config.toml

[kubemonkey]
dry_run = true                           # Terminations are only logged
run_hour = 8                             # Run scheduling at 8am on weekdays
start_hour = 10                          # Don't schedule any pod deaths before 10am
end_hour = 16                            # Don't schedule any pod deaths after 4pm
blacklisted_namespaces = ["kube-system"] # Critical apps live here
time_zone = "America/New_York"           # Set tzdata timezone example. Note the field is time_zone not timezone

Exemplo de variáveis de ambiente

KUBEMONKEY_DRY_RUN=true
KUBEMONKEY_RUN_HOUR=8
KUBEMONKEY_START_HOUR=10
KUBEMONKEY_END_HOUR=16
KUBEMONKEY_BLACKLISTED_NAMESPACES=kube-system
KUBEMONKEY_TIME_ZONE=America/New_York

Exemplo de configuração para testar se o kube-monkey funciona habilitando o modo de depuração

Nota: isso continuará atacando pods a cada 60s, independentemente do que você configurou para startHour e endHour.

[debug]
enabled= true
schedule_immediate_kill= true

Notificações

O Kube-monkey suporta notificações e pode notificar um endpoint de sua escolha após um ataque. Pode ser um webhook do Slack ou uma API personalizada.

Exemplo de configuração para enviar notificações de ataque para um endpoint HTTP

[notifications]
  enabled = true
  reportSchedule = true
  [notifications.attacks]
    endpoint = "http://url1"
    message = "message1"
    headers = ["header1Key:header1Value","header2Key:header2/Value"]

Placeholders

A mensagem suporta os seguintes placeholders:

{$name}: nome da vítima
{$kind}: tipo da vítima
{$namespace}: namespace da vítima
{$timestamp}: horário do ataque a partir da época Unix em milissegundos
{$time}: horário do ataque
{$date}: data do ataque
{$error}: erro do resultado, se houver
{$kubemonkeyid}: id do kube-monkey (definido usando a variável de ambiente KUBE_MONKEY_ID, caso contrário vazio)

  message: '{
            "what": "Kube-monkey(${kubemonkeyid}) attack of {$name} in {$namespace}",
            "who": "{$name}",
            "when": {$timestamp}
           }'

O header suporta um placeholder especial para recuperar o valor de uma variável de ambiente. Isso é útil ao chamar uma API que tenha um endpoint protegido. Um cenário típico é passar um token de API para o container do Kube-monkey; esse token é armazenado em um Secret do Kubernetes e você deseja passá-lo por meio de uma variável de ambiente.

headers = ["api-key:{$env:API_TOKEN}", "Content-Type:application/json"]

{$env:API_TOKEN} será substituído pelo valor da variável de ambiente API_TOKEN.

Nota: se a variável de ambiente não existir, a chamada de notificação NÃO será cancelada. O valor será resolvido como uma string vazia e um aviso aparecerá nos logs.

Implantação

Manualmente

Primeiro, implante o configmap kube-monkey-config-map esperado no namespace em que você pretende executar o kube-monkey (por exemplo, o namespace kube-system). Certifique-se de definir o nome da chave como config.toml

Por exemplo, kubectl create configmap km-config --from-file=config.toml=km-config.toml ou kubectl apply -f km-config.yaml

Execute o kube-monkey como um aplicativo k8s dentro do cluster Kubernetes, em um namespace que tenha permissões para matar Pods em outros namespaces (ex.: kube-system).

Consulte o diretório examples/ para ver exemplos de arquivos yaml do Kubernetes.

Você deve conseguir ver os logs de depuração com kubectl logs -f deployment.apps/kube-monkey --namespace=kube-system; aqui, deployment.apps/kube-monkey é o deployment k8s do kube-monkey.

Helm Chart

Consulte Como instalar o kube-monkey com Helm.

Logs

O kube-monkey usa glog e suporta todos os recursos de linha de comando do glog. Para especificar um nível v personalizado ou um diretório de log personalizado no pod, veja args: ["-v=5", "-log_dir=/path/to/custom/log"] no arquivo de exemplo de deployment

Níveis glog padronizados grep -r V$[0-9]$ *

L0: Nenhum

L1: Informações de status atuais de nível mais alto e erros com terminações

L2: Terminações bem-sucedidas

L3: Informações mais detalhadas do status do agendamento

L4: Depuração detalhada de agendamento e informações de configuração

L5: Problemas irrelevantes resolvidos automaticamente

Mais recursos: consulte a página de logging do k8s que sugere convenções da comunidade para severidade de logging

Instruções para fazer isso funcionar no OpenShift 3.x

git clone https://github.com/asobti/kube-monkey.git
cd examples
oc login http://someserver/ -u system:admin
oc project kube-system
oc create -f configmap.yaml
oc -n kube-system adm policy add-role-to-user -z deployer system:deployer
oc -n kube-system adm policy add-role-to-user -z builder system:image-builder
oc -n kube-system adm policy add-role-to-group system:image-puller system:serviceaccounts:kube-system
oc run kube-monkey --image=docker.io/ayushsobti/kube-monkey:v0.4.0 --command -- /kube-monkey -v=5 -log_dir=/var/log/kube-monkey
oc volume dc/kube-monkey --add --name=kubeconfigmap -m /etc/kube-monkey -t configmap --configmap-name=kube-monkey-config-map

OpenShift 4.x

git clone https://github.com/asobti/kube-monkey.git
cd examples
oc login http://someserver/ -u system:admin
oc project kube-system
oc create -f configmap.yaml
oc -n kube-system adm policy add-cluster-role-to-user edit -z default --rolebinding-name kube-monkey-edit
oc run kube-monkey --image=docker.io/ayushsobti/kube-monkey:v0.3.0 --command -- /kube-monkey -v=5 -log_dir=/var/log/kube-monkey
oc set volume dc/kube-monkey --add --name=kubeconfigmap -m /etc/kube-monkey -t configmap --configmap-name=kube-monkey-config-map

Formas de contribuir

Consulte Como Contribuir

Licença

Este projeto é licenciado sob a Apache License v2.0 - consulte o arquivo LICENSE para obter detalhes.

kube-monkey

Mais Populares