Amazon EKS incorpora EFA y grupos de colocación en Auto Mode y Karpenter

Introducción

La combinación de Amazon EKS con instancias EC2 de alto rendimiento y redes de baja latencia siempre tuvo un punto ciego: la configuración de la interfaz de red y la distribución física de las instancias quedaba relegada a pasos manuales o scripts externos. Hasta ahora, los equipos que necesitaban ejecutar cargas de trabajo como entrenamiento distribuido de modelos de ML o procesamiento paralelo de datos con latencia crítica debían elegir entre dos males: o sacrificaban ancho de banda con interfaces ENI estándar, o perdían flexibilidad al configurar manualmente interfaces EFA y grupos de colocación. Eso cambió con la actualización que AWS liberó en julio de 2026, que extiende EKS Auto Mode y Karpenter para soportar nativamente ambas capacidades.

El cambio no es cosmético. Según datos internos de AWS citados en la nota de lanzamiento, los nodos EKS que usan EFA en lugar de ENI estándar pueden lograr hasta un 40% más de throughput en transferencias de datos entre instancias dentro de un mismo AZ, mientras que los grupos de colocación reducen la probabilidad de fallos en cascada en clústeres con más de 100 nodos hasta en un 65%. La novedad es que estas optimizaciones ya no requieren configuraciones personalizadas en CloudFormation o Terraform, sino que se aplican directamente desde la definición del node pool en EKS Auto Mode o en las provisioners de Karpenter.

Qué ocurrió

AWS anunció soporte nativo para dos configuraciones previamente excluyentes:

1. Interfaz EFA en nodos EKS: Ahora es posible definir en el node pool de EKS Auto Mode o en la provisioner de Karpenter si una instancia EC2 usa una interfaz EFA exclusiva o una ENI estándar, incluso en instancias ya existentes. La interfaz EFA no consume direcciones IP del VPC, lo que simplifica la gestión de subredes para cargas de trabajo con alta densidad de conexiones.

1. Grupos de colocación en nodos EKS: Se agregó soporte para lanzar instancias EC2 directamente en grupos de colocación de tipo cluster, spread o partition desde la configuración del node pool. Esto permite controlar la distribución física de las instancias sin recurrir a scripts externos ni a la API de EC2.

Ambas funciones están disponibles desde la versión 1.32 de EKS (lanzada en julio de 2026) y son compatibles con instancias EC2 de las familias C6i, C7i, G5, Inf2, P5 y Trn2. La implementación usa la API de EKS Auto Mode y la librería karpenter-core versión 0.36.0, que ahora expone nuevos campos en el CRD EC2NodeClass y en la configuración de NodePool.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps y SRE

La integración elimina el overhead de mantener scripts personalizados para configurar EFA y grupos de colocación. Antes, un equipo que quería lanzar un clúster de entrenamiento distribuido con EFA debía:

• Crear un Launch Template con la interfaz EFA configurada.
• Asociar ese template a un ASG o a una provisioner de Karpenter.
• Asegurar que la subred tuviera suficiente capacidad de IPs para las ENIs estándar.

Ahora, basta con definir en el node pool de EKS Auto Mode:

apiVersion: eks.aws.crossplane.io/v1alpha1
kind: NodePool
spec:
  forProvider:
    clusterName: ml-cluster
    nodeClass:
      instanceType: p5.48xlarge
      amiFamily: AmazonLinux2023
      subnetSelector:
        aws-ids: subnet-123456,subnet-789012
      efa:
        enabled: true
        interfaceType: efaOnly
    placementGroup:
      strategy: cluster
      partitionCount: 3

Con esto, Karpenter lanza instancias directamente en el grupo de colocación cluster y configura la interfaz EFA sin intervención manual. Según benchmarks de AWS, el tiempo de aprovisionamiento de un nodo con EFA se reduce de 7 minutos a menos de 2 minutos en clústeres con 50 nodos.

Para equipos de Cloud

La novedad impacta en los costos de operación. Antes, usar EFA requería reservar IPs públicas o privadas en subredes con capacidad adicional, lo que aumentaba el costo por nodo hasta en un 15%. Con la nueva integración, las interfaces EFA no consumen IPs, lo que permite consolidar más nodos por subred sin incrementar el cost per hour. AWS estima un ahorro del 8-12% en entornos de ML con alta densidad de conexiones.

Además, la distribución física controlada mediante grupos de colocación reduce la necesidad de reiniciar nodos por fallos de hardware. En un caso de uso documentado por un cliente en us-east-1, la migración a grupos de colocación spread redujo los reinicios no planificados en un 40% en un clúster de 200 nodos.

Para equipos de Seguridad

La seguridad lateral mejora al poder aislar nodos críticos en grupos de colocación partition. Por ejemplo, se puede asignar un grupo de colocación partition por equipo (ML, backend, batch), limitando el blast radius de un fallo de hardware o de red. La interfaz EFA, al no exponer direcciones IP, reduce la superficie de ataque para escaneos internos no autorizados.

Sin embargo, hay que considerar que EFA requiere la versión 2.13.0 o superior del AWS VPC CNI plugin para EKS. Equipos que usen versiones antiguas (como 1.12.x) deberán actualizar antes de habilitar EFA, ya que versiones anteriores no soportan la configuración dinámica de interfaces.

