El costo oculto de la versión heredada del Cluster Autoscaler

Para entender por qué su clúster de EKS está perdiendo dinero, debe comprender la mecánica fundamental de cómo opera el Cluster Autoscaler estándar, y sus deficiencias en los entornos de nube modernos y dinámicos. 

CAS monitorea el servidor de la API de Kubernetes en busca de pods que no se pueden programar debido a limitaciones de recursos. Cuando detecta pods pendientes, calcula si añadir un nodo ayudará y luego ajusta la capacidad deseada (DesiredCapacity) de sus AWS Auto Scaling Groups. 

Esto introduce tres cuellos de botella críticos que impactan directamente el presupuesto de una startup en crecimiento:

1. El problema de los grupos de nodos rígidos

CAS depende completamente de los Node Groups, los cuales están respaldados por los ASG de AWS. Estos grupos casi siempre son homogéneos, lo que significa que están compuestos por instancias con proporciones idénticas de CPU y memoria (por ejemplo, todas m5.xlarge). 

Considere este escenario: Un pod requiere 1 vCPU y 2 GB de RAM para programarse. Sin embargo, su ASG está configurado para levantar instancias m5.2xlarge (8 vCPU, 32 GB de RAM). Debido a que CAS no detecta el catálogo de cómputo real de AWS y solo sabe cómo activar el ASG, inicia una instancia con una capacidad de cómputo enorme solo para alojar un pod diminuto. El resto de esos recursos se desperdicia, aunque usted pague la tarifa por hora completa. Para combatir esto, los equipos de DevOps se ven obligados a crear docenas de Node Groups altamente específicos para manejar diferentes perfiles de carga de trabajo, creando una pesadilla operativa fragmentada que es imposible de mantener de manera eficiente.

2. Empaquetamiento de contenedores ineficiente (El Tetris de Kubernetes)

La programación en Kubernetes es esencialmente un juego de Tetris gigante. Debido a que CAS está encadenado a las limitaciones de los ASG, tiene dificultades para jugar bien este juego. No analiza el tipo de instancia óptimo exacto en todo el catálogo de AWS para su combinación específica y en tiempo real de pods pendientes. En su lugar, activa a ciegas el ASG para incrementar su conteo.

¿El resultado? Un clúster lleno de instancias EC2 que permanecen inactivas entre un 30 % y un 40 % en cualquier momento, lo que genera una enorme reserva de cómputo pagada por su startup.

3. Programación lenta y el retraso en el inicio

La velocidad es una característica clave. Cuando un pod queda en estado pendiente bajo CAS, se desencadena una cadena de eventos dolorosamente lenta:

1. CAS detecta el pod pendiente.

2. CAS se comunica con la API de AWS para actualizar el ASG.

3. El ASG solicita una instancia a EC2.

4. EC2 asigna la instancia y esta se inicia.

5. La instancia se une al clúster a través del kubelet.

6. El nodo finalmente pasa a estar en estado `Listo` (Ready) y el pod se programa.

Este ciclo de vida suele tardar entre 2 y 4 minutos. En un entorno de alto tráfico y picos repentinos, esa latencia se traduce directamente en solicitudes caídas, degradación de la experiencia del usuario y un pipeline de CI/CD frágil.

Presentamos Karpenter: Aprovisionamiento Justo a Tiempo para la nube moderna

Desarrollado inicialmente por AWS y ahora un proyecto incubado en la Cloud Native Computing Foundation (CNCF), Karpenter representa un cambio de paradigma fundamental en el autoescalado de Kubernetes. Evita por completo los Auto Scaling Groups.

En lugar de gestionar Node Groups rígidos, Karpenter busca pods no programables, evalúa sus solicitudes exactas de recursos (CPU, memoria, GPU, topología de volumen y selectores de nodos) y realiza una llamada directa a la Amazon EC2 Fleet API. 

Por qué Karpenter es un cambio estructural para el FinOps de las startups

Arquitectura dinámica y sin grupos: Karpenter no está limitado por tipos de instancias predefinidos. Si tiene un grupo de pods pendientes que se adaptan perfectamente a una instancia r6g.xlarge (ARM Graviton), Karpenter aprovisionará exactamente esa instancia. Si el siguiente lote requiere una c6i.large optimizada para cómputo, iniciará esa en su lugar. Evalúa todo el catálogo de AWS en tiempo real.

Programación en menos de un minuto: Al eliminar al intermediario (el ASG) y aprovechar directamente la API EC2 Fleet, Karpenter aprovisiona y registra de forma rutinaria nuevos nodos EC2 en menos de 40 segundos. Esto transforma la manera en que su aplicación maneja los picos de tráfico.

