Chaos engineering: LitmusChaos ou Chaos Mesh para resiliência

1. Introdução ao Chaos Engineering em Kubernetes

1.1. Conceitos fundamentais: resiliência, falhas controladas e hipóteses de caos

Chaos Engineering é a disciplina de experimentar em um sistema distribuído para construir confiança na capacidade do sistema de resistir a condições turbulentas em produção. Diferente de testes tradicionais, que verificam funcionalidades esperadas, o caos engineering introduz falhas controladas para validar hipóteses sobre o comportamento do sistema. A premissa central é: "o sistema deve continuar operando mesmo quando componentes falham".

1.2. Por que testar caos em clusters Kubernetes (Docker + orquestração)

Clusters Kubernetes são ambientes dinâmicos com múltiplas camadas: pods, serviços, ingress, volumes persistentes e redes overlay. Falhas podem ocorrer em qualquer nível — um nó pode cair, um pod pode ser reiniciado, a latência de rede pode aumentar. Testar caos permite:

  • Validar políticas de auto-recuperação (ReplicaSets, StatefulSets)
  • Identificar pontos únicos de falha em arquiteturas de microsserviços
  • Garantir que SLAs/SLOs sejam mantidos sob estresse

1.3. Diferença entre testes de estresse tradicionais e experimentos de caos

Testes de estresse tradicionais (ex: carga máxima) focam em capacidade e desempenho. Experimentos de caos focam em resiliência: o que acontece quando um serviço essencial falha inesperadamente? Enquanto testes de estresse medem "até onde o sistema aguenta", caos engineering mede "como o sistema se recupera".

2. Visão Geral das Ferramentas: LitmusChaos e Chaos Mesh

2.1. LitmusChaos: arquitetura, componentes e modelo de execução

LitmusChaos é um framework CNCF que oferece:

  • ChaosCenter: interface web para gerenciar experimentos, workflows e probes
  • Workflows: sequências de experimentos com validação de hipóteses
  • Probes: verificações HTTP, comando ou prometheus para validar estado do sistema
  • Operador Kubernetes: gerencia CRDs como ChaosEngine, ChaosExperiment, ChaosWorkflow

Modelo de execução: o usuário define um ChaosWorkflow que executa experimentos em ordem, com probes de validação entre etapas.

2.2. Chaos Mesh: arquitetura, componentes e tipos de falhas

Chaos Mesh é um projeto CNCF focado em simplicidade e cobertura de falhas:

  • Dashboard: interface web para visualizar e gerenciar experimentos
  • Scheduler: suporte a cron jobs para experimentos recorrentes
  • Sidecar: injeção de falhas via sidecar containers (ex: para falhas de rede)
  • Tipos de falhas: Pod Kill, Pod Failure, Network Partition, DNS Chaos, Stress CPU/Memória, IO Delay

2.3. Comparação de maturidade, comunidade e integração com ecossistema CNCF

Característica LitmusChaos Chaos Mesh
Maturidade CNCF Incubating (2022) CNCF Incubating (2022)
Comunidade 5k+ stars, contribuidores ativos 6k+ stars, contribuidores ativos
Integração Prometheus, Grafana, ArgoCD Prometheus, Grafana, Jaeger
Probes avançadas Sim (HTTP, comando, prometheus) Limitado (apenas verificação básica)
Workflows complexos Sim (DAG, paralelo) Não (apenas sequencial)

3. Instalação e Configuração em Cluster Kubernetes

3.1. Instalação do LitmusChaos via Helm

# Adicionar repositório Helm
helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/
helm repo update

# Instalar LitmusChaos (versão 3.x)
kubectl create ns litmus
helm install litmus litmuschaos/litmus --namespace=litmus --set portal.frontend.service.type=NodePort

# Verificar pods
kubectl get pods -n litmus

Pré-requisitos: Kubernetes 1.20+, RBAC habilitado, acesso ao cluster como admin.

3.2. Instalação do Chaos Mesh via Helm

# Adicionar repositório Helm
helm repo add chaos-mesh https://charts.chaos-mesh.org
helm repo update

# Instalar Chaos Mesh
kubectl create ns chaos-mesh
helm install chaos-mesh chaos-mesh/chaos-mesh --namespace=chaos-mesh --set dashboard.securityMode=false

# Verificar CRDs
kubectl get crd | grep chaos-mesh

Pré-requisitos: Kubernetes 1.20+, CRDs habilitados, sidecar injection suportado.

3.3. Configuração de ambientes air-gapped

Para ambientes offline, ambas as ferramentas suportam instalação via imagens locais:

  • Baixar as imagens Docker em um registry privado
  • Ajustar values.yaml para apontar para o registry local
  • Para LitmusChaos: --set images.registry=myregistry.local
  • Para Chaos Mesh: --set images.registry=myregistry.local

4. Principais Experimentos de Caos e Casos de Uso

4.1. Falhas de pod (Pod Delete, Pod Kill) e testes de auto-recuperação

Simular a exclusão de pods para validar que ReplicaSets recriam automaticamente. Caso de uso: testar se o HPA (Horizontal Pod Autoscaler) reage corretamente.

4.2. Falhas de rede (latência, perda de pacotes, partição) e impacto em serviços

