Como Usar Chaos Engineering em Kubernetes: LitmusChaos e Testes de Resiliência em Produção Já leu

O que é Chaos Engineering e por que é Crítico em Kubernetes

Chaos Engineering é a prática disciplinada de injetar falhas controladas em sistemas de produção para descobrir fraquezas antes que elas causem incidentes reais. Diferentemente dos testes tradicionais, que validam o caminho feliz, o Chaos Engineering questiona "o que acontece quando as coisas dão errado?" — e faz isso propositalmente em ambientes controlados.

Em Kubernetes, essa prática é especialmente valiosa porque os sistemas distribuídos são inerentemente complexos. Você pode ter múltiplas réplicas, balanceadores de carga, redes sobrecarregadas e componentes falhando simultaneamente. Um pod pode desaparecer, um nó pode ficar indisponível, ou o tráfego de rede pode sofrer latência. Sem testes de resiliência, você só descobre esses cenários quando afetam seus usuários. O Chaos Engineering muda esse paradigma: você quer descobrir esses problemas agora, enquanto pode correções de forma segura e controlada.

O Impacto no Negócio

Empresas que implementam Chaos Engineering reduzem significativamente o tempo de detecção e correção de falhas (MTTR). Mais importante, aumentam a confiança no sistema — você sabe que sua aplicação sobreviveu a cenários reais porque você a testou contra eles. Isso se traduz em menos downtime não planejado, melhor experiência do usuário e, consequentemente, maior receita.

Introdução ao LitmusChaos: Arquitetura e Conceitos

LitmusChaos é uma plataforma de código aberto mantida pela CNCF que torna o Chaos Engineering acessível em Kubernetes. Em vez de criar scripts personalizados para injetar falhas, você declara seus testes de caos através de manifests Kubernetes, executando-os como parte de seu pipeline de CI/CD ou manualmente quando necessário.

A arquitetura do LitmusChaos é elegante e segue os princípios nativos de Kubernetes. No centro está o conceito de ChaosEngine, um Custom Resource Definition (CRD) que orquestra a execução de experimentos. Cada experimento é um manifesto que define exatamente qual falha será injetada, em quais recursos e por quanto tempo. O ChaosOperator monitora esses manifests e coordena a execução através de Chaos Runners — jobs temporários que executam a lógica de injeção de falha. Após a execução, um ChaosResult registra os detalhes do experimento: sucesso, falha, duração e métricas coletadas.

Componentes Principais

ChaosEngine: Define o experimento — qual tipo de caos executar, contra quais recursos e com quais parâmetros. É como um manifesto Deployment, mas para o caos. ChaosExperiment: Um CRD que descreve a lógica técnica de como injetar a falha específica. Cada tipo de caos (kill pod, network latency, disk fill) tem seu próprio ChaosExperiment. ChaosResult: Um objeto que registra o resultado da execução — passou ou falhou nos critérios definidos. Você usa isso para automatizar decisões no pipeline: se um teste de caos falhar, bloquear o deploy.

Instalação e Configuração Prática

Antes de executar qualquer teste, você precisa instalar o LitmusChaos em seu cluster. O processo é simples e segue o padrão de qualquer operador Kubernetes.

# 1. Criar namespace dedicado
kubectl create namespace litmus

# 2. Instalar LitmusChaos via Helm
helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/
helm repo update
helm install litmus litmuschaos/litmus --namespace litmus

# 3. Verificar instalação
kubectl get pods -n litmus
kubectl get crd | grep litmuschaos

Após alguns segundos, você verá o operador rodando. Agora você precisa instalar os Chaos Experiments que você quer usar. O LitmusChaos fornece uma biblioteca pré-construída de experimentos para cenários comuns.

# Instalar experimentos de pod chaos (kill pods, network issues)
kubectl apply -f https://hub.litmuschaos.io/api/v1.0.0/sample-chartservices/pod-chaos/experiments.yaml -n litmus

# Instalar experimentos de node chaos (simular falha de nó)
kubectl apply -f https://hub.litmuschaos.io/api/v1.0.0/sample-chartservices/node-chaos/experiments.yaml -n litmus

Verificação da Instalação

# Listar todos os CRDs de caos disponíveis
kubectl get crds | grep chaos

# Listar todos os experimentos disponíveis
kubectl get chaosexperiments -n litmus

Criando e Executando Seu Primeiro Experimento

Agora vem a parte prática: criar um experimento real que testa a resiliência de sua aplicação. Vamos supor que você tem uma aplicação de e-commerce em Kubernetes com a arquitetura comum: frontend, backend e banco de dados. Você quer testar se o frontend continua funcionando quando um pod do backend é morto abruptamente.

