Llevábamos tiempo queriendo dedicarle un rato a EKS Auto Mode, pero entre proyectos, eventos y vacaciones no conseguíamos encontrar ese hueco. Hoy lo hemos encontrado.
Y es que una de las conversaciones recurrentes con compañeros, clientes y jefes es precisamente cómo la tecnología está evolucionando para automatizar capas de infraestructura que antes requerían expertise y horas de configuración.
Nuestra respuesta es siempre la misma: la tecnología no elimina el conocimiento. Donde antes necesitabas configurar Karpenter, gestionar AMIs, parchear nodos y mantener add-ons... ahora puedes focalizarte en arquitectura, seguridad y en construir cosas que aporten valor de otra manera.
¿Qué es EKS Auto Mode?
Podríamos explicarlo de muchas maneras pero ya nos conocéis, nos gusta ser directos:
AWS gestiona por ti el autoscaling de nodos (con Karpenter), networking de pods, load balancing, DNS, almacenamiento EBS, parches del SO y rotación de nodos. Tú te centras en tus cargas de trabajo.
¿Qué ventajas nos da esto?
- AWS gestiona los add-ons core. No los ves, no los tocas, no los parcheas.
- Karpenter gestionado por AWS, sin instalación ni configuración.
- NodePools y NodeClasses disponibles para tener flexibilidad sobre tus nodos.
- Optimización de costes gracias a la consolidación automática de Karpenter.
¡Al lio!
Para el test hemos utilizado el módulo oficial de la community eks-auto-mode, modificando la llamada para adaptarla a este caso. Lo importante del módulo es que con "compute_config.enabled = true" activamos Auto Mode completo.
Parece broma pero sí.🥶Es así de fácil.🥶
¿Qué crea Auto Mode automáticamente?
Una vez desplegado el cluster, veamos como se gestiona Karpenter:
kubectl get nodeclass
NAME ROLE READY AGE
default awtwins-cluster-eks-auto-20260322210213399200000003 True 55m
kubectl get nodepools
NAME NODECLASS NODES READY AGE
general-purpose default 0 True 56m
Auto Mode crea automáticamente el NodeClass y el NodePool correspondiente.
Puedes añadir configuración extra de almacenamiento, restricciones de instancias, límites de capacidad o tags.
El test de autoscaling
Para validar que todo funciona usamos el deployment de pause que usa AWS en sus ejemplos oficiales de Karpenter y que ya hemos utilizado anteriormente. No hace nada, solo consume recursos.
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate
spec:
replicas: 5
selector:
matchLabels:
app: inflate
template:
metadata:
labels:
app: inflate
spec:
containers:
- name: inflate
image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
resources:
requests:
cpu: "1"
memory: "1Gi"
Aplicamos el manifest y vemos que tenemos los pods creandose correctamente:
Vamos a EC2 mediante la consola y podremos ver como Karpenter está creando el nodo necesario para desplegar este tipo de carga.
Para validar que el desescalado también funciona sin problema procedemos a escalar el deployment a 0 replicas:
kubectl scale deployment inflate --replicas=0
El resultado habla por sí solo: nodos provisionados en segundos, pods corriendo, y consolidación automática al bajar la carga. Sin tocar nada más.
En este post solo estamos validando el autoscaling, pero el mismo principio aplica para todo lo que mencionamos antes como load balancing, networking, DNS, almacenamiento, parches de nodos... Todo eso se gestiona por AWS sin que tengas que instalar, configurar ni actualizar nada. Como ya sabéis, somos muy fans de Karpenter, pero la gracia de Auto Mode es que Karpenter es solo una pieza de todo lo que te quitas de encima.
Adjuntamos una imagen descriptiva como comparación:
¿Cuánto cuesta?
El modelo de precios de EKS Auto Mode tiene tres componentes importantes:
- Precio del cluster igual que en EKS estándar.
- Precio de las EC2 desplegadas.
- Precio de Auto Mode, aprox un 12% extra sobre el coste de cada instancia.
Nuestra opinión
Como hemos hablado de estos temas en diferentes foros con muchos compañeros, llega el momento más esperado...🥁
EKS Auto Mode no es solo una feature más. Es un cambio en cómo operar Kubernetes en AWS. Pasamos de gestionar un cluster a consumirlo. Y eso, bien entendido, desgasta menos y minimiza problemas.
Además, como ya vimos en nuestro anterior post de awtwins, si le sumamos features como ArgoCD Capability la vida nos vuelve a sonreír con un cluster magnífico con mucha menos gestión que antes. Los que ya nos conocéis sabéis que para nosotros este tipo de soluciones siempre son un SÍ... si lo puedes pagar, claro💰😄
Como siempre, esperamos vuestros comentarios y feedback👇


Top comments (0)