DEV Community

Cover image for VPC CNI en EKS: cómo dejar de pagar nodos que no usás
AWS Community Builders profile image Lucas Blanco
Lucas Blanco for AWS Community Builders

Posted on

VPC CNI en EKS: cómo dejar de pagar nodos que no usás

#networking #devops #aws #kubernetes

Si alguna vez miraste un nodo de EKS y viste algo como esto:

CPU:    18%
Memory: 22%
Pods:   29/29 ← 😐
Enter fullscreen mode Exit fullscreen mode

ya viviste el problema del que va este post. Tus nodos tienen recursos para utilizar pero no podes schedulear más pods en ellos...

La buena noticia: hay una configuración llamada Prefix Delegation en AWS VPC CNI que amplia este techo, y bien configurada te puede bajar la factura de EC2 hasta un 75% sin tocar una sola línea de código de la app.

Vamos por partes.

Cómo funciona el networking de un nodo de EKS

Un nodo de EKS es una instancia EC2. A esa EC2 se le atachan Elastic Network Interfaces (ENIs), que son las placas de red virtuales. Cada ENI tiene:

  • 1 IP primaria (la del nodo en esa ENI)
  • N IPs secundarias (las que se asignan a los pods)

VPC Architecture

El encargado de entregar IPs

El plugin Amazon VPC CNI (que corre como un DaemonSet llamado aws-node en cada nodo) es el encargado de pedirle IPs a EC2 y dárselas a los pods cuando arrancan. Cada pod recibe una IP real y ruteable de la VPC, no una IP virtual dentro de EKS. Lo cual es la causa del problema: el número de pods queda atado a cuántas IPs aguanta la instancia.

Para saber cuantos pods pueden schedulearse en un nodo puede usarse la siguiente formula:

MaxPods x Nodo = ENIs × (IPs_por_ENI − 1) + 2
Enter fullscreen mode Exit fullscreen mode

donde:

  • ENIs: cuántas placas virtuales atacha la instancia
  • IPs_por_ENI − 1: descontamos la IP primaria
  • + 2: dos pods con hostNetwork: true que no consumen IP de pod (típicamente kube-proxy y aws-node)

Los límites de ENIs e IPs por instancia están en la doc oficial de tipos de instancia EC2. Aplicada a la familia M5:

Instancia vCPUs RAM ENIs IPs/ENI Max Pods
m5.large 2 8 GiB 3 10 29
m5.xlarge 4 16 GiB 4 15 58
m5.2xlarge 8 32 GiB 4 15 58
m5.4xlarge 16 64 GiB 8 30 234
m5.8xlarge 32 128 GiB 8 30 234
m5.16xlarge 64 256 GiB 15 50 737

Veamos un ejemplo

Analizando la m5.large: 29 pods. Con 2 vCPU y 8 GiB de RAM, si tus pods piden 100m CPU y 256 MiB de RAM (apis simples), la cuenta da:

  • Por CPU: 2000m / 100m = 20 pods (sin overhead).
  • Por RAM: 8192 MiB / 256 MiB = 32 pods.
  • Por red: 29 pods.

Y restando los pods de sistema (kube-proxy, aws-node, csi-drivers, coredns en algunos nodos), te quedan unos 24 slots útiles. Estás pagando 2 vCPUs y 8 GiB de RAM para correr aplicaciones que apenas usan la mitad del nodo.

Si además estás utilizando escalado automático, tu controller al ver que no entran más pods, levanta otro nodo igual. Y otro. Y otro.

Así aumentan los costos de nuestras EC2.

La solución: Prefix Delegation

Este AWS VPC CNI plugin que analizamos anteriormente puede configurarse en otro modo de funcionamiento (Prefix Delegation).
En este modo, en lugar de pedirle a la EC2 una IP a la vez, el CNI puede pedirle prefijos /28. Es decir, bloques contiguos de 16 IPs. Cada "slot" de la ENI pasa de ser 1 IP a ser 16 IPs.

Entonces, a partir de este cambio tenemos una fórmula nueva:

MaxPods = ENIs × ((IPs_por_ENI − 1) × 16) + 2
Enter fullscreen mode Exit fullscreen mode

Para la misma m5.large ahora tendriamos: 3 × (9 × 16) + 2 = 434 pods teóricos.

Pero esto es más teórico que real. Debajo lo analizamos mejor.

Cómo se activa

Es una variable de entorno en el addon vpc-cni:

{
  "env": {
    "ENABLE_PREFIX_DELEGATION": "true",
    "WARM_PREFIX_TARGET": "1"
  }
}
Enter fullscreen mode Exit fullscreen mode

Y kubelet?

Acá viene la trampa. Activar Prefix Delegation no es suficiente — hay que decirle al kubelet de cada nodo que use el límite nuevo (no lo detecta solo). Si no, vas a tener IPs disponibles pero Kubernetes va a seguir rechazando pods con un mensaje de error: "Too many pods, 0/N nodes are available".