Detalles técnicos

Soporte de EFA en EKS Auto Mode y Karpenter

• Versiones mínimas:

– Karpenter: 0.36.0 (con el CRD EC2NodeClass extendido).

– AWS VPC CNI: 2.13.0.

• Tipos de instancias soportadas:

• Configuración de interfaz:

– efaAndStandardENI: Usa EFA como principal y ENI estándar como secundaria.

• Impacto en ancho de banda:

– Latencia reducida en un 30% en transferencias entre nodos del mismo AZ, según pruebas internas de AWS.

Soporte de grupos de colocación en EKS Auto Mode y Karpenter

• Estrategias soportadas:

– spread: Distribuye instancias en racks diferentes.

– partition: Crea grupos lógicos con aislamiento de fallos.

• Comando para verificar el grupo de colocación de un nodo:

  aws ec2 describe-instances \
    --instance-ids $(kubectl get nodes -o jsonpath='{.items[*].spec.providerID}' | \
      sed 's/.*\///' ) \
    --query 'Reservations[*].Instances[*].Placement.GroupName' \
    --output text
  

• Limitaciones:

– No se puede mezclar estrategias en un mismo node pool.

Requisitos previos

1. Subredes con capacidad:

1. IAM Roles:

1. Actualizaciones críticas:

Qué deberían hacer los administradores y equipos técnicos

1. Actualizar los componentes críticos

# Actualizar el addon de EKS Auto Mode
aws eks update-addon \
  --cluster-name production-cluster \
  --addon-name karpenter \
  --addon-version v0.36.0-eksbuild.1 \
  --resolve-conflicts OVERWRITE

# Verificar versión
aws eks describe-addon \
  --cluster-name production-cluster \
  --addon-name karpenter \
  --query 'addon.addonVersion' \
  --output text

kubectl apply -f https://github.com/aws/karpenter/releases/download/v0.36.0/karpenter.yaml

2. Configurar el node pool con EFA y grupos de colocación

Ejemplo para un clúster de ML con nodos P5 y EFA exclusiva en un grupo de colocación cluster:

apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: ml-high-performance
spec:
  template:
    spec:
      requirements:
      - key: kubernetes.io/arch
        operator: In
        values: ["amd64"]
      nodeClassRef:
        name: default
  limits:
    cpu: 1000
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: 30s
---
apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiFamily: AmazonLinux2023
  instanceSelector:
    families: [p5]
  subnetSelector:
    karpenter.sh/discovery: production-cluster
  securityGroupSelector:
    karpenter.sh/discovery: production-cluster
  efa:
    enabled: true
    interfaceType: efaOnly
  placementGroup:
    strategy: cluster
    partitionCount: 2

3. Validar la configuración

kubectl get nodes -o wide | grep -E "p5|efa"

kubectl get nodes -o jsonpath='{.items[*].metadata.annotations.eks\.amazonaws\.com/placement-group}' | jq -r '.[]'

# Desde un pod en un nodo con EFA
kubectl run iperf3-server --image=networkstatic/iperf3 -- -s
kubectl run iperf3-client --image=networkstatic/iperf3 -- -c <IP-del-server> -t 30 -P 16

4. Monitorear y ajustar

Habilitar métricas de EFA en Prometheus:

- job_name: 'efa-metrics'
  scrape_interval: 15s
  static_configs:
  - targets: ['efa-exporter.default.svc.cluster.local:9090']

• efa_tx_bytes_total y efa_rx_bytes_total (throughput).
• efa_errors_total (pérdidas de paquetes).
• placement_group_health (estado del grupo de colocación).

5. Consideraciones de migración

Si ya tienes nodos con EFA configurados manualmente:

1. Crea un node pool nuevo con las nuevas funciones.
2. Mueve las cargas de trabajo con cordon/drain.
3. Elimina el node pool antiguo.

NODES=$(kubectl get nodes -l karpenter.sh/provisioner-name=old-pool -o name)
for NODE in $NODES; do
  kubectl cordon $NODE
  kubectl drain $NODE --ignore-daemonsets --delete-emptydir-data --timeout=300s
done

Conclusión

La incorporación de soporte nativo a EFA y grupos de colocación en EKS Auto Mode y Karpenter marca un antes y después para equipos que operan cargas de trabajo de alto rendimiento en Kubernetes. La capacidad de configurar interfaces EFA sin consumir IPs y de distribuir físicamente las instancias con grupos de colocación elimina capas de complejidad que antes requerían scripts personalizados o herramientas externas.

Para equipos de DevOps, esto significa menos toil y más tiempo para optimizar las cargas de trabajo. Para los de Cloud, implica ahorros directos en IPs y mejoras en disponibilidad. Y para Seguridad, ofrece un modelo de aislamiento más robusto sin sacrificar rendimiento.

La transición es directa, pero requiere actualizar componentes críticos (EKS Auto Mode, Karpenter y VPC CNI) y validar la configuración antes de migrar cargas de trabajo críticas. Quienes adopten estas funciones en los próximos meses no solo ganarán en rendimiento, sino también en consistencia operativa: todo queda definido en la misma API de Kubernetes que ya usan para escalar sus clústeres.