Preparação: Deployar uma Aplicação de Teste

# app-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-api
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: backend-api
  template:
    metadata:
      labels:
        app: backend-api
    spec:
      containers:
      - name: api
        image: nginx:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: backend-api
  namespace: default
spec:
  selector:
    app: backend-api
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: ClusterIP

Aplique isso no seu cluster:

kubectl apply -f app-deployment.yaml
kubectl get pods -n default | grep backend-api

Você deve ver 3 pods rodando. Agora vamos injetar caos matando um deles.

Criando um ChaosEngine para Pod Kill

# chaos-kill-pod.yaml
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: backend-chaos-kill
  namespace: default
spec:
  # Definir o aplicativo alvo
  appinfo:
    appns: 'default'
    applabel: 'app=backend-api'
    appkind: 'deployment'

  # Configurar o orquestrador de caos
  engineState: 'active'
  chaosServiceAccount: 'litmus-admin'

  # Definir o experimento a executar
  experiments:
  - name: pod-delete
    spec:
      components:
        env:
        # Força do caos: quantos pods deletar
        - name: TOTAL_CHAOS_DURATION
          value: '30'
        - name: CHAOS_INTERVAL
          value: '10'
        - name: FORCE
          value: 'true'
        - name: NAMESPACE
          value: 'default'
      probe: []
      verdict: 'Awaited'

Agora você precisa criar o Service Account que o caos usará:

# chaos-rbac.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: litmus-admin
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: litmus-admin
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "create", "update", "patch", "delete", "list", "watch"]
- apiGroups: [""]
  resources: ["events"]
  verbs: ["get", "create", "patch"]
