Prefix Delegation e Limites de Pods no EKS

Uma coisa que estranhei ao usar o EKS pela primeira vez foi que alguns Pods simplesmente paravam de funcionar ou ficavam em Pending, mesmo quando o Node tinha CPU e memória de sobra. Em outras plataformas, isso não costuma acontecer. A partir dessa observação, ficou claro que entender “capacidade” no EKS exige olhar além das métricas tradicionais.

Acontece que a capacidade do Node depende da quantidade de IPs que a instância (do EC2) pode receber da VPC. Se os IPs acabam, os Pods param, mesmo que o resto dos recursos esteja disponível.

Entendendo o limite

No EKS, cada Pod consome um IP da VPC, e cada instância tem um limite fixo de IPs disponíveis pelas suas ENIs.

Para confirmar, você pode olhar o Allocatable:

kubectl describe nodes | grep -i pods:

Se o número parecer baixo demais para o Node escolhido, geralmente é isso.

Prefix Delegation

Prefix Delegation surge então como solução para esta dependência de IP individual. Em vez de solicitar IP por IP, o CNI passa a solicitar blocos, como um /28. Isso dá ao Node uma margem maior sem precisar subir para tipos de instância mais caros só por conta desta questão.

Para configurar, rode os comandos

aws eks update-addon \
  --cluster-name <cluster> \
  --addon-name vpc-cni \
  --resolve-conflicts PRESERVE

E depois:

kubectl set env daemonset aws-node \
  -n kube-system ENABLE_PREFIX_DELEGATION=true

Os Pods do aws-node reiniciam, e o cluster passa a operar no modo de prefixo.

Conclusão

No fim, prefix delegation não muda o Kubernetes. Ele só altera como o EKS gerencia IPs. Isso costuma ser suficiente para permitir Nodes menores, com densidade maior, e um cluster mais previsível.

No geral, o benefício real é evitar aquela situação-problema apontado no inicio do texto. Com prefix delegation, a capacidade passa a refletir melhor o que o Node realmente consegue entregar.