Cluster Autoscaler vs Karpenter: cuándo usar cada uno en Kubernetes (2026)

Tus pods están en estado Pending. Tu ingeniero de guardia está recibiendo alertas. En algún punto de la cadena entre «necesito más cómputo» y «el cómputo está disponible», algo va demasiado lento. Ese algo casi siempre es el aprovisionamiento de nodos — y la herramienta que elegiste para gestionarlo determina si ese retraso son 4 minutos o 45 segundos.

El autoescalado de nodos en Kubernetes es de esas decisiones de infraestructura que parecen sencillas hasta que las tienes corriendo en producción. Dos pods en estado Pending no significan solo un despliegue retrasado: significan picos de latencia, tráfico perdido, SLOs incumplidos e ingenieros depurando problemas que deberían haber sido invisibles. A escala, también significa quemar dinero en nodos sobreaprovisionados o jugársela con un submínimo de recursos en el peor momento posible.

Cluster Autoscaler (CA) ha sido la respuesta por defecto durante años. Karpenter emergió de AWS en 2021, alcanzó estado estable en 2023 y para 2025 ya era la recomendación mayoritaria para clusters nativos en AWS. En 2026, ambas herramientas están maduras, ampliamente desplegadas y son genuinamente buenas — pero resuelven el problema de forma diferente, y elegir la incorrecta para tu entorno tiene consecuencias reales.

Este artículo es una comparativa técnica en profundidad sobre autoescalado de nodos Kubernetes. Asume que ya sabes lo que es Kubernetes y que tienes criterio sobre infraestructura. El objetivo es darte una imagen clara de cómo funciona cada herramienta, dónde gana cada una, y un framework de decisión que puedas aplicar directamente.

Por qué el autoescalado de nodos es difícil

La tensión fundamental en el autoescalado es esta: quieres tener cómputo disponible antes de necesitarlo, pero no quieres pagar por cómputo que no estás usando. Estos objetivos están en conflicto directo, y todo sistema de autoescalado es un intento de encontrar el trade-off menos malo.

Sin autoescalado, estás haciendo una de estas dos cosas:

1. Sobreaprovisionando — ejecutas suficientes nodos para gestionar la carga pico en todo momento. La utilización media se sitúa en el 20–30%, y estás pagando el otro 70–80% para que esté ocioso.
2. Subaprovisionando — vas ajustado, y cuando el tráfico se dispara, los pods van a Pending. Tus SLOs se incumplen. Te llaman a las 3 de la mañana para escalar manualmente.

Un patrón de fallo habitual con un autoescalado mal ajustado es el de «estampida en el scale-up»: el HPA crea nuevos pods más rápido de lo que el autoescalado de nodos puede aprovisionar capacidad. La ventana de aprovisionamiento importa. Con CA y node groups respaldados por ASG en AWS, estás hablando de 4–8 minutos. Con Karpenter, 60–90 segundos. A 100 RPS y una ventana de 3 minutos, eso son 18.000 peticiones bajo condiciones degradadas.

Cluster Autoscaler: cómo funciona realmente

Cluster Autoscaler es un proyecto nativo de Kubernetes bajo el repositorio kubernetes/autoscaler, en producción desde 2016, con soporte para AWS, GCP, Azure, Alibaba, DigitalOcean y otros proveedores.

El modelo de node groups

CA opera sobre node groups — ASGs en AWS, MIGs en GCP, VMSSs en Azure. La función de CA es decidir cuándo aumentar o reducir la capacidad deseada de estos grupos. CA no aprovisiona nodos individuales. Escala node groups, y es el propio node group quien aprovisiona los nodos. Esta indirección añade latencia y reduce la flexibilidad.

Scale-up: detección de pods no programables

CA ejecuta un bucle de control (intervalo de escaneo por defecto: 10 segundos). Para cada pod en estado Pending con PodScheduled=False, CA simula añadir un nodo de cada tipo de node group conocido y comprueba si el pod podría programarse. Cuando se selecciona un node group, CA aplica un expander para elegir qué grupo escalar:

• least-waste — minimiza el desperdicio de CPU/memoria tras la programación (mejor opción por defecto para coste)
• most-pods — maximiza los pods programados por operación de scale-up
• priority — permite definir un orden mediante ConfigMap
• grpc — delega en un servicio gRPC externo

# Despliegue de Cluster Autoscaler — AWS, ajustado para producción
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cluster-autoscaler
  namespace: kube-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: cluster-autoscaler
  template:
    metadata:
      labels:
        app: cluster-autoscaler
      annotations:
        cluster-autoscaler.kubernetes.io/safe-to-evict: "false"
    spec:
      priorityClassName: system-cluster-critical
      serviceAccountName: cluster-autoscaler
      containers:
        - image: registry.k8s.io/autoscaling/cluster-autoscaler:v1.30.3
          name: cluster-autoscaler
          resources:
            requests:
              cpu: 100m
              memory: 600Mi
            limits:
              cpu: 200m
              memory: 1Gi
          command:
            - ./cluster-autoscaler
            - --cloud-provider=aws
            - --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster
            - --expander=least-waste
            - --balance-similar-node-groups=true
            - --scale-down-delay-after-add=10m
            - --scale-down-unneeded-time=10m
            - --scale-down-utilization-threshold=0.5
            - --max-graceful-termination-sec=600
            - --scan-interval=10s

Scale-down: el enfoque conservador

Un nodo es candidato a scale-down solo si:
– La utilización de CPU y memoria (por requests) está por debajo del umbral (por defecto: 50%)
– Todos los pods podrían reprogramarse en otro nodo
– Ningún pod tiene la anotación cluster-autoscaler.kubernetes.io/safe-to-evict: "false"
– El nodo ha estado infrautilizado durante al menos --scale-down-unneeded-time (por defecto: 10 minutos)

Este conservadurismo evita el churn — es una característica, no un defecto.

Hay un matiz importante que a menudo se pasa por alto: CA no distingue entre un nodo que tiene el 45% de uso de CPU y otro que tiene el 5%. Ambos son candidatos a eliminación si están por debajo del umbral. La granularidad es binaria (utilizado / no utilizado lo suficiente), no continua. Esto contrasta con el enfoque de consolidación activa de Karpenter, que veremos a continuación.

Karpenter: cómo funciona realmente

Karpenter es un proyecto en incubación de la CNCF, construido originalmente por AWS, donado a la CNCF en 2023 y con disponibilidad general (v1.0) a mediados de 2024. Existen providers para AWS (estable), Azure (estable) y GCP (beta).

La idea central: eliminar el node group de la ecuación

Karpenter llama directamente a la API RunInstances de EC2 — sin implicar ASGs. Esto significa:
– Cualquier tipo de instancia en una sola petición, sin necesidad de preconfigurar un node group
– Sin intermediarios: Karpenter → EC2 API → el nodo se une al cluster
– Nodos ajustados exactamente a lo que necesitan las cargas de trabajo, sobre el catálogo completo de instancias
– Karpenter gestiona el ciclo de vida completo del nodo, incluida su terminación

Esta diferencia arquitectónica es la que explica casi todas las ventajas de rendimiento y flexibilidad de Karpenter frente a CA. No es una cuestión de mejor algoritmo; es una cuestión de eliminar una capa completa de indirección.

NodePool y EC2NodeClass

La configuración de Karpenter se expresa mediante dos CRDs principales:

# EC2NodeClass — parámetros específicos del cloud
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiSelectorTerms:
    - alias: al2023@latest
  role: "KarpenterNodeRole-my-cluster"
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: "my-cluster"
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: "my-cluster"
  blockDeviceMappings:
    - deviceName: /dev/xvda
      ebs:
        volumeSize: 50Gi
        volumeType: gp3
        encrypted: true
  metadataOptions:
    httpTokens: required
    httpPutResponseHopLimit: 1