- apiGroups: ["apps"]
  resources: ["deployments", "statefulsets"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: litmus-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: litmus-admin
subjects:
- kind: ServiceAccount
  name: litmus-admin
  namespace: default

Aplique os manifests:

kubectl apply -f chaos-rbac.yaml
kubectl apply -f chaos-kill-pod.yaml

Monitorando a Execução

# Ver o ChaosEngine em execução
kubectl get chaosengine -n default
kubectl describe chaosengine backend-chaos-kill -n default

# Ver os pods sendo eliminados em tempo real
kubectl get pods -n default -w

# Ver o resultado do experimento
kubectl get chaosresult -n default
kubectl describe chaosresult backend-chaos-kill-pod-delete -n default

Enquanto o caos roda (30 segundos), você verá pods do backend sendo mortos e recriados. A verdadeira questão é: sua aplicação mantém tráfego sendo roteado corretamente? As conexões são gracefully encerradas? Se você monitorar métricas de erro, elas devem ser mínimas ou zero.

Testes Avançados: Injeção de Latência de Rede

Matar pods é um cenário óbvio, mas a maioria das falhas em produção é mais sutil. Latência de rede, perda de pacotes e contenção de recursos causam mais danos ao longo do tempo do que falhas catastrophais. Vamos criar um experimento que simula latência de rede.

# chaos-network-latency.yaml
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: backend-chaos-latency
  namespace: default
spec:
  appinfo:
    appns: 'default'
    applabel: 'app=backend-api'
    appkind: 'deployment'

  engineState: 'active'
  chaosServiceAccount: 'litmus-admin'

  experiments:
  - name: pod-network-latency
    spec:
      components:
        env:
        # Adicionar 500ms de latência
        - name: NETWORK_LATENCY
          value: '500'
        # Durante 60 segundos
        - name: TOTAL_CHAOS_DURATION
          value: '60'
        # Quantos pods afetados
        - name: PODS_AFFECTED_PERC
          value: '66'
        # Namespace alvo
        - name: NAMESPACE
          value: 'default'
        # Interface de rede
        - name: NETWORK_INTERFACE
          value: 'eth0'
      probe: []

A latência simulada afeta conexões TCP/IP reais. Se seu backend faz chamadas para um microserviço externo e espera por resposta, essa latência pode fazer timeout ocorrer. Se não há retry logic ou circuit breaker, a falha em cascata. Ao testar isso, você descobre onde adicionar resiliência — timeouts mais altos, retries exponenciais, ou cache.

Usando Probes para Validação Automática

Um experimento que só injeta caos é metade do caminho. A outra metade é validar automaticamente se seu sistema se comportou como esperado. Para isso, você usa Probes — testes pequenos e específicos executados durante o caos.

# chaos-with-probe.yaml
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: backend-chaos-validated
  namespace: default
spec:
  appinfo:
    appns: 'default'
    applabel: 'app=backend-api'
    appkind: 'deployment'

  engineState: 'active'
  chaosServiceAccount: 'litmus-admin'

  experiments:
  - name: pod-delete
    spec:
      components:
        env:
        - name: TOTAL_CHAOS_DURATION
          value: '30'
        - name: FORCE
          value: 'true'
        - name: NAMESPACE
          value: 'default'

      # Aqui começam as probes
      probe:
      - name: check-backend-availability
        type: httpProbe
        httpProbe/inputs:
          url: "http://backend-api.default.svc.cluster.local/health"
          insecureSkipVerify: true
          method:
            get: {}
        mode: Continuous
        runProperties:
          probeTimeout: 5
          interval: 2
          retry: 3
          initialDelaySecs: 5

      - name: check-pod-count
        type: k8sProbe
        k8sProbe/inputs:
          group: ""
          version: "v1"
          resource: "pods"
          namespace: "default"
          fieldSelector: "status.phase=Running"
          labelSelector: "app=backend-api"
        mode: Continuous
        runProperties:
          probeTimeout: 10
          interval: 5

Com probes, o LitmusChaos monitora continuamente durante o caos e gera um relatório final. Se o endpoint HTTP ficar down por mais tempo que o permitido, o experimento falha automaticamente, marcando a resiliência como inadequada.

Integrando Chaos Engineering no Pipeline CI/CD

A verdadeira maturidade em Chaos Engineering é quando os testes de caos rodam automaticamente, bloqueando deploys que falham em cenários de resiliência. Aqui está como integrar com GitLab CI:

# .gitlab-ci.yml
stages:
  - test
  - chaos
  - deploy

chaos-tests:
  stage: chaos
  image: bitnami/kubectl:latest
  script:
    # Deploy da aplicação de teste
    - kubectl apply -f app-deployment.yaml
    - kubectl wait --for=condition=ready pod -l app=backend-api --timeout=300s

    # Deploy do experimento de caos
    - kubectl apply -f chaos-rbac.yaml
    - kubectl apply -f chaos-kill-pod.yaml

    # Aguardar conclusão (6 minutos de timeout)
    - kubectl wait chaosengine/backend-chaos-kill --for=condition=Completed --timeout=360s

    # Validar resultado
    - |
      RESULT=$(kubectl get chaosresult -n default -o jsonpath='{.items[0].spec.verdict}')
      if [ "$RESULT" != "Pass" ]; then
        echo "Chaos test failed!"
        exit 1
      fi
  only:
    - merge_requests

Adicione isso ao seu repositório. Agora, toda PR rodará testes de caos automaticamente. Se a aplicação não é resiliente o suficiente, o merge é bloqueado. Nada passa sem passar na luta contra o caos.

Métricas e Observabilidade

Para realmente entender o comportamento durante o caos, você precisa de métricas. O LitmusChaos integra com Prometheus e você pode exportar resultados para qualquer sistema de monitoramento.

# Instalar Prometheus (se ainda não tiver)
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus prometheus-community/kube-prometheus-stack -n monitoring --create-namespace

# O LitmusChaos expõe métricas em localhost:8000/metrics
# Configure seu Prometheus para scrape esse endpoint

As métricas importantes são:

• litmuschaos_experiment_verdict: 1 se passou, 0 se falhou
• litmuschaos_experiment_duration_seconds: Quanto tempo o experimento levou
• litmuschaos_experiment_injected_chaos_total: Contador de quantas falhas foram injetadas

Combine isso com suas métricas de aplicação (latência, taxa de erro, throughput) para ver exatamente como a aplicação reagiu ao caos.

Conclusão

Chaos Engineering em Kubernetes através do LitmusChaos oferece três ganhos principais. Primeiro, você descobre falhas antes de seus usuários descobrirem. Em vez de reactive firefighting em produção, você é proativo durante o desenvolvimento. Segundo, o LitmusChaos torna isso acessível — não precisa de scripts custom ou modificações no código da aplicação, tudo é declarativo e reutilizável. Terceiro, integrando com CI/CD, você força qualidade de resiliência como um requisito, não uma nice-to-have. Seu sistema entra em produção já sabendo que sobreviveu a cenários reais de falha.

Referências

• LitmusChaos Official Documentation: https://docs.litmuschaos.io/
• Kubernetes Chaos Engineering Best Practices: https://www.cncf.io/blog/2023/10/chaos-engineering-in-kubernetes/
• LitmusChaos GitHub Repository: https://github.com/litmuschaos/litmus
• Building Resilient Systems with Chaos Engineering - O'Reilly Media: https://www.oreilly.com/library/view/chaos-engineering/9781492043850/
• Kubernetes Network Policies and Chaos: https://kubernetes.io/docs/concepts/services-networking/network-policies/