Módulo 7: Eks Specifics For Production
4. Autoscaling de nodos: Karpenter frente a Cluster Autoscaler
Descripción
En el Módulo 3, lección 7, instalaste metrics-server, resolviste la fricción del certificado autofirmado de kind, y viste un HorizontalPodAutoscaler reaccionar de verdad a carga real, subiendo y bajando el número de réplicas de andes-cargo-status-api. Ese mecanismo funcionó exactamente como se esperaba, ejecutado, con evidencia literal de kubectl get hpa -w. Pero hay una pregunta que ese módulo dejó, a propósito, sin responder, porque kind no tiene forma de responderla: ¿qué pasa cuando el HPA quiere crear más Pods, pero ya no hay espacio libre en ningún nodo existente? En kind, la respuesta es "esos Pods se quedan en Pending para siempre" — no hay ningún mecanismo que agregue un cuarto contenedor Docker como nodo nuevo. En EKS, esa pregunta la responde un componente completamente distinto del HPA, con un trabajo completamente distinto: autoscaling de nodos.
Conexión con el módulo
Esta lección exige que tengas fresca la distinción que ya construiste en el Módulo 3: un HorizontalPodAutoscaler observa métricas de Pods (CPU, memoria, u otras personalizadas) y decide cuántas réplicas debería haber — pero nunca crea ni destruye un nodo, porque no es su trabajo. Esta lección presenta el componente que sí lo hace, y por qué en 2026 la respuesta por defecto de AWS a esa pregunta tiene un nombre propio: Karpenter.
La distinción exacta: qué escala el HPA, qué escala esto
DOS BUCLES DE AUTOSCALING DISTINTOS, DOS PREGUNTAS DISTINTAS
HorizontalPodAutoscaler (Módulo 3, EJECUTADO en kind)
──────────────────────────────────────────────────────
Pregunta: "¿cuántas RÉPLICAS de este Deployment necesito
para la carga actual?"
Actúa sobre: spec.replicas del Deployment
Nunca toca: los nodos — asume que ya existen y tienen espacio
┌─────────────────────────────────────┐
│ Nodo A Nodo B Nodo C │
│ [Pod] [Pod] [Pod] [Pod] │ ◀── HPA sube/baja
│ │ CUÁNTOS Pods
└─────────────────────────────────────┘ hay, en nodos
que ya existen
Karpenter / Cluster Autoscaler (este módulo, representativo en EKS)
─────────────────────────────────────────────────────────────────
Pregunta: "¿hay algún Pod en Pending porque NINGÚN nodo
actual tiene espacio? ¿Sobra algún nodo vacío?"
Actúa sobre: el número de NODOS del clúster (instancias EC2)
Nunca decide: cuántas réplicas debería tener un Deployment
┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐
│Nodo A │ │Nodo B │ │Nodo C │ │Nodo D │ ◀── Karpenter
│ lleno │ │ lleno │ │ lleno │ │ NUEVO,│ lanza un
└───────┘ └───────┘ └───────┘ │creado │ nodo nuevo
│ahora │ cuando no
└───────┘ hay espacioNinguno de los dos mecanismos reemplaza al otro — se necesitan mutuamente, en cascada: el HPA decide que hacen falta más réplicas; si los nodos existentes no tienen espacio para programarlas, esas réplicas quedan Pending; eso es la señal que dispara a Karpenter (o a Cluster Autoscaler) para crear un nodo nuevo donde el scheduler sí pueda colocarlas. Sin autoscaling de nodos, un HPA que pide más réplicas de las que caben en tu capacidad actual se queda pidiendo algo que nunca va a llegar — exactamente lo que hubiera pasado si el Módulo 3 hubiera empujado la carga lo suficientemente alto en kind: los nodos de tu laptop tienen un límite físico real que ningún autoscaler puede resolver, porque no hay ninguna nube detrás para pedirle más.
Karpenter: el default de AWS en 2026
Karpenter es un cluster autoscaler de alto rendimiento, de código abierto, diseñado específicamente para lanzar cómputo just-in-time: en vez de trabajar con un grupo de instancias predefinido (como hace el enfoque más antiguo, ver más abajo), Karpenter observa directamente los Pods sin programar y decide, en el momento, qué tipo y tamaño exacto de instancia EC2 lanzar para que quepan — sin necesitar que un humano haya predefinido de antemano "este node group usa t3.medium".
La documentación oficial de AWS confirma que EKS Auto Mode, la forma más reciente de administración simplificada de cómputo para EKS, construye directamente sobre Karpenter — es la cita que fija esta lección, verificada contra docs.aws.amazon.com/eks:
"Amazon EKS Auto Mode automatically scales cluster compute resources. If a pod can't fit onto existing nodes, EKS Auto Mode creates a new one. EKS Auto Mode also consolidates workloads and deletes nodes. EKS Auto Mode builds upon Karpenter."
Esa última frase —"EKS Auto Mode builds upon Karpenter"— es la razón por la que esta lección llama a Karpenter "el default recomendado por AWS en 2026", sin exagerar: no es que AWS lo tolere como una alternativa de terceros, es que la forma más nueva y simplificada que AWS ofrece para administrar cómputo de EKS usa Karpenter por debajo, aunque envuelto en una capa adicional administrada.
La propia documentación de AWS es igual de precisa sobre el modelo de soporte cuando usas Karpenter directamente (sin pasar por EKS Auto Mode):
"Karpenter is open-source software which AWS customers are responsible for installing, configuring, and managing in their Kubernetes clusters. AWS provides technical support when Karpenter is run unmodified using a compatible version in Amazon EKS clusters. There is no AWS Service Level Agreement (SLA) for Karpenter."
Esta distinción importa: EKS Auto Mode (Karpenter, administrado por AWS, con soporte de AWS sobre la capa administrada) no es lo mismo que Karpenter autogestionado (tú lo instalas, tú lo mantienes actualizado, AWS te ayuda técnicamente pero sin SLA formal sobre el propio Karpenter). Los dos usan el mismo motor por debajo — la diferencia es, otra vez, quién administra el ciclo de vida.
Cómo decide Karpenter, en una frase con evidencia de fuente: "Karpenter launches right-sized compute resources (for example, Amazon EC2 instances) in response to changing application load in under a minute" — observa los requisitos exactos de cómputo, almacenamiento, aceleración (GPU) y programación de los Pods sin asignar, y lanza la instancia EC2 que mejor se ajusta, en vez de forzar todo a un tamaño de instancia fijo predefinido de antemano.
Con un NodePool de Karpenter (representativo) — la unidad de configuración con la que le dices a Karpenter qué tipos de instancia considerar:
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: andes-cargo-general
spec:
template:
spec:
requirements:
- key: karpenter.k8s.aws/instance-category
operator: In
values: ["t", "m"]
- key: kubernetes.io/arch
operator: In
values: ["amd64"]
nodeClassRef:
group: karpenter.k8s.aws
kind: EC2NodeClass
name: andes-cargo-nodeclass
limits:
cpu: 100Cluster Autoscaler: el enfoque anterior, todavía vigente por contraste
El Kubernetes Cluster Autoscaler es el mecanismo más antiguo de los dos, y AWS sigue documentándolo como una de las "Additional Solutions" soportadas junto a Karpenter — no está deprecado, pero la propia estructura de la documentación oficial lo posiciona después de Karpenter, no como el primer default. Su diferencia de fondo con Karpenter, en las palabras exactas de AWS:
"The Kubernetes Cluster Autoscaler automatically adjusts the number of nodes in your cluster when pods fail or are rescheduled onto other nodes. The Cluster Autoscaler uses Auto Scaling groups."
La frase clave: "uses Auto Scaling groups". Cluster Autoscaler no lanza instancias a medida, como Karpenter — trabaja sobre grupos de Auto Scaling que ya existen, con tamaños de instancia ya fijados de antemano, y su única palanca es subir o bajar el desiredCapacity de esos grupos. Si necesitas un tipo de instancia que ningún Auto Scaling Group existente contempla, Cluster Autoscaler no puede improvisar uno nuevo — Karpenter, en cambio, evalúa el requisito exacto de cada Pod sin programar y elige entre un catálogo mucho más amplio de tipos de instancia, sin necesitar un grupo predefinido para cada combinación posible.
¿Cuándo elige un equipo Cluster Autoscaler en 2026, sabiendo que Karpenter es el default recomendado? El caso citado con más consistencia por AWS y por la comunidad es multi-nube: Cluster Autoscaler tiene implementaciones para AWS, GCP, Azure y otros proveedores con una API común, mientras que Karpenter, en su forma nativa de AWS, está construido específicamente para el modelo de EC2 — un equipo que administra clústeres Kubernetes en más de un proveedor de nube, buscando un único mecanismo de operación consistente entre todos, puede preferir Cluster Autoscaler por esa portabilidad, aun renunciando a la velocidad y precisión de Karpenter dentro de AWS.
Tabla de contraste
| Karpenter | Cluster Autoscaler | |
|---|---|---|
| Cómo decide qué lanzar | Evalúa el Pod sin programar directamente, elige el tipo de instancia óptimo en el momento | Sube/baja el desiredCapacity de un Auto Scaling Group con tamaño ya fijado |
| Necesita un grupo de instancias predefinido | No | Sí — trabaja sobre Auto Scaling Groups existentes |
| Velocidad de reacción documentada | "in under a minute" | Depende del tiempo de reacción del propio Auto Scaling Group |
| Soporte de AWS | Sin SLA formal si es autogestionado; con soporte de AWS si corre vía EKS Auto Mode | Soportado como alternativa documentada, sin ser el default |
| Multi-nube | No — nativo de AWS/EC2 | Sí — implementaciones para múltiples proveedores |
| Relación con EKS Auto Mode | Es la base ("builds upon Karpenter") | No es parte de EKS Auto Mode |
Errores comunes
Pensar que Karpenter reemplaza al HorizontalPodAutoscaler, y que ya no hace falta el HPA en un clúster EKS real (de confusión de capas). Qué pasa: alguien, al aprender sobre Karpenter, asume que ya no necesita el HorizontalPodAutoscaler del Módulo 3 en producción. Cómo detectarlo: si tu plan de migración (el proyecto de este módulo, lección 8) elimina hpa.yaml del repositorio en vez de conservarlo. Cómo corregirlo: son mecanismos complementarios, no sustitutos — el HPA sigue decidiendo cuántas réplicas de andes-cargo-status-api necesitas; Karpenter solo entra en juego cuando esas réplicas no caben en el cómputo actual. Sin el HPA, Karpenter no tendría ninguna señal de "necesito más Pods" que reaccionar.
Asumir que Karpenter y EKS Auto Mode son sinónimos exactos (de vocabulario). Qué pasa: alguien usa "Karpenter" y "EKS Auto Mode" indistintamente, como si fueran el mismo producto con dos nombres. Cómo detectarlo: si describes EKS Auto Mode como "otro nombre de Karpenter" sin matices. Cómo corregirlo: la cita exacta de esta lección dice que EKS Auto Mode "builds upon Karpenter" — construye sobre él, no es idéntico a él. EKS Auto Mode agrega una capa administrada por AWS encima del motor de Karpenter (incluyendo, por ejemplo, gestión de AMI y actualizaciones que el Karpenter autogestionado no incluye por sí solo). Puedes usar Karpenter directamente, sin EKS Auto Mode, y sigue siendo Karpenter — solo que sin esa capa adicional administrada.
Elegir Cluster Autoscaler "porque es el más conocido", sin evaluar si el caso multi-nube aplica (de criterio de decisión). Qué pasa: alguien, familiarizado con Cluster Autoscaler de proyectos anteriores, lo elige por costumbre en un clúster EKS nuevo sin evaluar si Karpenter le convendría más. Cómo detectarlo: si tu justificación para elegir Cluster Autoscaler no menciona ningún requisito real de portabilidad entre nubes. Cómo corregirlo: dado que la propia AWS documenta a Karpenter como la base de su solución más nueva (EKS Auto Mode) y como el default recomendado, la pregunta correcta no es "¿cuál conozco?" sino "¿este clúster necesita portabilidad multi-nube real?" — si la respuesta es no, Karpenter es la elección que la evidencia de esta lección respalda.
Ejercicios
Ejercicio 1 — Traza el flujo completo, de carga a nodo nuevo. En tus propias palabras, describe la cadena completa de eventos, en orden, desde que sube el tráfico a andes-cargo-status-api hasta que aparece un nodo EC2 nuevo en el clúster — nombrando qué componente hace cada paso.
Ver solución
(1) Sube la CPU real de los Pods de andes-cargo-status-api, medida por metrics-server. (2) El HorizontalPodAutoscaler (Módulo 3) detecta que la utilización supera el objetivo configurado y aumenta spec.replicas del Deployment. (3) El kube-scheduler intenta programar los Pods nuevos, pero ningún nodo existente tiene espacio libre suficiente — esos Pods quedan en estado Pending. (4) Karpenter (o Cluster Autoscaler) detecta los Pods Pending sin ningún nodo compatible, y lanza una instancia EC2 nueva dimensionada para el requisito exacto de esos Pods. (5) El scheduler programa los Pods, ahora sí, en el nodo recién creado. Si tu respuesta identificó los cuatro componentes en ese orden (metrics-server → HPA → scheduler → Karpenter/Cluster Autoscaler), capturaste la cadena completa.
Ejercicio 2 — Explica "builds upon Karpenter" sin usar la palabra "construye". Un colega te pregunta qué significa exactamente que "EKS Auto Mode builds upon Karpenter". Explícaselo en una frase, sin usar la palabra "construye" ni "build".
Ver solución
Una explicación completa suena, más o menos, así: "El motor que decide qué instancia lanzar y cuándo, dentro de EKS Auto Mode, es Karpenter — AWS simplemente le agrega una capa administrada encima (gestión de AMI, actualizaciones, soporte formal) para que no tengas que instalarlo ni mantenerlo tú mismo." Si tu respuesta distinguió "el motor de decisión" de "la capa administrada que lo envuelve", capturaste la relación real entre ambos.
Ejercicio 3 — Predice el resultado si Karpenter necesita un tipo de instancia que un Auto Scaling Group de Cluster Autoscaler no contempla. Si un Pod sin programar requiere una instancia con GPU, y el clúster usa Cluster Autoscaler con Auto Scaling Groups configurados solo para instancias t3/m5 sin GPU, ¿qué pasaría? Compara con lo que haría Karpenter en el mismo escenario.
Ver solución
Con Cluster Autoscaler: el Pod se quedaría indefinidamente en Pending — Cluster Autoscaler solo puede subir el desiredCapacity de los Auto Scaling Groups que ya existen, y si ninguno de ellos ofrece instancias con GPU, no tiene forma de crear un grupo nuevo por sí solo; alguien tendría que crear manualmente un Auto Scaling Group nuevo con el tipo de instancia correcto. Con Karpenter: al evaluar directamente los requisitos del Pod sin programar (incluida la necesidad de GPU, uno de los criterios que la documentación de AWS menciona explícitamente que Karpenter considera), lanzaría una instancia con GPU compatible sin que nadie tuviera que predefinir ese tipo de instancia de antemano — la diferencia exacta entre "trabajar sobre grupos predefinidos" y "evaluar el requisito exacto en el momento" que esta lección explicó.
Resumen y siguiente paso
Esta lección distinguió, con evidencia y cita de fuente, dos bucles de autoscaling que resuelven preguntas completamente distintas: el HorizontalPodAutoscaler del Módulo 3 (ejecutado en kind) decide cuántas réplicas de un Deployment hacen falta, sobre nodos que ya existen; Karpenter y Cluster Autoscaler deciden cuántos nodos hacen falta, reaccionando a Pods que quedan Pending por falta de capacidad. Confirmaste, con la cita exacta de docs.aws.amazon.com/eks, que EKS Auto Mode "builds upon Karpenter" — el motor detrás de la forma más nueva y simplificada de administrar cómputo en EKS —, y contrastaste eso contra Cluster Autoscaler, el enfoque más antiguo, basado en Auto Scaling Groups predefinidos, vigente sobre todo para casos multi-nube.
Antes de avanzar deberías poder: explicar, sin confundirlos, qué escala el HPA y qué escala Karpenter/Cluster Autoscaler; citar la relación exacta entre EKS Auto Mode y Karpenter; y justificar cuándo un equipo real elegiría Cluster Autoscaler sobre Karpenter en 2026.
Siguiente lección: IRSA y su sucesor, EKS Pod Identity. Ahí vas a ver el mismo patrón OIDC que ya conoces de cicd-and-gitops-on-aws-guide y cloud-security-and-guardrails-guide, aplicado por primera vez a un Pod en vez de a un job de CI.
Recursos
- Amazon EKS — Scale cluster compute with Karpenter and Cluster Autoscaler — la fuente exacta de todas las citas de esta lección, incluida "EKS Auto Mode builds upon Karpenter".
- Karpenter — Documentation — documentación oficial del proyecto, referenciada directamente por AWS Docs.
- Cluster Autoscaler on AWS — la implementación de Cluster Autoscaler específica para AWS.
kubernetes-and-eks-in-production-guide(NIEVA), Módulo 3, lección 7 — elHorizontalPodAutoscalerejecutado enkind, el punto de comparación central de esta lección.