Karpenter vs Cluster Autoscaler: comparativa de escalado de nodos en AWS EKS

Introducción

Son las tres de la madrugada. Miras la alerta roja en Grafana: los Pods llevan cuatro minutos en estado Pending. Llegó el pico de tráfico, pero los nodos siguen en «arrancando».

El administrador del clúster de al lado ya está durmiendo. Su sistema de escalado terminó de levantar nodos en 55 segundos.

No es exageración. Es la brecha real entre Karpenter y Cluster Autoscaler.

Para ser honesto, la primera vez que vi estos datos también desconfié. ¿Un minuto frente a tres minutos realmente importa tanto? Hasta que probé ambos sistemas en EKS y me di cuenta de que la diferencia es lo bastante grande como para replantear toda la estrategia de escalado.

Según el informe de Reintech de 2026, Karpenter escala en menos de 60 segundos, mientras que Cluster Autoscaler (en adelante CA) necesita 3-5 minutos [1]. En costos, usuarios reales reportan ahorros del 20-40% [2]. Salesforce incluso completó la migración a escala de miles de clústeres [3].

Este artículo te ayudará a entender: ¿en qué se diferencian estas herramientas? ¿Cuál elegir? ¿Cómo migrar? Responderé con datos reales, ejemplos de configuración completos y un cronograma de migración.

1. Comparativa de arquitectura: ¿por qué la brecha de velocidad es tan grande?

Diferencia principal: CA depende de grupos de nodos; Karpenter configura nodos directamente.

Suena simple, pero la brecha arquitectónica detrás afecta todo el flujo de escalado.

El flujo «indirecto» de Cluster Autoscaler

CA trabaja como si tomara un camino largo.

Cuando falla el scheduling de un Pod, CA primero revisa los grupos de nodos predefinidos (Node Group). Cada grupo está vinculado a tipos de instancia fijos: por ejemplo, node-group-1 con m5.large y node-group-2 con c5.xlarge.

CA debe decidir: ¿qué grupo encaja? Una vez elegido, llama a la API del proveedor (AWS Auto Scaling Groups API) para escalar. Luego espera a que ASG lance instancias, a que se unan al clúster, a que los nodos estén Ready y, por fin, puede programar el Pod.

Son 4-5 pasos. Cada uno añade latencia.

Especialmente el paso «revisar grupo → elegir grupo». Si tu Pod necesita GPU pero ningún grupo tiene ese tipo, CA no puede hacer nada: solo puede elegir entre grupos existentes.

El enfoque «directo» de Karpenter

Karpenter es completamente distinto.

¿Falló el scheduling del Pod? Sin problema. Karpenter analiza directamente la demanda: ¿cuánta CPU? ¿cuánta memoria? ¿necesita GPU? ¿tiene tolerations o nodeSelector especiales?

Tras analizar la demanda, Karpenter llama directamente a la API de EC2 y aprovisiona la instancia más adecuada. Sin grupos de nodos, sin ASG: encaja directamente con la demanda del Pod.

Luego el nodo arranca, se une al clúster y se programa el Pod. Dos pasos centrales, sin las vueltas intermedias.

La documentación oficial de AWS lo dice claro: Karpenter puede lanzar recursos de cómputo en menos de 1 minuto [4].

Una analogía

CA es como el flujo de pedido en un restaurante: el cliente quiere pollo picante, el mesero primero revisa si está en el menú (grupos de nodos), hace el pedido (llama a ASG), la cocina prepara (arranca instancias) y finalmente sirve (programa el Pod).

Karpenter es como una cocina abierta: el cliente quiere pollo picante, el chef mira directamente la demanda (specs del Pod), va al almacén por ingredientes (llama a la API de EC2) y cocina al momento.

¿Cuál es más rápido? De un vistazo.

¿Por qué CA depende de grupos de nodos?

CA se diseñó desde el inicio para soporte multicloud. El mecanismo de grupos de nodos le permite usar la misma lógica en AWS, GCP y Azure — solo cambia el nombre (AWS usa ASG, GCP usa MIG, Azure usa VMSS).

Pero ese diseño también trae limitaciones: debes definir grupos de nodos con anticipación. ¿Quieres un nuevo tipo de instancia? Crea un grupo. ¿Quieres Spot? Crea un grupo Spot. El costo de mantenimiento sube y la flexibilidad baja.

