Fase 2: Testes de LB - happy path

2a. Região → Hybrid Nodes (Ingress via ALB)

ALB=$(kubectl get ingress demo-ingress -n demo-resilience \
  -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
curl -s "http://${ALB}/" | jq '{hostname, message}'

O que acontece: tráfego da internet → ALB (região) → Gateway → VXLAN → pod on-prem.

2b. Hybrid Nodes → Externo (Egress)

O teste de egress roda melhor via crictl exec no próprio node: kubectl exec em pods de hybrid node é instável (passa pelo API server -> kubelet:10250 pela VPN). E use um endpoint confiável - checkip.amazonaws.com (AWS-owned) em vez do httpbin.org, que retorna 503 com frequência.

Primeiro, logue no node 1:

ssh -i ~/.ssh/id_ecdsa lopbruno@192.168.3.51

Já no node, rode o teste de egress:

CID=$(sudo crictl ps --name podinfo -q | head -1)
sudo crictl exec $CID curl -s https://checkip.amazonaws.com

Resultado esperado: o IP público de egress do datacenter. Mostra que o pod on-prem sai para a internet pelo caminho do próprio DC, não pela AWS.

2c. LB On-Premises (MetalLB VIP)

O VIP local (192.168.3.240) é o papel que o F5 exerce no design de produção do cliente:

# Da LAN on-prem (ou do próprio node):
curl -s http://192.168.3.240/ | jq '{hostname, message}'