Fase 3: Desconexão em estado estável

Abra três terminais com os logs dos clients lado a lado.

Terminal 1 - LOCAL (Node1 → Node1):

kubectl logs -n demo-resilience deploy/client-hybrid -f

Terminal 2 - CROSS-NODE (Node1 → Node2):

kubectl logs -n demo-resilience deploy/client-hybrid-to-hybrid -f

Terminal 3 - CROSS-CLUSTER (Cloud → Node1):

kubectl logs -n demo-resilience deploy/client-cloud-to-hybrid -f

Os logs dos clients no hybrid node podem falhar via kubectl (control plane alcança o kubelet só pela VPN). Alternativa: SSH no node e ver via jornal do container, ou focar no client-cloud (kubelet cloud sempre acessível). Ver environment-status.

Iniciar a falha via FIS. O comando captura o EXPERIMENT_ID (usado no stop da Fase 5) e tem fallback para o ID do template caso o export da Fase 0 não tenha sido feito:

EXPERIMENT_ID=$(aws fis start-experiment \
  --experiment-template-id ${FIS_TEMPLATE_ID:-EXTCnS3KTdAc2AEME} \
  --region sa-east-1 --query 'experiment.id' --output text)
echo "FIS iniciado: $EXPERIMENT_ID"

Comportamento por tipo de endpoint EKS: se o kubelet alcança o endpoint PÚBLICO do cluster via internet (caso deste lab), o node PERMANECE Ready durante o FIS - a falha derruba apenas o data path (cross-cluster/VXLAN). Em ambientes com endpoint privado + Direct Connect (produção típica), o FIS derruba ambos os paths de uma vez.

Atenção - dois gatilhos independentes, não confundir na hora da demo

FIS = corta o data path. Cross-cluster (cloud→on-prem) e o ALB caem. NÃO deixa o node NotReady neste lab.
iptables da Fase 3b = corta o control plane. Node vira NotReady e as tolerations aparecem. NÃO derruba o data path.

Consequência prática: o ALB só fica fora do ar enquanto o FIS estiver ATIVO. Se o experimento expirou (duração de 1h) e você mostrar o ALB só com o iptables aplicado, ele responde 200 - e parece que a demo falhou. Confira o estado antes de mostrar:

aws fis get-experiment --id ${EXPERIMENT_ID} --region sa-east-1 --query 'experiment.state.status' --output text

Rodar os DOIS juntos = desconexão completa (control plane + data path), que é o cenário real de "o link com a AWS caiu".

Fase 3b: NotReady + Tolerations (2 nodes)

Para demonstrar os hybrid nodes NotReady SEM afetar a LAN local (não desconecte a NIC - isso mataria os paths locais), bloqueie o acesso do kubelet ao endpoint do EKS nos DOIS nodes. Assim o datacenter inteiro fica "perdido" para o control plane, que é o cenário real de "a AWS caiu para o DC".

Resolver os IPs do endpoint e guardar na variável (mudam - sempre re-resolver). A remoção das regras, na Fase 5 (Recovery), reutiliza a mesma variável:

export EKS_EP_IPS=$(dig +short $(aws eks describe-cluster --name llm-vmware-hybrid \
  --region sa-east-1 --query 'cluster.endpoint' --output text | sed 's|https://||') | grep -E '^[0-9]' | tr '\n' ' ')
echo "IPs do endpoint: $EKS_EP_IPS"

Criar as regras de bloqueio nos dois nodes de uma vez. O loop externo percorre os nodes (literais, seguro no zsh) e o loop dos IPs roda NO node (o bash do node faz o split), então funciona igual seja o seu shell zsh ou bash:

for node in 192.168.3.51 192.168.3.52; do
  ssh -i ~/.ssh/id_ecdsa lopbruno@$node "for ip in $EKS_EP_IPS; do sudo iptables -I OUTPUT -d \$ip -j DROP; done"
done

Alternativa: logar em cada node e criar as regras por dentro

Logue no node:

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

Já no node, criar as regras - um comando para cada IP que o resolve retornou (repita no .52):

sudo iptables -I OUTPUT -d <IP-DO-ENDPOINT> -j DROP

Acompanhar os dois virarem NotReady:

watch -n5 'kubectl get nodes -l eks.amazonaws.com/compute-type=hybrid'

Resultado esperado: AMBOS os hybrid nodes NotReady em ~60s, taint unreachable

Unknown directive

Line 87: Unknown text directive “NoExecute”

aplicado, pods continuam Running (tolerations). E o mais forte: a comunicação CROSS-NODE (Node1 para Node2) continua 200 - o mesh VXLAN on-prem não depende do control plane. O DC inteiro opera autônomo.

A remoção destas regras é um passo explícito da Fase 5 (Recovery) - o ambiente permanece desconectado pelas próximas fases de teste.

Nota (dúvida comum)

NÃO dá para alterar Tolerations durante a desconexão - é campo do pod spec, exige o kube-apiserver (inalcançável offline). A janela de sobrevivência (tolerationSeconds) tem que ser definida ANTES.

Já o TTL/GC de imagem do containerd é config LOCAL do node, então esse SIM pode ser alterado via SSH + restart do containerd mesmo offline.

Regra: objeto da API = imutável offline; config local do node = mutável offline. Ref: https://docs.aws.amazon.com/eks/latest/best-practices/hybrid-nodes-kubernetes-pod-failover.html