Karpenter, en cambio, es diseño nativo de AWS. No necesita la capa intermedia de grupos de nodos e interactúa directamente con la API de EC2. La desventaja es soporte multicloud débil (hoy principalmente AWS); la ventaja es velocidad y configuración más simple.

2. Benchmark de rendimiento: comportamiento en entornos reales

Karpenter escala rápido; el escalado hacia abajo tampoco es lento.

Los datos de este capítulo provienen principalmente de pruebas técnicas de CHKK y feedback de usuarios reales.

Velocidad de escalado: comparativa medida

Los datos de prueba de CHKK son bastante claros [5]:

• Karpenter: Pods intensivos en CPU listos en unos 55 segundos
• Cluster Autoscaler: la misma carga, 3-4 minutos

Esta brecha coincide con lo que AWS oficialmente describe como «menos de 1 minuto» [4].

En Reddit hay un usuario que hizo sus propias pruebas y comentó que la diferencia real no era tan dramática — la latencia de nodos listos era similar, probablemente porque su clúster era pequeño (unos 10 nodos) [6]. Es feedback de un solo usuario con muestra limitada; tómalo como referencia, no como conclusión.

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

Eficiencia de escalado hacia abajo: ¿quién ahorra más?

Escalar rápido es la superficie; la eficiencia al reducir nodos es lo que realmente ahorra dinero.

La lógica de CA es revisión periódica: cada cierto intervalo (por defecto 10 segundos) escanea el clúster buscando nodos inactivos por mucho tiempo. Si superan el umbral (por defecto 10 minutos), dispara el escalado hacia abajo.

Karpenter es distinto. Usa Consolidation — monitorea la utilización de nodos en tiempo real, fusiona cuando puede y reemplaza cuando conviene.

Ejemplo: tu clúster tiene 3 nodos m5.xlarge con utilización del 30%, 25% y 20%. Karpenter evalúa: ¿caben esos Pods en 1 m5.large? Si sí, elimina los 3 nodos grandes y los reemplaza por 1 pequeño.

El blog oficial de AWS da datos sobre este enfoque: Spot combinado con Consolidation puede ahorrar hasta 90% de costos (frente a On-demand) [7].

Diferencias en clústeres grandes

CA tiene cuellos de botella en clústeres grandes (100+ nodos).

El blog de ScaleOps menciona que cuantos más grupos de nodos, más lento es el scheduling de CA [8]. Debe recorrer todos los grupos para encontrar el adecuado. Más grupos significa más tiempo de recorrido y más latencia.

Karpenter no tiene esta limitación. No depende de grupos de nodos: analiza directamente la demanda del Pod y encuentra el tipo de instancia óptimo. Por grande que sea el clúster, la lógica es la misma.

Caso real: escenarios de procesamiento por lotes

Un escenario que he visto en la práctica.

Un pipeline de datos dispara un batch cada hora y necesita 50 worker Pods. En entorno CA, los Pods esperaron 3 minutos en Pending, el batch arrancó tarde y el ciclo completo del pipeline se alargó.

Tras migrar a Karpenter, todos los Pods estuvieron Running en 50 segundos. El batch arrancó a tiempo y el ciclo de procesamiento aguas abajo volvió a la normalidad.

La clave aquí: el batch es sensible a la latencia de arranque. Tres minutos de espera pueden retrasar toda la cadena de datos. Escalar en menos de un minuto es una necesidad para este tipo de carga.

3. Ahorro de costos: el secreto del 20-40%

La ventaja de costos de Karpenter viene de tres mecanismos: instancias Spot, Consolidation y estrategia de selección de instancias.

Cada uno por separado no es novedad. Combinados, el efecto llega al 20-40% de ahorro — datos de usuarios reales del informe Reintech [2].

Instancias Spot: hasta 90% de ahorro

El precio de instancias Spot de AWS puede ser hasta 90% más barato que On-demand [7]. Dato oficial de AWS, alta confianza.

Pero Spot tiene riesgo: puede interrumpirse en cualquier momento. AWS avisa con 2 minutos de anticipación y luego recupera la instancia [7].

Con CA, usar Spot implica crear manualmente grupos Spot y configurar lógica de manejo de interrupciones. Proceso engorroso, propenso a errores.

Karpenter maneja las interrupciones Spot automáticamente. Al recibir la notificación, completa cordon (marcar nodo como no programable) y drain (migrar Pods a otros nodos) en 2 minutos. Sin scripts adicionales: la lógica está integrada.

Estrategia PCO: elegir Spot con inteligencia