---
# NodePool — intención y restricciones
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general-purpose
spec:
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand", "spot"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64", "arm64"]
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["c", "m", "r"]
        - key: karpenter.k8s.aws/instance-generation
          operator: Gt
          values: ["5"]
        - key: karpenter.k8s.aws/instance-size
          operator: NotIn
          values: ["nano", "micro", "small", "medium", "large"]
      expireAfter: 720h
  limits:
    cpu: "1000"
    memory: 1000Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 5m
    budgets:
      - nodes: "5%"
        schedule: "0 8 * * mon-fri"
        duration: 10h
      - nodes: "25%"

La expresividad de este modelo de configuración es significativa: en lugar de mantener varios ASGs con tipos de instancia fijos, defines restricciones y dejas que Karpenter resuelva la instancia óptima en tiempo de ejecución. Para clusters con carga variable o diversa (batch, APIs sin estado, workloads GPU), esto elimina una cantidad enorme de gestión manual de configuración.

Aprovisionamiento just-in-time y bin packing

Cuando los pods van a Pending, Karpenter observa el evento (no hace polling) e inmediatamente:
1. Recopila todos los pods en Pending
2. Simula el bin packing — el mínimo número de nodos posible sobre el catálogo completo de instancias
3. Selecciona las instancias que satisfacen todos los requisitos de los pods
4. Llama a la EC2 API para aprovisionar las instancias óptimas

Disruption y consolidación

El valor diferencial de Karpenter: la consolidación activa del cluster. Evalúa si los nodos pueden eliminarse redistribuyendo los pods en otros, o reemplazándolos con un tipo de instancia más pequeño. Un c5.4xlarge ejecutando pods que consumen 4 vCPU se reemplaza por un c5.xlarge. Los equipos reportan habitualmente reducciones de coste de cómputo del 30–50%.

Las opciones de consolidationPolicy son:
– WhenEmpty — solo elimina nodos sin pods de workload (más conservador)
– WhenEmptyOrUnderutilized — también reemplaza nodos infrautilizados por instancias más pequeñas

La consolidación no es solo una mejora incremental sobre el scale-down de CA — es cualitativamente diferente. CA puede decirte «este nodo está infrautilizado, lo elimino». Karpenter puede decirte «estos tres nodos están infrautilizados, puedo consolidar todo en uno más pequeño, déjame hacerlo». La diferencia en ahorro de costes compuesto a lo largo del tiempo es sustancial.

Comparativa de arquitectura

Velocidad de escalado: los números reales

Esta es probablemente la diferencia más visible en producción, y merece un análisis secuencia por secuencia.

Cluster Autoscaler en AWS (típico)

1. Pod en Pending → el escaneo de CA lo detecta (0–10s)
2. Llamada API UpdateAutoScalingGroup al ASG (~15–30s)
3. La instancia EC2 arranca (1–2 min)
4. Bootstrap del nodo + registro del kubelet (30–60s)
5. El pod se programa (5–10s)

Total: 3–6 minutos (hasta 12 minutos en períodos de alta demanda de capacidad EC2)

Karpenter en AWS (típico)

1. Pod en Pending → el watch event se dispara (~1s)
2. Llamada API EC2 RunInstances (~2–3s)
3. La instancia EC2 arranca (el mismo hardware — 1–2 min)
4. El nodo hace bootstrap y queda Ready (30–60s)
5. El pod se programa (~5s)

Total: 90 segundos a 3 minutos

La diferencia de hardware es idéntica — el tiempo de arranque de EC2 es el mismo. La ventaja de Karpenter proviene de eliminar el polling del bucle de control y la capa ASG. A efectos prácticos, esto es una mejora de 2–4x en el tiempo de aprovisionamiento en condiciones normales, y de hasta 8x en condiciones de alta contención de capacidad.

Para workloads event-driven, batch o APIs con picos bruscos de tráfico, esta diferencia determina directamente si los SLOs se cumplen o se incumplen.

Optimización de costes: donde Karpenter toma ventaja

Right-sizing