Injetar latência de 500ms em um serviço de pagamento para verificar timeouts e retries. Caso de uso: validar circuit breakers (ex: Hystrix, Resilience4j).

4.3. Falhas de disco, CPU e memória: simulação de degradação de recursos

Estressar CPU de um pod para 90% e observar degradação de desempenho. Caso de uso: testar políticas de resource limits e requests.

5. Criação e Execução de Experimentos Práticos

5.1. LitmusChaos: definindo um ChaosWorkflow com probes de validação

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosWorkflow
metadata:
  name: pod-delete-workflow
  namespace: default
spec:
  workflow:
    steps:
      - name: delete-pod
        template: pod-delete
    templates:
      - name: pod-delete
        chaosEngine:
          appInfo:
            appns: default
            applabel: app=nginx
            appkind: deployment
          experiments:
            - name: pod-delete
              spec:
                probe:
                  - name: check-service
                    type: httpProbe
                    httpProbe/inputs:
                      url: http://nginx-service.default.svc.cluster.local:80
                      expectedResponse: "200"

5.2. Chaos Mesh: definindo um experimento com Schedule e Template

apiVersion: chaos-mesh.org/v1alpha1
kind: Schedule
metadata:
  name: pod-kill-schedule
  namespace: default
spec:
  schedule: "*/5 * * * *"  # A cada 5 minutos
  historyLimit: 5
  concurrencyPolicy: Allow
  type: PodChaos
  podChaos:
    selector:
      namespaces: [default]
      labelSelectors:
        app: nginx
    mode: one
    action: pod-kill
    duration: 30s

5.3. Execução contínua com pipelines CI/CD e rollback automático

Exemplo com GitHub Actions:

name: Chaos Test Pipeline
on:
  schedule:
    - cron: '0 2 * * 1'  # Toda segunda às 2h
jobs:
  chaos-test:
    runs-on: ubuntu-latest
    steps:
      - name: Instalar LitmusChaos CLI
        run: curl -L https://litmuschaos.github.io/litmusctl/litmusctl-linux-amd64.tar.gz | tar xz
      - name: Executar experimento
        run: |
          kubectl apply -f chaos-workflow.yaml
          sleep 60
          kubectl get chaosresult -n default
      - name: Rollback se falha
        if: failure()
        run: kubectl rollout undo deployment/nginx -n default

6. Monitoramento, Observabilidade e Análise de Resultados

6.1. Métricas-chave: tempo de recuperação, taxa de erros, latência p95/p99

  • Tempo de recuperação: intervalo entre início da falha e restauração do serviço
  • Taxa de erros: porcentagem de requisições com status 5xx durante o experimento
  • Latência p95/p99: impacto na performance durante a falha

6.2. Integração com Prometheus/Grafana para dashboards de resiliência

Ambas as ferramentas expõem métricas via Prometheus. Exemplo de query:

# Tempo de recuperação médio (LitmusChaos)
avg(litmus_chaos_experiment_recovery_time_seconds)

# Pods afetados (Chaos Mesh)
chaos_mesh_pod_chaos_pods_affected

6.3. Análise de logs e eventos do Kubernetes durante experimentos de caos

# Eventos do namespace
kubectl get events -n default --watch

# Logs do operador LitmusChaos
kubectl logs -n litmus deployment/litmuschaos-operator

# Logs do Chaos Mesh
kubectl logs -n chaos-mesh deployment/chaos-dashboard

7. Comparação Final: LitmusChaos vs Chaos Mesh

7.1. Facilidade de uso vs flexibilidade: curva de aprendizado e abstrações

  • LitmusChaos: mais flexível com workflows complexos e probes avançadas, mas maior curva de aprendizado
  • Chaos Mesh: mais simples para experimentos básicos, ideal para times iniciantes

7.2. Suporte a políticas de compliance (OPA/Gatekeeper) e blue-green/canary

  • LitmusChaos: suporte nativo a OPA/Gatekeeper via ChaosEngine com securityContext
  • Chaos Mesh: requer configuração manual de políticas de segurança

7.3. Recomendação de escolha baseada em cenários

Cenário Recomendação
Produção com compliance LitmusChaos (probes + workflows)
Startups/experimentação rápida Chaos Mesh (simplicidade)
Ambientes regulados (fintech, saúde) LitmusChaos (auditoria via ChaosCenter)
Testes de rede complexos Chaos Mesh (sidecar para network partition)

8. Boas Práticas e Próximos Passos

8.1. Planejamento de experimentos: frequência, escopo e aprovação de equipe

  • Comece com experimentos em ambientes de staging
  • Defina hipóteses claras antes de cada experimento
  • Estabeleça janelas de caos (ex: 30 minutos, fora do horário comercial)

8.2. Integração com estratégias de deploy (blue-green, canary) para validação de resiliência

Execute experimentos de caos na nova versão durante um canary deploy para validar resiliência antes do rollout completo.

8.3. Evolução para Chaos Engineering como prática contínua

  • Implemente Game Days mensais com toda a equipe
  • Utilize o Chaos Maturity Model para medir evolução:
  • Nível 1: Experimentos manuais
  • Nível 2: Experimentos automatizados em staging
  • Nível 3: Experimentos contínuos em produção com rollback automático
  • Nível 4: Cultura de resiliência incorporada ao ciclo de desenvolvimento

Referências