F.A.Q

E storage persistente? Nossos workloads stateful?

Stateful funciona em Hybrid Nodes - o que não funciona é EBS (preso à AZ, e o EBS CSI não está na lista de add-ons compatíveis). Opções locais:

hostPath - simples, preso ao node (é como o sample oficial de GPU burst persiste modelos LLM localmente)
local PersistentVolumes com nodeAffinity
CSI de terceiros - Longhorn, Ceph, OpenEBS, ou o CSI do storage array do próprio DC
FSx CSI está na lista de compatíveis, mas é storage de rede dependente da região (falha na desconexão)

Ação: validar com o time de storage do cliente qual CSI o array deles oferece. Ref: add-ons compatíveis .

Como fica a observabilidade DURANTE a desconexão? Ficamos cegos?

Métricas/logs para CloudWatch/AMP param de fluir durante o disconnect (dependência regional). Mitigações:

Backend local secundário: Prometheus on-prem + ADOT com dual-exporter (é o que a Fase 7 demonstra)
crictl para troubleshooting local sem control plane
Do lado AWS: alarme CloudWatch em NodeNotReady (control plane logs) detecta a desconexão

Ref: best practices - network disconnections .

Pod que CRASHA durante a desconexão reinicia?

Sim - diferente do restart de node (Cenário 4). O kubelet gerencia o restartPolicy localmente, sem API server, desde que a imagem esteja no cache do containerd. Pré-requisitos em produção:

Pre-pull das imagens críticas em todos os nodes
GC do containerd com discard_unpacked_layers=false (não descartar imagens)

E se a desconexão durar mais de 12 horas?

Os pods continuam rodando independente de credencial expirada - ela afeta só a comunicação node↔AWS, não o workload local. Sobre as credenciais:

SSM Hybrid Activation: credencial de 1h; para de renovar offline (reconexão pode levar até 30min de backoff - systemctl restart do agent força)
IAM Roles Anywhere: até 12h configurável, reconexão em segundos

Para janelas longas: IRA com durationSeconds alto. Ref: host credentials .

Nosso IDP usa admission webhooks (policy engines). O que acontece?

Gotcha de produção importante: se um webhook backend roda nos hybrid nodes e o DC desconecta, o API server não o alcança.

Com failurePolicy: Fail, isso bloqueia operações no cluster INTEIRO (não só on-prem)
Recomendações: rodar webhooks críticos em nodes cloud, ou usar failurePolicy: Ignore + réplicas nos dois lados
Ação: revisar os webhooks da plataforma (Kyverno/OPA/Gatekeeper) sob esse critério

E o cloud bursting?

Demonstrado na Fase 6 (overflow) e evoluível para Karpenter + Spot disparado por KEDA/Prometheus. Nota: bursting depende da conectividade com a região - é complementar à resiliência (um usa a nuvem quando ela está lá, o outro sobrevive quando não está).

O DNS não vira ponto único de falha no disconnect?

Vira, se o CoreDNS rodar só na nuvem - foi um achado deste lab (Fase 4b - DNS Resiliency):

Nomes internos (*.svc.cluster.local): exigem CoreDNS. Fix validado: CoreDNS em cada node + internalTrafficPolicy: Local (pré-baked). O internalTrafficPolicy: Local é o ponto crítico - faz cada pod usar o CoreDNS do próprio node. Topology hints não são confiáveis em cluster pequeno; com Cilium, NodeLocal DNSCache exige Local Redirect Policy (camada de cache opcional)
Nomes públicos: o data plane do Route 53 é global (SLA 100%) - mas se o DC resolve via Resolver endpoint na VPC (regional, via link privado), o caminho morre com o disconnect. Resolver local no DC para nomes públicos
O CoreDNS local serve do cache mesmo sem API server - nomes existentes resolvem offline

Dois datacenters: um cluster único ou um por DC?

Recomendação: um cluster por DC (blast radius menor, upgrades independentes, menor latência). Se optarem por cluster único com nodes nos dois DCs:

Zone labels obrigatórias (topology.kubernetes.io/zone por DC) - o Kubernetes cancela evictions quando uma zona INTEIRA fica unreachable, protegendo cada DC
Requisito de rede: até 200ms RTT e 100Mbps+ por DC