Karpenter usa la estrategia Price Capacity Optimized (PCO) [7].

En pocas palabras: primero elige el pool Spot con menor probabilidad de interrupción, luego dentro del pool la instancia de menor precio.

La inteligencia está en equilibrar dos objetivos: ahorrar y mantener estabilidad. El pool más barato interrumpe más; el más estable ahorra menos. PCO busca el punto medio.

El blog oficial de AWS lo explica en detalle [7]:

1. Karpenter monitorea la tasa de interrupción de pools Spot (datos oficiales de AWS)
2. Filtra pools con alta tasa de interrupción
3. En los pools restantes, elige el tipo de instancia de menor precio

Esta lógica no requiere configuración: Karpenter la activa por defecto.

Consolidation: ahorro en tiempo real

Ya mencioné Consolidation en el capítulo 2. Aquí profundizo en la configuración.

Karpenter soporta dos estrategias de Consolidation [7]:

• WhenEmpty: elimina nodos completamente inactivos
• WhenUnderutilized: cuando la utilización es baja, intenta fusionar o reemplazar

Por defecto es WhenUnderutilized, más agresivo.

Ejemplo:

# Karpenter NodePool - Configuración de Consolidation
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenUnderutilized  # Fusión agresiva
    consolidateAfter: 1m                     # Dispara tras 1 minuto inactivo

CA no tiene esta función. Solo puede eliminar periódicamente nodos inactivos por mucho tiempo; no puede «fusionar nodos pequeños en uno grande» ni «reemplazar instancias caras por baratas».

Cálculo de ROI: beneficios reales

Supón que tu clúster cuesta $50,000/mes (100 nodos, tipos de instancia mixtos).

Tras migrar a Karpenter, estimación conservadora de 20% de ahorro: $10,000/mes.

Estimación agresiva (uso pleno de Spot + Consolidation) de 40%: $20,000/mes.

En un año, ahorras entre $120,000 y $240,000.

Este cálculo no es ficticio: se basa en datos de usuarios reales de Reintech [2]. El beneficio real depende del tipo de carga, proporción de Spot y configuración de Consolidation.

Comparativa de configuración: ¿cuál es más sencillo?

Flujo de configuración Spot con CA:

1. Crear ASG Spot (selección manual de tipos de instancia)
2. Configurar la estrategia de asignación Spot del ASG
3. Escribir scripts de manejo de interrupciones (monitorear notificaciones, drain manual)
4. Configurar el parámetro --node-group-auto-discovery de CA

Configuración Spot con Karpenter:

# Un solo NodePool lo resuelve todo
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
      - key: karpenter.sh/capacity-type
        operator: In
        values: ["spot", "on-demand"]  # Selección automática Spot u On-demand
      - key: karpenter.k8s.aws/instance-category
        operator: In
        values: ["c", "m", "r"]  # Series c/m/r, suficiente diversidad
  disruption:
    consolidationPolicy: WhenUnderutilized

Un YAML cubre selección Spot, diversidad de tipos de instancia y Consolidation. Karpenter maneja interrupciones, elige la instancia óptima y fusiona nodos automáticamente.

La diferencia en comodidad es evidente.

4. Complejidad de configuración: análisis costo-beneficio

CA se configura rápido; Karpenter tarda más en aprenderse, pero el costo de mantenimiento se invierte a largo plazo.

Los datos de este capítulo provienen del informe Reintech [1]: CA «unas horas», Karpenter «1-2 días».

La primera vez que vi estos datos pensé que exageraban. Después de hacerlo yo mismo, Reintech no estaba tan lejos.

CA: rápido al inicio, cansado de mantener

Flujo de configuración de CA:

# Deployment de CA (versión simplificada)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cluster-autoscaler
  namespace: kube-system
spec:
  containers:
  - name: cluster-autoscaler
    image: k8s.gcr.io/autoscaling/cluster-autoscaler:v1.30.0
    command:
    - ./cluster-autoscaler
    - --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled
    - --scale-down-unneeded-time=10m
    - --scale-down-delay-after-add=10m

Los parámetros centrales son pocos: descubrimiento de grupos, umbral de escalado hacia abajo, tiempos de retardo. Tras configurar el Deployment y crear grupos de nodos (ASG), CA ya funciona.

Unas horas, no es exageración.

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

Pero el costo de mantenimiento viene después.

