<h2>O que é Chaos Engineering e por que é Crítico em Kubernetes</h2>
<p>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.</p>
<p>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.</p>
<h3>O Impacto no Negócio</h3>
<p>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.</p>
<h2>Introdução ao LitmusChaos: Arquitetura e Conceitos</h2>
<p>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.</p>
<p>A arquitetura do LitmusChaos é elegante e segue os princípios nativos de Kubernetes. No centro está o conceito de <strong>ChaosEngine</strong>, 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 <strong>ChaosOperator</strong> monitora esses manifests e coordena a execução através de <strong>Chaos Runners</strong> — jobs temporários que executam a lógica de injeção de falha. Após a execução, um <strong>ChaosResult</strong> registra os detalhes do experimento: sucesso, falha, duração e métricas coletadas.</p>
<h3>Componentes Principais</h3>
<p><strong>ChaosEngine</strong>: Define o experimento — qual tipo de caos executar, contra quais recursos e com quais parâmetros. É como um manifesto Deployment, mas para o caos. <strong>ChaosExperiment</strong>: 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. <strong>ChaosResult</strong>: 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.</p>
<h2>Instalação e Configuração Prática</h2>
<p>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.</p>
<pre><code class="language-bash"># 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</code></pre>
<p>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.</p>
<pre><code class="language-bash"># 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</code></pre>
<h3>Verificação da Instalação</h3>
<pre><code class="language-bash"># Listar todos os CRDs de caos disponíveis
kubectl get crds | grep chaos
Listar todos os experimentos disponíveis
kubectl get chaosexperiments -n litmus</code></pre>
<h2>Criando e Executando Seu Primeiro Experimento</h2>
<p>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.</p>
<h3>Preparação: Deployar uma Aplicação de Teste</h3>
<pre><code class="language-yaml"># 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</code></pre>
<p>Aplique isso no seu cluster:</p>
<pre><code class="language-bash">kubectl apply -f app-deployment.yaml
kubectl get pods -n default | grep backend-api</code></pre>
<p>Você deve ver 3 pods rodando. Agora vamos injetar caos matando um deles.</p>
<h3>Criando um ChaosEngine para Pod Kill</h3>
<pre><code class="language-yaml"># 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'</code></pre>
<p>Agora você precisa criar o Service Account que o caos usará:</p>
<pre><code class="language-yaml"># 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</code></pre>
<p>Aplique os manifests:</p>
<pre><code class="language-bash">kubectl apply -f chaos-rbac.yaml
kubectl apply -f chaos-kill-pod.yaml</code></pre>
<h3>Monitorando a Execução</h3>
<pre><code class="language-bash"># 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</code></pre>
<p>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.</p>
<h2>Testes Avançados: Injeção de Latência de Rede</h2>
<p>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.</p>
<pre><code class="language-yaml"># 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: []</code></pre>
<p>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.</p>
<h2>Usando Probes para Validação Automática</h2>
<p>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 <strong>Probes</strong> — testes pequenos e específicos executados durante o caos.</p>
<pre><code class="language-yaml"># 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</code></pre>
<p>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.</p>
<h2>Integrando Chaos Engineering no Pipeline CI/CD</h2>
<p>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:</p>
<pre><code class="language-yaml"># .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</code></pre>
<p>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.</p>
<h2>Métricas e Observabilidade</h2>
<p>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.</p>
<pre><code class="language-bash"># 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</code></pre>
<p>As métricas importantes são:</p>
<ul>
<li><strong>litmuschaos_experiment_verdict</strong>: 1 se passou, 0 se falhou</li>
<li><strong>litmuschaos_experiment_duration_seconds</strong>: Quanto tempo o experimento levou</li>
<li><strong>litmuschaos_experiment_injected_chaos_total</strong>: Contador de quantas falhas foram injetadas</li>
</ul>
<p>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.</p>
<h2>Conclusão</h2>
<p>Chaos Engineering em Kubernetes através do LitmusChaos oferece três ganhos principais. <strong>Primeiro</strong>, você descobre falhas antes de seus usuários descobrirem. Em vez de reactive firefighting em produção, você é proativo durante o desenvolvimento. <strong>Segundo</strong>, 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. <strong>Terceiro</strong>, 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.</p>
<h2>Referências</h2>
<ul>
<li><strong>LitmusChaos Official Documentation</strong>: https://docs.litmuschaos.io/</li>
<li><strong>Kubernetes Chaos Engineering Best Practices</strong>: https://www.cncf.io/blog/2023/10/chaos-engineering-in-kubernetes/</li>
<li><strong>LitmusChaos GitHub Repository</strong>: https://github.com/litmuschaos/litmus</li>
<li><strong>Building Resilient Systems with Chaos Engineering</strong> - O'Reilly Media: https://www.oreilly.com/library/view/chaos-engineering/9781492043850/</li>
<li><strong>Kubernetes Network Policies and Chaos</strong>: https://kubernetes.io/docs/concepts/services-networking/network-policies/</li>
</ul>
<p><!-- FIM --></p>