CA requiere node groups predefinidos. Si tienes cargas de trabajo con necesidades de memoria muy variables — un pod de 2 GiB y otro de 14 GiB — necesitas node groups que cubran ambos casos, o desperdicias recursos. Karpenter selecciona la instancia mínima viable para el workload pendiente desde el catálogo completo, sin necesidad de preconfigurar.

Consolidación frente a scale-down

CA elimina nodos infrautilizados. Karpenter reemplaza un nodo grande infrautilizado por uno más pequeño que aún cabe con todos los pods. Esto produce un ahorro compuesto a lo largo del tiempo que CA estructuralmente no puede alcanzar.

Ejemplo concreto: tienes un m5.4xlarge (16 vCPU, 64 GiB) con pods que solo consumen 3 vCPU y 12 GiB. CA lo deja como está porque tiene pods. Karpenter lo reemplaza por un m5.xlarge (4 vCPU, 16 GiB) y redistribuye. El coste baja un 75% en ese nodo.

Gestión de instancias spot

Karpenter recibe los avisos de interrupción de EC2, pre-aprovisiona un nodo de reemplazo y drena el nodo afectado — todo dentro de la ventana de 2 minutos. No requiere AWS Node Termination Handler. Además, diversifica automáticamente las peticiones de spot entre tipos de instancia para reducir el riesgo de interrupciones simultáneas.

Con CA, gestionar instancias spot de forma fiable requiere: ASGs configurados con múltiples tipos de instancia (opción mixed instances policy), desplegar y mantener el AWS Node Termination Handler, y ajustar los interruptionHandlers en la configuración de CA. Con Karpenter, declaras capacity-type: spot en el NodePool y el resto es automático.

Soporte multicloud en 2026

Esta tabla es probablemente el factor más determinante en la decisión para muchos equipos. Si tu organización no está en AWS o Azure, la decisión prácticamente se toma sola: Cluster Autoscaler es la opción razonable.

Una excepción notable: GKE en GCP tiene su propio mecanismo de autoescalado (Node Auto Provisioning / NAP) que es técnicamente superior a CA en ese entorno. Si estás en GKE, la respuesta suele ser «ninguno de los dos — usa NAP».

Cuándo Cluster Autoscaler sigue siendo la elección correcta

A pesar del innegable avance técnico de Karpenter, hay escenarios donde CA sigue siendo la respuesta correcta:

1. Entornos no-AWS
Si estás en GCP (sin GKE NAP), Alibaba, DigitalOcean o on-premises con Cluster API, Karpenter no es una opción viable. CA es la herramienta madura y bien soportada para esos entornos.

2. Arquitectura de node groups existente con inversión significativa
Si tienes años de diseño de ASGs, tooling de compliance vinculado a tags de ASG y pipelines de CI/CD que asumen la existencia de node groups específicos, el coste de migración puede superar fácilmente el beneficio. No migres por migrar.

3. Restricciones regulatorias
Algunos marcos de cumplimiento (PCI-DSS, entornos gubernamentales con requisitos específicos de auditoría) requieren trazabilidad de aprovisionamiento a través de ASGs. El modelo directo de Karpenter puede complicar las evidencias de auditoría en estos contextos.

4. Cluster API / bare metal
CA es la única opción madura para entornos con Cluster API o bare metal. Karpenter requiere un provider de cloud para funcionar.

5. Despliegues CA que funcionan bien y equipo sin tiempo para migrar
Si tu CA está bien configurado, los SLOs se cumplen y no tienes presión de costes urgente, la relación coste-beneficio de migrar puede no ser favorable a corto plazo. «Si funciona, no lo toques» es un principio válido de ingeniería.

Cuándo Karpenter es la elección correcta

1. Clusters AWS-nativos con prioridad de optimización de costes
La combinación de right-sizing + consolidación activa produce reducciones de coste reales y sostenidas. Si tu factura de cómputo en AWS es significativa, el ROI de migrar a Karpenter es generalmente positivo en semanas.