Cada vez que quieres un nuevo tipo de instancia, creas un grupo. ¿Quieres Spot? Crea un grupo Spot. Más grupos significa más gestión: cada ASG tiene su propio min/max de nodos, tipos de instancia y etiquetas.

Con el tiempo, los archivos de configuración de grupos se acumulan en YAML. Cambiar un parámetro puede afectar varios grupos.

Karpenter: lento al inicio, cómodo de mantener

La complejidad de Karpenter está en entender los conceptos.

Debes dominar NodePool, Disruption, Consolidation, requirements. La primera vez me tomó un día entender cada parámetro.

# NodePool de Karpenter (versión completa)
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
      - key: karpenter.k8s.aws/instance-category
        operator: In
        values: ["c", "m", "r"]
      - key: karpenter.sh/capacity-type
        operator: In
        values: ["spot", "on-demand"]
      - key: karpenter.k8s.aws/instance-generation
        operator: Gt
        values: ["5"]  # Generación 5 o superior
      nodeClassRef:
        name: default
  disruption:
    consolidationPolicy: WhenUnderutilized
    consolidateAfter: 1m
  limits:
    cpu: 1000
    memory: 1000Gi

Este YAML tiene más parámetros que el Deployment de CA. Pero una vez entendido, un solo NodePool cubre múltiples tipos de instancia, mezcla Spot/On-demand y Consolidation automática.

El costo de mantenimiento es casi cero.

¿Nuevo tipo de instancia? Modifica los values de requirements y añade una serie. ¿Ajustar Consolidation? Cambia consolidationPolicy.

Un YAML para gobernarlos a todos, sin mantener montones de grupos de nodos.

Compromiso entre ambas configuraciones

La recomendación de Reintech es práctica [1]:

• CA conviene para: equipos con recursos limitados, preferencia por configuración simple, cargas homogéneas
• Karpenter conviene para: equipos de plataforma, cargas diversas, sensibles al costo, dispuestos a invertir tiempo de aprendizaje

Si mantienes un clúster pequeño personal (10-20 nodos), la configuración simple de CA puede ser más adecuada.

Si mantienes un clúster mediano-grande en equipo (50+ nodos), o cargas variadas (batch + servicios web + tareas GPU), el costo de mantenimiento a largo plazo de Karpenter es menor.

5. Hoja de ruta de migración: de CA a Karpenter

Ciclo de migración 2-4 semanas; el riesgo principal es ejecutar ambos sistemas en paralelo.

Este dato proviene del informe Reintech [1]. El caso de Salesforce es más convincente: completaron la migración en más de 1000 clústeres EKS [3].

Salesforce usó Karpenter transition tool (herramienta oficial de migración) con estrategia de ejecución en paralelo. Los detalles los desarrollo más adelante.

Semana 1: preparación

Objetivo: instalar Karpenter, crear NodePool, configurar permisos IAM.

Lista de tareas:

1. Instalar Karpenter (helm o eksctl)
2. Crear NodePool (empieza con uno simple, mezcla Spot/On-demand)
3. Configurar permisos IAM (Karpenter necesita permisos EC2)
4. Verificar que Karpenter puede aprovisionar nodos correctamente

Puntos clave:

• Los permisos IAM deben ser completos. Karpenter necesita ec2:RunInstances, ec2:TerminateInstances, ec2:DescribeInstances, etc.
• Los limits del NodePool deben ser razonables para evitar escalado excesivo (por ejemplo, cpu: 100 para evitar aprovisionamiento ilimitado).
• No detengas CA. Sigue ejecutándose; Karpenter es respaldo por ahora.

Semana 2: pruebas

Objetivo: migrar cargas no críticas a Karpenter y monitorear rendimiento comparativo.

Lista de tareas:

1. Elegir cargas de prueba (tareas batch, servicios de baja prioridad)
2. Usar nodeSelector o affinity para dirigir cargas de prueba a nodos aprovisionados por Karpenter
3. Observar velocidad de escalado, manejo de interrupciones Spot, efecto de Consolidation
4. Comparar latencia y costos entre CA y Karpenter

Puntos clave:

• No uses demasiadas cargas de prueba; controla el 10-20% de recursos del clúster.
• Métricas clave: tiempo de Pod Pending, tiempo de arranque de nodos, interrupciones Spot, utilización de nodos.
• Si Karpenter no rinde bien, ajusta requirements o consolidationPolicy del NodePool a tiempo.

Semana 3: ejecución mixta

Objetivo: migrar gradualmente cargas de producción; CA y Karpenter en paralelo.

