Descomissionar o cluster Kubernetes da DigitalOcean

TLDR: Depois de confirmar que todos os workloads rodam no EKS, destruir o cluster Kubernetes compartilhado da DigitalOcean e remover o stack do repo — hoje ele só existe como rollback do cutover do gateway.

Contexto

Os workloads compartilhados migraram para o EKS (gateway completo ponta a ponta; n8n do marketing no EKS). O cluster shared-kubernetes da DigitalOcean continua running, mantido de propósito como rollback durante o cutover do gateway. Assim que o time tiver confiança, ele é puro custo sem tráfego.

O repo ainda carrega src/shared/kubernetes/digitalocean/ e o state correspondente.

Objetivos

  • Cluster e seus load balancers e volumes destruídos.
  • src/shared/kubernetes/digitalocean/ removido do repo — o stack AWS já é o canônico.
  • Nenhum recurso órfão continuando a gerar custo.

Fora de escopo

Mudanças

Pré-checagens (obrigatórias antes do destroy)

  • Nenhum DNS oficial apontando para o IP do ingress do cluster antigo — os CNAMEs do gateway já estão no NLB; confirmar que nenhum outro projeto resolve para lá.
  • Nenhum remote_state de projeto lendo a chave de state do cluster antigo.

Destroy

  • Destruir o stack src/shared/kubernetes/digitalocean — cluster, node pools e os load balancers que ele possui. O LB do ingress-nginx e os volumes do CSI vão junto; verificar sobra com doctl compute load-balancer list e doctl compute volume list.
  • Remover os volumes de block storage deixados por PVCs antigos de redis (o redis do gateway foi para EBS no EKS).

Limpeza do repo

  • Apagar src/shared/kubernetes/digitalocean/terraform/ e todo script ou target de make exclusivo dele.
  • Remover o objeto de state do bucket depois do destroy.

Como verificar

  • doctl kubernetes cluster list → nenhum shared-kubernetes.
  • doctl compute load-balancer list e volume list → nenhuma sobra de gateway ou k8s.
  • Todos os apps continuam saudáveis no EKS.

Documentação

— (não registrado na spec original)

⚠️ Ponto sem volta: isto elimina a possibilidade de rollback do gateway. Só executar depois de a aplicação estar validada em produção no EKS por tempo suficiente.

Ordem: o build para ECR tem que estar feito antes — sem ele um redeploy não produz imagem que o EKS consiga puxar.

Credencial: o token usado no destroy precisa de escopo de compute. O token do ward é escopado em registry/spaces; usar um token de operador ou o console.