Node group do EKS não escala sozinho

O que aconteceu

Depois de migrar o n8n (staging e produção) para o cluster EKS compartilhado, várias réplicas de worker e webhook ficaram presas em Pending com a mensagem Insufficient cpu/memory e 0/1 nodes are available. O cluster tinha um único nó t3.medium e nunca crescia, mesmo com o node group configurado para min=1 e max=3.

Causa raiz

Um managed node group do EKS não escala sozinho. Definir min_nodes e max_nodes apenas informa os limites — quem realmente ajusta a capacidade desejada (adicionando ou removendo nós) precisa ser um controlador rodando dentro do cluster: o Cluster Autoscaler ou o Karpenter. Sem esse controlador, o desired_size fica travado no valor inicial (min), então pods que não cabem no nó existente ficam Pending para sempre.

Correção

Instalamos o Cluster Autoscaler via Helm no cluster EKS, usando IRSA (OIDC) para as permissões de IAM da service account. Para isso foi criado o provider OIDC do cluster, uma role IAM federada à service account cluster-autoscaler do namespace kube-system, e as tags de autodescoberta (k8s.io/cluster-autoscaler/enabled e k8s.io/cluster-autoscaler/<cluster>) diretamente no Auto Scaling Group — porque o EKS não propaga essas tags do node group para o ASG automaticamente.

Optou-se por IRSA em vez do atalho de anexar permissões à role do nó porque o Karpenter (autoscaler pretendido no futuro) exige OIDC/IRSA de qualquer forma. Fazendo agora, o provider OIDC já fica pronto e a futura migração para Karpenter é só trocar a role e o release Helm.

Como evitar

  • Ao criar um novo cluster EKS que precise escalar, lembre que definir min/max no node group não basta — é obrigatório instalar Cluster Autoscaler ou Karpenter.
  • As tags k8s.io/cluster-autoscaler/* precisam estar no ASG, não só no node group — o EKS não as propaga.
  • Prefira IRSA (OIDC) desde o início para permissões de controladores no cluster; deixa o caminho aberto para Karpenter sem recriar o provider OIDC.