Fundamentos de Resiliência no Amazon EKS: Como projetar workloads tolerantes a falhas em produção

Source: Dev.to

🎯 1. O que é Resiliência no Contexto de Kubernetes e EKS?

Resiliência é a capacidade de um sistema:

• continuar operando mesmo diante de falhas
• recuperar‑se automaticamente
• degradar de maneira controlada
• manter confiabilidade e disponibilidade

No Kubernetes/EKS, isso se traduz em:

• multi‑AZ
• autoscaling
• readiness e liveness probes
• limites de recursos
• rollouts seguros
• automação de autoscaling da infraestrutura

Resiliência não significa não falhar, mas falhar com graça.

🏗️ 2. Arquitetura Multi‑AZ e Auto‑Healing

O EKS simplifica a criação de clusters distribuídos por múltiplas zonas de disponibilidade, reduzindo drasticamente o risco de interrupção.

Por que isso é importante?

• Uma AZ pode falhar → seus Pods continuam funcionando em outras.

Interrupções de nós são automaticamente tratadas via:

• Managed Node Groups auto‑recovery
• Auto‑healing do Kubernetes

Boas práticas

• Usar 2 ou 3 AZs no cluster.
• Preferir Managed Node Groups ou EKS Auto Mode.
  (Tenho um artigo falando mais sobre o EKS Auto Mode)
• Configurar Pod Anti‑Affinity para distribuir Pods entre nós/AZs.

🔧 3. Probes: Garantindo Saúde da Aplicação

Liveness Probe

Detecta travamentos. Se falhar → Kubernetes reinicia o Pod.

Readiness Probe

Define quando o Pod está pronto para receber tráfego.

Startup Probe

Evita falsos positivos de liveness em aplicações lentas para iniciar.

Boas práticas

• Sempre definir healthchecks adequados.
• Nunca usar a mesma URL para readiness e liveness.
• Ajustar tempos: initialDelay, timeout, period.

📦 4. Requests, Limits e QoS

Grande parte dos incidentes em clusters vem de uso incorreto de recursos, como:

• consumo excessivo de memória
• uso intensivo de CPU
• OOMKills
• throttling

Requests

Quantidade mínima necessária.

Limits

Máximo permitido para o Pod.

QoS

• Guaranteed
• Burstable
• BestEffort

Boas práticas

• Sempre definir requests e limits.
• Monitorar OOMKills e throttling.
• Avaliar Vertical Pod Autoscaler em clusters maduros.

📈 5. Autoscaling: HPA, Karpenter e EKS Auto Mode

Resiliência também envolve adaptação automática.

HPA (Horizontal Pod Autoscaler)

Escala Pods com base em:

• CPU
• Memória
• Latência
• Métricas customizadas (Prometheus)

Infraestrutura: Karpenter ou EKS Auto Mode

• Karpenter provê provisionamento inteligente.
• EKS Auto Mode leva isso ao próximo nível:
  • Provisionamento automático baseado nos Pods
  • Multi‑AZ
  • Zero configuração de node groups
  • Alta resiliência + redução de custo

Boas práticas

• Usar HPA + Auto Mode/Karpenter.
• Configurar Pod Disruption Budgets.
• Garantir readiness antes de receber tráfego.

🔄 6. Implantação Resiliente: Rolling, Blue/Green e Canary

Rolling Update

Atualização gradual sem downtime.

Blue/Green

Versão nova só recebe tráfego quando validada.

Canary

Tráfego gradual para nova versão baseado em métricas.

Ferramentas recomendadas

• Argo Rollouts
• AWS App Mesh
• NGINX Ingress Controller

Boas práticas

• Evitar breaking changes.
• Usar feature flags.
• Monitorar cada etapa do rollout.

🧪 7. Testes de Resiliência: Caos, Carga e Funcionais

Chaos Engineering

Ferramentas: ChaosMesh, LitmusChaos, AWS Fault Injection Simulator

Cenários comuns: falha de nó, falha de Pod, perda de rede, latência artificial.

Testes de Carga

K6, Locust, Artillery

Testes Funcionais

Robot Framework, Postman/Newman, Cypress (front)

Por que isso importa?
Revela gargalos, comportamentos inesperados e falta de tolerância a falhas.

📊 8. Observabilidade para Resiliência

Sem visibilidade, não há resiliência.

Métricas

Prometheus, CloudWatch, OpenTelemetry

Logs

Fluent Bit, CloudWatch Logs, OpenSearch

Traces

X‑Ray, Jaeger, Tempo (Grafana)

Boas práticas

• Criar métricas de SLO (latência, erros).
• Dashboards dedicados para Pods, Nodes, Deployments.
• Alertas automáticos com CloudWatch ou Alertmanager.

🛣️ 9. Padrões Fundamentais para Resiliência no Kubernetes

• Pod Disruption Budget (PDB)
• Pod Affinity/Anti‑Affinity
• Topology Spread Constraints
• Retry + Exponential Backoff
• Circuit Breaker
• Idempotência
• Timeouts bem definidos

Esses padrões evitam:

• cascatas de falhas
• saturação de recursos
• degradação global do serviço

🎯 10. Conclusão

O EKS fornece uma base robusta, mas a resiliência depende de:

• padrões arquiteturais
• práticas operacionais
• observabilidade
• testes contínuos
• cultura DevOps
• automação inteligente

Ao aplicar esses fundamentos, você obtém aplicações que:

• toleram falhas
• escalam automaticamente
• recuperam‑se sem intervenção humana
• entregam confiabilidade em produção

Resiliência é uma disciplina, não uma configuração.