EKS Hybrid Nodes - Resiliência
Cada fase tem um objetivo, os comandos e o resultado esperado. Execute comando a comando e acompanhe a saída - o próprio passo elucida o comportamento. Não use o validador automatizado aqui.
Pré-requisito: ambiente já preparado e validado pela Parte 1. Tenha o ALB DNS e o FIS_TEMPLATE_ID à mão.
| # | Cenário | Método de falha | Prova |
|---|---|---|---|
| 1 | Desconexão em estado estável | FIS (disrupt-connectivity) | Pods existentes continuam; node NotReady; tolerations impedem eviction |
| 1b | Comunicação multi-node on-prem | FIS (mesmo do 1) | Node1→Node2 continua funcionando |
| 2 | Desconexão durante provisioning | FIS + kubectl scale | Pods novos ficam Pending; existentes intactos |
| 3a | LB Região → Hybrid Nodes | ALB + curl | Tráfego externo alcança pods on-prem |
| 3b | Hybrid Nodes → Externo | exec + curl | Pods on-prem acessam APIs externas |
| 3c | LB On-Premises (MetalLB VIP) | curl ao VIP | Entrada local independente da AWS |
| 4 | Restart de node DURANTE desconexão | vCenter restart | Pods não voltam até reconectar; réplicas multi-node salvam |
Componentes envolvidos no comportamento de failover de pods durante desconexões (fonte: EKS Best Practices - Pod Failover ).