Lista de tareas:

1. Migrar 10-15% de cargas de producción cada día
2. Usar nodeSelector para controlar distribución de Pods (parte en nodos CA, parte en nodos Karpenter)
3. Monitorear frecuencia de escalado, costos y estabilidad de ambos sistemas
4. Hacer rollback a tiempo si hay problemas (redirigir Pods a nodos CA)

Puntos clave:

• Durante la ejecución en paralelo, ambos sistemas pueden interferirse. Por ejemplo, nodos escalados por CA podrían ser eliminados por error por la Consolidation de Karpenter. Separar distribución con nodeSelector es clave.
• Configura alertas: Pod Pending más de 3 minutos (recomendación oficial de AWS [7]).
• Si los costos suben, revisa proporción de Spot y configuración de Consolidation del NodePool.

Semana 4: cambio completo

Objetivo: deshabilitar CA, limpiar grupos de nodos, Karpenter asume toda la carga.

Lista de tareas:

1. Deshabilitar CA (reducir replicas del Deployment a 0)
2. Limpiar grupos de nodos de CA (ASG)
3. Eliminar nodeSelector de todos los Pods para que Karpenter programe automáticamente
4. Monitorear rendimiento con Karpenter a plena escala y ajustar NodePool

Puntos clave:

• Antes de deshabilitar CA, confirma que Karpenter ya asumió todas las cargas.
• Limpia grupos con cuidado: antes de eliminar ASG, confirma que no hay nodos en ejecución.
• Tras el cambio completo, observa varios días para asegurar que no hay anomalías.

Experiencia de migración de Salesforce

El caso de Salesforce está documentado en detalle en AWS Architecture Blog [3].

Su flujo de migración:

1. Usar Karpenter transition tool para detectar automáticamente configuración de grupos CA y generar NodePools equivalentes
2. Ejecutar CA y Karpenter en paralelo, migrar cargas gradualmente
3. Monitorear latencia de escalado y cambios de costo por clúster
4. Tras deshabilitar CA, limpiar grupos de nodos

Punto clave: transition tool simplifica la migración de configuración. La configuración de grupos CA se convierte automáticamente en NodePools de Karpenter, ahorrando tiempo de configuración manual.

"Completamos la migración de Cluster Autoscaler a Karpenter en más de 1000 clústeres EKS, usando Karpenter transition tool para simplificar la conversión de configuración."

Lista de mitigación de riesgos

1. Ejecución en paralelo: no deshabilites CA directamente; ejecuta ambos un tiempo
2. Control con nodeSelector: separa distribución de Pods con etiquetas para evitar interferencia mutua
3. Configurar limits: establece límites de CPU/Memory en NodePool para evitar escalado excesivo
4. Alertas de monitoreo: Pod Pending > 3 minutos dispara alerta [7]
5. Preparar rollback: conserva archivos de configuración de CA para volver en cualquier momento

6. Marco de decisión: ¿qué elegir en 2026?

No hay respuesta absoluta; depende de tus prioridades.

Reintech proporciona una tabla de decisión [1]; la complementé con información oficial de AWS.

Matriz de decisión en cinco dimensiones

Recomendaciones por escenario típico

Escenario 1: equipo pequeño, carga simple

• Escala del clúster: 10-20 nodos
• Carga: principalmente servicios web, tráfico estable
• Prioridad: configuración simple, adopción rápida

Recomendación: CA.

Razón: CA se configura en horas y el costo de mantenimiento no es notable en clústeres pequeños. El costo de aprendizaje de Karpenter puede no compensar para equipos pequeños.

Escenario 2: equipo mediano-grande, sensible al costo

• Escala del clúster: 50+ nodos
• Carga: tipos mixtos (web + batch + tareas Spot)
• Prioridad: control de costos, gestión automatizada

Recomendación: Karpenter.

Razón: el ahorro del 20-40% es significativo en clústeres medianos-grandes [2]. Consolidation y automatización Spot ahorran esfuerzo operativo.

Escenario 3: entorno multicloud

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

• Distribución de clústeres: AWS + GCP + Azure
• Prioridad: solución unificada de escalado

Recomendación: CA.

Razón: CA tiene soporte multicloud maduro; GCP y Azure tienen mecanismos de grupos de nodos. Karpenter hoy soporta principalmente AWS (diseño nativo).

Tendencia futura: EKS Auto Mode

AWS lanzó en 2026 EKS Auto Mode — solución nativa basada en Karpenter [4].