Para configurarlo:

Si usas Karpenter

Karpenter por default usa --use-max-pods=false y un cap de 110 pods, pero no lo ajusta por instancia automáticamente. Hay que decirle explícitamente en el NodePool:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    expireAfter: Never
  limits:
    cpu: "50"
  template:
    spec:
      kubelet:
        maxPods: 110     # 👈 el cambio
Enter fullscreen mode Exit fullscreen mode

¿Por qué Karpenter no lo hace solo? Porque el script max-pods-calculator.sh de AWS sigue usando la fórmula vieja (Secondary IP) y no entiende Prefix Delegation. Karpenter prefiere dejarte un default conservador y que vos decidas. Info en la doc de Karpenter NodeClass.

Con Managed Node Groups

Hay que ajustar el bootstrap script:

/etc/eks/bootstrap.sh my-cluster \
  --use-max-pods false \
  --kubelet-extra-args '--max-pods=110'
Enter fullscreen mode Exit fullscreen mode

La recomendación/limitación propia de Kubernetes

Antes de poner el resultado de la nueva tabla, hay que tener en cuenta el siguiente thresholds de kubernetes:

min(110, 10*#cores)
Enter fullscreen mode Exit fullscreen mode

La regla, validada por kubernetes, asegura que el promedio de procesos por core quede en un rango que el scheduler del kernel maneje bien.

Entonces el nuevo calculo para pods por EC2 es el siguiente:

maxPods_real = min(kubelet_maxPods, EKS_cap, CNI_formula, 10 × cores)
Enter fullscreen mode Exit fullscreen mode

Para una m5.large entonces con PD: min(110, 250, 434, 20) = 20. Pero ahora tenemos menos. En este caso conviene dejar en: 110.

Referencia: Kubernetes Scalability Thresholds (SIG Scalability).

EC2 vs Pods - Prefix Mod

Ahora revisando nuevamente las EC2:

Instancia vCPUs RAM ENIs IPs/ENI Max Pods (sin PD) Max Pods (con PD)
m5.large 2 8 GiB 3 10 29 110
m5.xlarge 4 16 GiB 4 15 58 110
m5.2xlarge 8 32 GiB 4 15 58 110
m5.4xlarge 16 64 GiB 8 30 234 110
m5.8xlarge 32 128 GiB 8 30 234 250
m5.12xlarge 48 192 GiB 8 30 234 250
m5.16xlarge 64 256 GiB 15 50 737 250
m5.24xlarge 96 384 GiB 15 50 737 250

Cuándo Prefix Delegation NO es la respuesta

Hay casos donde no ganás nada o incluso te complica la vida:

  • Pods grandes (>1 vCPU, >2 GiB de RAM): el cuello ya es CPU/RAM, no IPs. Activar PD no cambia nada.
  • VPC con subnets chicas: un /28 reserva 16 IPs aunque uses 1. Con 10 nodos pidiendo 2 prefijos al boot, eso son 320 IPs apenas el cluster arranca. Una subnet /24 (251 IPs usables) se queda corta. Recomendación: subnets /20 o más grandes para clusters con PD.
  • Instancias no-Nitro: no es compatible. Solo Nitro (m5, c5, r5+, t3, m6i, etc.).
  • Subnets fragmentadas: si la subnet ya tiene muchas IPs sueltas dispersas, EC2 puede no encontrar un /28 contiguo.

La regla práctica: PD es palanca para instancias chicas con pods chicos. Para instancias grandes con pods pesados, el problema ya es otro.

Pensando en costos:

Caso de analisis: cluster con ~200 pods de microservicios livianos (100m CPU / 256 MiB RAM cada uno).

Sin Prefix Delegation, con m5.large:

  • 24 pods de app por nodo (descontando 5 de sistema)
  • 200 / 24 = 9 nodos
  • 9 × US$ 0.096/h × 730 h = US$ 631/mes

Con Prefix Delegation, con m5.xlarge y maxPods=110:

  • ~104 pods de app por nodo
  • 200 / 104 = 2 nodos
  • 2 × US$ 0.192/h × 730 h = US$ 280/mes

Ahorro: ~55% sobre el costo de cómputo, siendo conservador. Se pueden disminuir más los costos usando instancias SPOT.

Conclusión

El networking de EKS tiene un techo que es invisible hasta que se analizan los costos. Prefix Delegation no es un cambio gigante, es una variable de entorno que te baja el costo de cómputo en ciertos casos de usos.

Material de referencia

Este post nace de mi charla en AWS Community Day Argentina 2025. Si tenés dudas sobre cómo aplicar esto a tu cluster contactame en /in/blanco-lucas.

Top comments (0)