2. Workloads diversas y variables
Batch, spot, GPU, APIs sin estado — Karpenter gestiona todo esto con unos pocos NodePools bien definidos, sin la proliferación de ASGs que requeriría CA para el mismo nivel de flexibilidad.

3. Clusters spot-heavy
La gestión nativa de interrupciones de spot, con diversificación automática entre tipos de instancia y pre-aprovisionamiento de reemplazos, es cualitativamente superior al stack CA + NTH. Si más del 30–40% de tu capacidad es spot, Karpenter simplifica enormemente la operación.

4. Cultura infrastructure-as-code declarativa
Los NodePools se versionan limpiamente en Git, se revisan en pull requests, y expresan intención en lugar de configuración imperativa. Para equipos con GitOps maduro, esto es una mejora real en mantenibilidad.

5. Requisitos de escalado de baja latencia
Workloads event-driven, jobs desencadenados por KEDA, picos bruscos de tráfico. Si los 3–6 minutos de CA están dentro de tu ventana de incumplimiento de SLO, Karpenter soluciona el problema estructuralmente.

Ejecutar ambos: ruta de migración y gotchas

Hay escenarios válidos para ejecutar CA y Karpenter en paralelo — especialmente durante la migración o cuando tienes workloads con requisitos contradictorios. Lo más importante es que no gestionen los mismos nodos.

Separar la responsabilidad

Usa labels y taints para evitar que CA y Karpenter gestionen los mismos nodos:

# NodePool con taint — los pods gestionados por CA no tolerarán esto
spec:
  template:
    metadata:
      labels:
        provisioner: karpenter
    spec:
      taints:
        - key: karpenter.sh/provisioned
          value: "true"
          effect: NoSchedule

Migración gradual recomendada

Fase 1 — Karpenter gestiona workloads spot y batch. CA gestiona los nodos on-demand de producción. Esto valida Karpenter con workloads menos críticos.

Fase 2 — Migrar workloads spot completamente a Karpenter. Eliminar AWS NTH (ya no es necesario). Validar el comportamiento de consolidación.

Fase 3 — Migrar nodos on-demand. Reducir gradualmente la capacidad de los node groups de CA mientras se monitorizan los NodePool limits de Karpenter.

Fase 4 — Desmantelar CA una vez que todos los grupos están vacíos. Limpiar ASGs y tooling asociado.

Budget mínimo para una migración bien hecha en un cluster de tamaño medio: un sprint completo. Las prisas aquí tienen consecuencias directas en disponibilidad.

Gotchas que te van a costar tiempo

Karpenter consolidation + PDBs permisivos: maxUnavailable: 100% causará consolidación disruptiva. Audita tus PodDisruptionBudgets antes de habilitar WhenEmptyOrUnderutilized. Un PDB mal configurado puede provocar una interrupción de servicio durante la consolidación.

Los NodePool limits son paradas duras: cuando un NodePool alcanza su límite de CPU o memoria, los pods van a Pending indefinidamente. CA tiene el mismo problema, pero los equipos nuevos en Karpenter tienden a descubrirlo en producción. Monitoriza la utilización de los límites activamente.

AMI drift: el alias @latest selecciona nuevas AMIs en nuevos nodos. Esto significa que puedes tener nodos con AMIs diferentes conviviendo en el cluster. Para entornos con control de cambios estricto, considera anclar la versión de AMI o implementar tests de validación antes de actualizar el alias.

Conflictos de scale-down simultáneos: durante la migración, CA y Karpenter pueden intentar escalar hacia abajo al mismo tiempo. La segregación estricta por labels y taints es la única garantía real contra esto.

Framework de decisión

El árbol de decisión simplificado:

¿Ejecutas en AWS?
├── No → ¿Azure? → Karpenter (estable) o CA
│        ¿GCP?   → CA o GKE NAP (preferido)
│        ¿Otro?  → Cluster Autoscaler
│
└── Sí → ¿Restricciones regulatorias que exigen ASG?
          ├── Sí → Cluster Autoscaler
          └── No → ¿Prioridad de optimización de costes o workloads diversas?
                   ├── Sí → Karpenter
                   └── No → Cualquiera (elige según preferencia del equipo)

