Introdução

A engenharia de caos é uma prática disciplinada de experimentar falhas controladas em sistemas distribuídos para aumentar a confiança de que eles suportarão condições adversas em produção. Em arquiteturas cloud-native orquestradas pelo Kubernetes, essa abordagem deixa de ser opcional e torna-se um mecanismo essencial de validação contínua da resiliência.

Este artigo apresenta um roteiro prático para adotar engenharia de caos em clusters Kubernetes, cobrindo desde a escolha de ferramentas e o desenho de experimentos até a integração em pipelines de entrega contínua.

Por que o Kubernetes precisa de engenharia de caos?

O Kubernetes abstrai máquinas, redes e armazenamento, mas introduz uma camada adicional de complexidade distribuída. Componentes falham de forma independente, atualizações ocorrem em paralelo e a comunicação entre serviços depende de uma topologia de rede dinâmica. Sem testes sistemáticos de falha, problemas só são descobertos em produção, quando o impacto é maior.

Cenários típicos de falha

• Perda repentina de um nó de trabalho e reagendamento imediato de Pods
• Particionamento de rede entre zonas de disponibilidade
• Latência elevada ou indisponibilidade transitória de volumes persistentes
• Exaustão de recursos provocando eviction de contêineres
• Leitura de ConfigMaps ou Secrets desatualizados após rollback

Passos para implementar engenharia de caos

1. Preparação do ambiente e escolha de ferramentas

Recomenda-se isolar os experimentos em um namespace dedicado, com limites de RBAC e políticas de rede restritas. Para a execução, as principais opções são:

• Chaos Mesh: plataforma nativa de Kubernetes com suporte a falhas de Pod, rede, E/S, CPU e memória
• Litmus: framework declarativo com catálogo de experimentos prontos e fácil integração com GitOps
• kube-monkey: implementação do Chaos Monkey para terminação aleatória de Pods

Exemplo de instalação do Chaos Mesh via Helm, usando um namespace próprio para os experimentos:

helm repo add chaos-mesh https://charts.chaos-mesh.org
helm repo update

helm install controle-caos chaos-mesh/chaos-mesh \
  --namespace=lab-caos \
  --create-namespace \
  --set dashboard.create=true \
  --set timezone=America/Sao_Paulo

2. Definição do estado estacionário e da hipótese

Antes de injetar qualquer falha, é preciso estabilizar um conjunto mínimo de sinais que indiquem saúde. A partir daí, formula-se uma hipótese testável.

1. Estado estacionário: a latência média da API de pagamentos deve permanecer abaixo de 200 ms com taxa de erro menor que 0,1%
2. Hipótese: mesmo com a remoção de 50% dos Pods da camada de catálogo, o balanceamento interno mantém o SLA
3. Cenário: deleção súbita de metade das réplicas do serviço de catálogo
4. Execução: aplicação do experimento via Chaos Mesh e observação dos indicadores
5. Verificação: comparação das métricas antes, durante e após a injeção de falha

3. Exemplo de experimento de falha em Pod

O manifesto a seguir elimina metade dos Pods da aplicação de pagamento durante 30 segundos. O gracePeriod: 0 simula uma parada abrupta, sem tempo de desligamento gracioso.

apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: falha-pod-pagamento
  namespace: lab-caos
spec:
  action: pod-kill
  mode: fixed-percent
  value: "50"
  duration: 30s
  gracePeriod: 0
  selector:
    namespaces:
      - pagamentos
    labelSelectors:
      component: api-pagamento
      version: v1

4. Exemplo de experimento de latência de rede

Para simular congestão no cache, o experimento a seguir adiciona atraso de 150 ms com variação de 30 ms em tráfego destinado aos Pods do Redis.

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: latencia-redis
  namespace: lab-caos
spec:
  action: delay
  mode: all
  direction: to
  selector:
    namespaces:
      - carrinho
    labelSelectors:
      tier: cache
      app: redis
  delay:
    latency: "150ms"
    jitter: "30ms"
    correlation: "50"

5. Exemplo de carga excessiva de CPU

Além de falhas de disponibilidade e rede, é importante validar como o serviço se comporta sob pressão computacional. O manifesto abaixo aplica 80% de carga em dois núcleos dos Pods do serviço de catálogo.

apiVersion: chaos-mesh.org/v1alpha1
kind: StressChaos
metadata:
  name: estresse-cpu-catalogo
  namespace: lab-caos
spec:
  mode: all
  duration: 60s
  selector:
    namespaces:
      - catalogo
    labelSelectors:
      app: servico-catalogo
  stressors:
    cpu:
      workers: 2
      load: 80

Integração contínua e práticas avançadas

Pipeline automatizada de caos

Incorporar experimentos em um pipeline de CI/CD permite detectar regressões de resiliência a cada mudança de código. Um fluxo recomendado é:

1. Implantar a nova versão da aplicação em um ambiente de homologação
2. Executar experimentos pré-definidos: perda de Pod, partição de rede e pressão de recursos
3. Coletar métricas de latência, taxa de erro e tempo de recuperação
4. Prosseguir para produção apenas se todos os indicadores estiverem dentro dos limites aceitáveis

Segurança em produção

• Escalonamento gradual: iniciar por serviços não críticos e expandir para componentes centrais apenas após maturidade
• Blast radius contido: usar selectors precisos e namespaces isolados para limitar o impacto
• Recuperação automática: garantir liveness probes, pod disruption budgets e políticas de reinício configuradas
• Observabilidade: correlacionar eventos de caos com traces, logs e métricas para reduzir o tempo de diagnóstico

Comparação entre ferramentas

Indicadores para medir a maturidade da resiliência

Para que a engenharia de caos evolua de experimentos isolados para uma cultura organizacional, é importante acompanhar métricas como:

• MTTR (Mean Time To Recovery): tempo médio até a recuperação do serviço
• Taxa de detecção: percentual de falhas identificadas antes do impacto no usuário
• Cobertura de cenários: proporção de componentes críticos cobertos por experimentos
• Tempo de indisponibilidade planejada versus não planejada: redução de inicdentes inesperados

Adotar esses indicadores transforma a engenharia de caos em uma prática mensurável, capaz de guiar investimentos em arquitetura e operações.