Fase 6: Cloud Bursting - overflow do DC para a AWS

Cenário complementar (não é resiliência, é elasticidade): a app da plataforma roda no DATACENTER e, sob pico de carga, transborda para a AWS. Simples e realista - sem GPU/LLM, apenas scheduling nativo do Kubernetes.

Este cenário DEPENDE da conectividade com a AWS (oposto da resiliência). Bursting e resiliência são complementares: um usa a nuvem quando ela está lá, o outro sobrevive quando ela não está.

Estado normal: app roda no DC

kubectl apply -f manifests/08-cloud-bursting.yaml
kubectl get pods -n demo-resilience -l app=burst-app -o wide

As 2 réplicas ficam no hybrid node (nodeAffinity preferred para on-prem).

Pico de carga: burst para a AWS

# Simula o pico escalando a app
kubectl scale deploy burst-app -n demo-resilience --replicas=12
sleep 30
# Ver a distribuição: hybrid enche, o excedente vai pros cloud nodes
kubectl get pods -n demo-resilience -l app=burst-app -o wide \
  --no-headers | awk '{print $7}' | sort | uniq -c

Para ver pod a pod (agrupado por node - mi-* = on-prem, ip-* = cloud), saída compacta que cabe em terminal com split:

kubectl get pods -n demo-resilience -l app=burst-app \
  -o custom-columns='POD:.metadata.name,NODE:.spec.nodeName' \
  --sort-by=.spec.nodeName

Resultado validado: ~7 pods permanecem no DC (hybrid), ~3 transbordam para os cloud nodes da AWS. O overflow é automático - preferred affinity, não required: o scheduler prefere on-prem, mas usa a nuvem quando o DC enche.

Na prática: a carga normal roda no datacenter, com o custo e a latência do hardware já existente. Num pico - Black Friday, campanha - a capacidade transborda para a AWS automaticamente, sem reconfigurar nada. Elasticidade sob demanda mantendo o baseline no DC.

Dica k9s: em :pods filtrado em demo-resilience, pressione w para exibir a coluna NODE. Ao escalar o burst-app, veja os pods nascendo e se espalhando: a maioria nos hybrid nodes e o excedente nos cloud nodes. Bursting visível pod a pod.

Fim do pico: consolidação de volta ao DC

kubectl scale deploy burst-app -n demo-resilience --replicas=2

Nuance importante: o scale-down remove pods mas NÃO move os sobreviventes de volta - a affinity só age no scheduling. Para consolidar ativamente no DC use kubectl rollout restart deploy/burst-app (recria os pods, que voltam pro hybrid por preferência) ou o Descheduler em produção. Validado: pós rollout restart, 100% de volta ao hybrid.

Evolução em produção

Este demo usa cloud nodes já existentes (overflow). Em produção, para provisionar capacidade cloud SOB DEMANDA e destruir depois: Karpenter + Spot disparado por KEDA/Prometheus monitorando a carga local. É a mesma estratégia do sample oficial aws-samples/sample-eks-hybrid-nodes-gpu-burst-scaling, aplicável a workloads web (não só LLM). Pode ser uma demo dedicada.