Consolidación continua: Aquí es donde se producen los mayores ahorros de costos. Karpenter monitorea activamente el uso del clúster de forma continua. Si nota que las cargas de trabajo distribuidas en tres instancias mayormente vacías podrían caber cómodamente en una sola instancia más pequeña y económica, aislará, drenará y terminará con cuidado los nodos sobredimensionados, reemplazándolos con una sola instancia del tamaño adecuado. Este empaquetamiento (bin-packing) activo y automatizado garantiza que nunca pague por cómputo inactivo.

La mina de oro de las instancias Spot (Gestionada de forma segura)

Las instancias Spot ofrecen hasta un 90 % de descuento sobre los precios de EC2 bajo demanda, lo que las convierte en la solución ideal para reducir costos de nube. Pero tienen una condición: AWS puede reclamarlas con un aviso de advertencia de 2 minutos. 

Gestionar las interrupciones Spot con los ASG tradicionales y el AWS Node Termination Handler es complejo, frágil y a menudo genera interrupciones del servicio. Karpenter simplifica esto de forma nativa y elegante. 

Al integrarse directamente con Amazon SQS y Amazon EventBridge, Karpenter escucha las advertencias de interrupción Spot a nivel de la infraestructura de AWS. Cuando se recibe un aviso de terminación, Karpenter aísla instantáneamente el nodo que va a finalizar y comienza a aprovisionar un reemplazo antes de que el nodo original sea retirado, garantizando que sus servicios no sufran tiempo de inactividad.

Mezclar Spot y Bajo demanda en producción

Con la API NodePool de Karpenter, puede definir fácilmente reglas altamente específicas para determinar qué cargas de trabajo van a instancias Spot y cuáles a instancias Bajo demanda. 

Por ejemplo, puede configurar por defecto que todos los nodos de trabajo de su clúster utilicen instancias Spot, mientras usa selectores de nodos o etiquetas sencillos para garantizar que sus bases de datos con estado, cachés Redis o controladores de ingreso críticos se ubiquen siempre en instancias Bajo demanda de alta disponibilidad.

apiVersion: karpenter.sh/v1beta1

kind: NodePool

metadata:

  name: default-spot

spec:

  template:

    spec:

      requirements:

        - key: karpenter.sh/capacity-type

          operator: In

          values: ["spot"]

        - key: kubernetes.io/arch

          operator: In

          values: ["amd64", "arm64"]

        - key: karpenter.k8s.aws/instance-category

          operator: In

          values: ["c", "m", "r"]

  limits:

    cpu: 1000

  disruption:

    consolidationPolicy: WhenUnderutilized

    expireAfter: 720h # Recicla proactivamente los nodos cada 30 días para aplicar parches de seguridad

Esta configuración única permite a Karpenter elegir entre cientos de tipos de instancias posibles (combinando sin problemas arquitecturas Intel y Graviton basadas en ARM) en las familias de cómputo C, M y R. Seleccionará automáticamente en tiempo real la instancia Spot disponible más barata que mejor se adapte a los pods pendientes.

---

Un plan de migración con cero tiempo de inactividad

Migrar del antiguo Cluster Autoscaler a Karpenter no requiere una ventana de mantenimiento estresante, un equipo de migración gigante o una reconstrucción completa del clúster. Dado que los dos controladores funcionan de manera diferente, puede ejecutarlos en paralelo durante la transición. 

Este es el plan que utilizamos en Betta para llevar a cabo este proceso sin inconvenientes con nuestros clientes de startups:

Fase 1: Requisitos previos e IAM

1. Etiquetado de infraestructura: Asegúrese de que sus subredes y Grupos de seguridad de EKS estén etiquetados adecuadamente para que Karpenter sepa exactamente dónde y cómo iniciar nodos (por ejemplo, `karpenter.sh/discovery: su-nombre-de-cluster`).

2. IRSA (IAM Roles para cuentas de servicio): La seguridad es primordial. Cree un rol de IAM estrictamente definido para el controlador de Karpenter con permisos para administrar instancias EC2 y asócielo con una cuenta de servicio de Kubernetes mediante OIDC.

3. Integración de colas SQS: Configure la cola SQS y las reglas de EventBridge para la gestión nativa de interrupciones Spot para garantizar la estabilidad de la aplicación.

Fase 2: Despliegue y configuración

1. Desplegar el controlador: Instale Karpenter usando su chart oficial de Helm, asegurándose de configurarlo para usar el rol de IAM creado en la Fase 1.

