EKS Auto Mode: correr Kubernetes sin andar peleando con los nodos

Si algo aprendí gestionando EKS en producción, es que mantener los nodos se lleva más tiempo del que uno imagina. Managed node groups, Karpenter, el EBS CSI driver, actualizar AMIs, y el clásico "¿por qué este pod lleva 10 minutos en Pending?" a la hora menos pensada. No es lo más entretenido del rol, pero es parte de lo que nos toca hacer para mantener un cluster sano en producción.

Por eso, cuando probé EKS Auto Mode, me hice esta pregunta: "si dejo que AWS haga todo esto por mí, ¿qué gano y qué pierdo?". Este artículo es esa respuesta, con un laboratorio que puedes seguir tú mismo en menos de 30 minutos.

---

Mantener nodos es casi un segundo trabajo

Antes de vender la solución, hablemos del problema de verdad. En un EKS "clásico", tú te encargas de un montón de cosas:

• Crear y dimensionar los node groups. ¿m5.large? ¿c6i.xlarge? ¿Spot u On-Demand? Cada decisión te la cobra el futuro.
• Instalar y afinar un autoscaler. Cluster Autoscaler o Karpenter. Los dos piden configuración, permisos IAM y mantenimiento.
• Cuidar los add-ons. CoreDNS, kube-proxy, EBS CSI, VPC CNI... instalarlos, versionarlos, actualizarlos.
• Parchear las AMIs. Cada vez que aparece una vulnerabilidad de seguridad en el sistema operativo del nodo (CVE), es nuestro trabajo subsanarlo.
• Debuggear el scheduling. Ese 0/3 nodes are available: Insufficient memory que aparece justo cuando ya te ibas a desconectar.

Lo irónico es que nada de eso hace tu producto mejor. Es puro "impuesto de plataforma". Trabajo que haces para que Kubernetes exista, no para que tu app sea mejor.

Entonces, ¿Qué es EKS Auto Mode?

AWS se hace cargo del cómputo, el almacenamiento y el networking del cluster por ti. Por dentro usa Karpenter y nodos con Bottlerocket, pero todo eso queda tras bambalinas. Tú ya no administras node groups ni instalas add-ons uno por uno.

Tú declaras tus apps, AWS decide y levanta la infraestructura para correrlas. Los nodos aparecen cuando tus pods los necesitan, y se van cuando ya no.

Lab: de cero a app corriendo, con nodos que aparecen solos

Lo que necesitas:

• AWS CLI v2 configurado (aws configure)
• eksctl v0.195.0 o más
• kubectl
• Permisos IAM sobre EC2, EKS, IAM y VPC

Paso 1: Crear el cluster con Auto Mode

eksctl create cluster \
  --name demo-automode \
  --region us-east-1 \
  --enable-auto-mode

Ese único comando te crea el cluster, la VPC, las subredes, activa Auto Mode y deja los add-ons esenciales gestionados por AWS. Tarda aproximadamente unos 15 minutos.

Paso 2: Mirar el cluster recién creado

kubectl get nodes

kubectl get nodepools

Auto Mode crea dos node pools automáticamente:

• system arranca con 1 nodo desde el inicio. Ese nodo corre los componentes internos del propio cluster (CoreDNS y los add-ons gestionados). Por eso kubectl get nodes sí te muestra un nodo apenas creas el cluster.
• general-purpose arranca con 0 nodos. Este es el pool donde van a caer tus aplicaciones, y ahí es donde se ve la magia: se queda vacío hasta que despliegas algo que necesite cómputo.

Así que el cambio de chip es este: ver el pool de tus cargas en cero no significa que algo se rompió. Significa que todavía no hay nada tuyo que correr, y AWS no está cobrándote nodos de más.

Paso 3: Desplegar una app

# nginx-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-demo
  template:
    metadata:
      labels:
        app: nginx-demo
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        resources:
          requests:
            cpu: "250m"
            memory: "128Mi"
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-demo
spec:
  type: LoadBalancer
  selector:
    app: nginx-demo
  ports:
  - port: 80
    targetPort: 80

kubectl apply -f nginx-demo.yaml

Paso 4: Ver Auto Mode en acción

kubectl get nodes

En unos 30 segundos vas a ver aparecer un nodo nuevo en el pool general-purpose (ese que estaba en cero) sin que tú lo hayas pedido. AWS se dio cuenta de que tus pods necesitan cómputo y levantó una instancia EC2 solo.

Paso 5: Escalar y mirar qué pasa

kubectl scale deployment nginx-demo --replicas=10
kubectl get nodes

Al escalar en numero de replicas de nuestra app, tener un solo nodo será insuficiente. Si la capacidad de ahora no alcanza, Auto Mode levanta más. No tocaste ningún autoscaler, no editaste ningún node group.

Paso 6: Destruir

eksctl delete cluster --name demo-automode --region us-east-1

Es super importante que al finalizar nuestro laboratorio destruymos todos los recursos creado, para evitar costos innecesarios. Un cluster olvidado es una sorpresa fea en la factura.

---

Clásico vs Auto Mode

Qué	EKS clásico	EKS Auto Mode
Gestión de nodos	Manual / tu propio Karpenter	AWS
Add-ons (CoreDNS, CSI, etc.)	Los instalas y versionas tú	Gestionados
Actualizar AMIs	Lo gestionas tú	AWS
Autoscaling	Configuras CA o Karpenter	Automático
Tu tiempo operando	Mucho	Poco
Personalización	Total	Acotada
Curva de arranque	Empinada	Suave

---

Cuándo usarlo y cuándo no (Según mi opinión)

Úsalo si:

• Arrancas un cluster nuevo y quieres velocidad sin construir toda una plataforma.
• Tu equipo es chico y no quieres tener a alguien dedicado a cuidar nodos.
• Tus workloads son bastante estándar: APIs, workers, web.

Piénsalo dos veces si:

• Dependes de configuraciones muy específicas de nodo (kernels custom, DaemonSets exigentes, GPUs con drivers a medida).
• Ya tienes un Karpenter afinado que te ahorra dinero y no lo quieres soltar.
• Necesitas control total del ciclo de vida de la AMI por temas de compliance.

Auto Mode te cambia control por simplicidad. Ganas horas de operación, cedes algunos grados de personalización. Para la mayoría, ese cambio vale muchísimo la pena. Para casos muy puntuales, todavía no.

¿Y cuánto me va a costar?

Auto Mode suma un pequeño cargo de gestión encima del costo del EC2 que corre por debajo. Pero no te quedes solo con "cuánto cuesta el add-on". La cuenta real es: cuánto cuesta el add-on menos las horas de ingeniería que dejas de gastar cuidando nodos, autoscalers y parches. Cuando sumas ese tiempo, el número se ve muy distinto.

En conclusión

EKS Auto Mode no es magia. Es AWS haciendo el trabajo de plataforma que muchos veníamos haciendo a mano. Si gestionas clusters en producción, pruébalo con un workload que no sea crítico y mide cuánto tiempo dejas de invertir en cosas que no hacen mejor tu producto.