En pocas palabras: AWS integra la lógica de Karpenter en EKS Auto Mode. Sin instalar Karpenter por separado, EKS escala nodos automáticamente.

Esta tendencia indica la dirección de AWS: la arquitectura de Karpenter es el esquema futuro reconocido por AWS.

Si es un clúster nuevo, considera usar EKS Auto Mode directamente y ahorrarte los pasos de instalación y configuración de Karpenter.

Comparativa de soporte multicloud

CA: cobertura completa en AWS, GCP y Azure.

• AWS: Auto Scaling Groups
• GCP: Managed Instance Groups
• Azure: Virtual Machine Scale Sets

El mecanismo de grupos de nodos de CA se adapta naturalmente a multicloud.

Karpenter: principalmente AWS; progreso lento en otras nubes.

Actualmente Karpenter solo soporta oficialmente AWS. La comunidad tiene PRs para Azure (funciones parciales) y el soporte GCP está en etapa temprana.

Si necesitas multicloud, CA es hoy la única opción madura. A largo plazo, el soporte multicloud de Karpenter irá mejorando.

Mi recomendación

Si tu clúster está en AWS y cumple estas condiciones:

1. Escala del clúster > 30 nodos
2. Tipos de carga diversos
3. El costo es consideración clave
4. Tienes equipo de plataforma

Ve directo a Karpenter, o usa EKS Auto Mode.

Si tu clúster es pequeño (< 20 nodos) o es entorno multicloud, CA sigue siendo la opción segura.

En entornos AWS EKS de 2026, Karpenter ya es la solución recomendada. Pero CA sigue teniendo valor en escenarios específicos (multicloud, clústeres pequeños).

Resumen

Después de todo esto, la conclusión central en tres frases:

Karpenter gana en velocidad, costo y flexibilidad. CA sigue teniendo valor en simplicidad y soporte multicloud.

En entornos AWS EKS de 2026, Karpenter es la solución recomendada. Pero la migración requiere 2-4 semanas de planificación y pruebas; no cambies a las apuradas.

Si tienes un clúster nativo de AWS, carga diversa y sensible al costo — empieza tu primera prueba de NodePool de Karpenter. Consulta la guía oficial de migración [9], ejecuta en paralelo dos semanas y cambia gradualmente.

Si tu clúster es multicloud, o pequeño con carga estable — CA sigue siendo suficiente; no hace falta migrar a la fuerza.

Próximos pasos:

• Lee la documentación oficial de migración de Karpenter [9]
• Crea un NodePool de prueba y ejecuta una tarea batch
• Monitorea tiempo de Pod Pending y cambios de costo; compara con CA

Seguiré publicando artículos prácticos sobre gestión de clústeres EKS. Suscríbete al blog para no perderte actualizaciones.

Referencias

[1] Reintech - Karpenter vs Cluster Autoscaler: Which Should You Use in 2026
https://reintech.io/blog/karpenter-vs-cluster-autoscaler-comparison-2026

[2] Reintech - Reporte de ahorro de costos real de usuarios (20-40%)

[3] AWS Architecture Blog - How Salesforce migrated from Cluster Autoscaler to Karpenter
https://aws.amazon.com/blogs/architecture/how-salesforce-migrated-from-cluster-autoscaler-to-karpenter-across-their-fleet-of-1000-eks-clusters/

[4] AWS EKS Official Docs - Scale cluster compute with Karpenter and Cluster Autoscaler
https://docs.aws.amazon.com/eks/latest/userguide/autoscaling.html

[5] CHKK - Karpenter vs. Cluster Autoscaler
https://www.chkk.io/blog/karpenter-vs-cluster-autoscaler

[6] Reddit r/kubernetes - Feedback de pruebas de usuarios (latencia de nodos listos)
https://www.reddit.com/r/kubernetes/comments/zsmqrk/karpenter_vs_cluster_autoscaler_findings/

[7] AWS Blog - Using Amazon EC2 Spot Instances with Karpenter
https://aws.amazon.com/blogs/containers/using-amazon-ec2-spot-instances-with-karpenter/

[8] ScaleOps - Karpenter vs Cluster Autoscaler: Definitive Guide for 2025
https://scaleops.com/blog/karpenter-vs-cluster-autoscaler/

[9] Karpenter Official Docs - Migrating from Cluster Autoscaler
https://karpenter.sh/docs/getting-started/migrating-from-cas/