2. Definir EC2NodeClass y NodePools: Despliegue su `EC2NodeClass` (que define las configuraciones específicas de AWS, como familias AMI, subnets y grupos de seguridad) y sus `NodePools` (que definen restricciones específicas de Kubernetes, como tipos de capacidad y familias de instancias).

Fase 3: Aislamiento y drenado (La transición)

En esta etapa, tanto CAS como Karpenter se ejecutan simultáneamente, pero administran recursos separados. Para transferir las cargas de trabajo de forma segura:

1. Añadir un Taint a los grupos de nodos antiguos: Aplique un taint `NoSchedule` a sus nodos de ASG existentes administrados por CAS. Esto evita que nuevos pods se alojen en la infraestructura antigua y costosa.

2. Provocar el escalado: A medida que elimina manualmente los pods en los nodos antiguos (o usa un script de drenado automatizado), esos pods pasarán a un estado `Pending`.

3. Karpenter toma el control: Dado que los nodos antiguos tienen un taint, CAS no puede usarlos para alojar los pods pendientes. Karpenter, sin embargo, detecta inmediatamente los pods pendientes, inicia instancias EC2 del tamaño exacto y optimizadas mediante la API Fleet y los programa en segundos.

4. Retirar CAS: Una vez que todos los nodos antiguos estén drenados y vacíos, reduzca la escala de sus ASG anteriores a `0`, elimine por completo los Node Groups antiguos y desinstale el despliegue del Cluster Autoscaler de su clúster.

Fase 4: Observabilidad y optimización

Después de la migración, es fundamental monitorear las decisiones de Karpenter. Al recopilar las métricas nativas de Prometheus de Karpenter (karpenter_nodes_created, karpenter_nodes_terminated, karpenter_pod_startup_time_seconds), su equipo puede visualizar en Grafana el ahorro de costos exacto y las mejoras en la velocidad de programación, demostrando el ROI del cambio a su junta directiva.

---

El impacto real: Cómo Betta transforma FinOps

En Betta nos especializamos en resolver estos cuellos de botella de infraestructura específicos para startups B2B en crecimiento. Recientemente, un cliente SaaS de Serie B acudió a nosotros con una factura de AWS en rápido crecimiento. Su equipo de ingeniería era increíblemente talentoso, pero estaba demasiado ocupado desarrollando características del producto para deshacer la compleja maraña de sus Node Groups estáticos y distribuidos en EKS. 

Al implementar Karpenter actuando como un equipo de SRE fraccionado, logramos lo siguiente en 30 días:

Reducción de la cantidad total de nodos en un 35 %: La consolidación activa de Karpenter eliminó la cantidad masiva de capacidad de CPU disponible por la que el cliente había estado pagando durante el último año.

Migración del 80 % de los entornos de no-producción a Spot: El aprovechamiento de la gestión nativa de interrupciones de Karpenter permitió un uso agresivo y seguro de instancias Spot para los pipelines de CI/CD y entornos de prueba sin interrumpir el ritmo de trabajo de los desarrolladores.

Reducción del 46 % en costos de cómputo de EKS: El efecto combinado del uso seguro de instancias Spot y el redimensionamiento continuo redujo casi a la mitad la factura total del clúster de EKS.

Aumento en la velocidad de despliegue: Los tiempos de programación de los pods disminuyeron de ~3.5 minutos a menos de 40 segundos, acelerando drásticamente el feedback para los desarrolladores y la escalabilidad horizontal durante picos de tráfico.

La ventaja del modelo fraccionado para startups en crecimiento

La ingeniería de plataformas y la optimización profunda de FinOps rara vez son proyectos de una sola vez, pero contratar a tiempo completo a un ingeniero especializado de FinOps de más de $200k o a un arquitecto especialista de Kubernetes para coordinar solo esta transición suele ser excesivo para una startup eficiente. 

Este es el valor del modelo fraccionado. Al incorporar expertos especializados para diseñar, ejecutar y documentar migraciones de gran impacto como la de Karpenter, protege el capital acumulado de su startup, elimina la deuda técnica y, lo más importante, mantiene a su equipo de ingeniería de tiempo completo enfocado completamente en su producto principal y en las funcionalidades que generan ingresos.

Deje de permitir que una infraestructura rígida y obsoleta determine su gasto en la nube. Las herramientas para consolidar clústeres de Kubernetes elásticos y de alta eficiencia de costos existen hoy en día; solo necesita el conocimiento adecuado para implementarlas con éxito.