Preguntas frecuentes

¿Es Karpenter un sustituto directo de Cluster Autoscaler?

No. Son modelos de configuración y conceptos diferentes. La migración requiere re-expresar la configuración de node groups como NodePools/NodeClasses, auditar PDBs y ejecutar ambos en paralelo durante la transición. Presupuesta al menos un sprint para un cluster de tamaño medio. No hay un botón de «migrar».

¿Puedo usar Karpenter en Kubernetes autogestionado (sin EKS)?

Sí, pero con trabajo extra. Karpenter requiere credenciales IAM (IRSA o equivalente) para llamar a las APIs de EC2. En clusters autogestionados, esto requiere más configuración que en EKS donde IRSA es nativo. Es viable, pero no es el camino de menor resistencia.

¿Cómo interactúa Karpenter con HPA y VPA?

Sin conflicto. El flujo es: HPA crea pods → los pods van a Pending si no hay nodos suficientes → Karpenter aprovisiona nodos → los pods se programan. VPA ajusta los resource requests de los pods, que Karpenter usa como inputs para el bin packing. Los tres pueden coexistir sin problemas.

¿Qué ocurre si Karpenter se cae?

Los nodos existentes y los pods continúan con normalidad. Los pods nuevos que requieran aprovisionamiento quedan en Pending hasta que Karpenter se recupere. El scale-down y la consolidación se pausan. Para producción, despliega múltiples réplicas con leader election.

¿Karpenter soporta nodos GPU?

Sí. Los tipos de instancia GPU (p3, p4, g4, g5) pueden incluirse en los requirements del NodePool. La recomendación es crear NodePools dedicados con taints apropiados para los pods que soliciten recursos GPU, manteniendo la separación clara de workloads GPU frente al resto.

¿Cómo gestiona Karpenter las actualizaciones de AMI?

El campo expireAfter fuerza la rotación de nodos. Cuando un nodo expira, Karpenter pre-aprovisiona un reemplazo con la AMI más reciente según el EC2NodeClass, luego drena y termina el nodo antiguo. Es efectivamente un mecanismo de rolling AMI update sin tooling adicional. La alternativa es anclar la versión de AMI explícitamente y gestionar las actualizaciones de forma controlada.

¿Cluster Autoscaler sigue con mantenimiento activo?

Sí. CA sigue en desarrollo activo bajo kubernetes/autoscaler, con releases que siguen las versiones minor de Kubernetes. No está siendo deprecado. Para entornos no-AWS y despliegues CA que funcionan bien, sigue siendo una elección completamente soportada y racional. La narrativa de «CA está muerto» es incorrecta — simplemente tiene un ámbito de aplicación más claro en 2026.

Conclusión

Ni Cluster Autoscaler ni Karpenter son la respuesta universal. Son herramientas diferentes para contextos diferentes, y en 2026 ambas están maduras.

Si estás en AWS y el coste de cómputo o la velocidad de escalado son prioridades reales, Karpenter es la elección técnicamente superior. La combinación de aprovisionamiento directo vía EC2 API, consolidación activa y gestión nativa de spot produce beneficios compuestos que CA estructuralmente no puede igualar.

Si no estás en AWS, tienes restricciones regulatorias específicas, o tu CA actual funciona bien y el equipo no tiene ancho de banda para una migración, Cluster Autoscaler sigue siendo la respuesta correcta. No migres por moda.

La pregunta que vale la pena hacerse no es «¿cuál es mejor?» sino «¿cuál resuelve mi problema concreto con el menor coste operativo?». Para la mayoría de clusters AWS en 2026, esa respuesta es Karpenter — pero solo si estás dispuesto a hacer la migración bien.

Validado con Kubernetes 1.28–1.32. API de Karpenter v1.x (GA). CA v1.30.x. Los ejemplos usan el provider de AWS; los detalles de los providers de Azure y GCP pueden diferir.