Cómo Autoescalar en Kubernetes de forma eficiente con KEDA & Karpenter

Aprende a optimizar costes en Amazon EKS combinando KEDA y Karpenter. Miguel Fontanilla (Sender) explica cómo lograr un 40% de ahorro.

Durante la reciente edición del SpainClouds Summit, uno de los temas más destacados fue la optimización de costes y eficiencia en arquitecturas orientadas a eventos dentro de Amazon EKS. La sesión estuvo a cargo de Miguel Fontanilla, Arquitecto Profesional de Amazon, AWS Community Builder y actual líder del equipo de plataforma en la nube de Sender.

Fontanilla desgranó cómo su equipo logró reducir costes en un 40% y mejorar drásticamente la respuesta ante picos de tráfico implementando una estrategia combinada de KEDA y Karpenter. A continuación, te contamos los puntos clave de su intervención técnica.

Desafíos en Arquitecturas Orientadas a Eventos

Para entender la solución, primero debemos entender el problema. Sender opera como un «Uber para camiones», un marketplace logístico digital cuyo tráfico varía enormemente: muy alto durante horas de oficina y muy bajo por las noches y fines de semana.

Su arquitectura se basa en Amazon EKS (Kubernetes), Lambda y un bus de eventos principal con Kafka. Inicialmente, utilizaban las herramientas estándar de escalado:

HPA (Horizontal Pod Autoscaler) para los workloads.
Cluster Autoscaler para los nodos.

Sin embargo, este enfoque presentaba limitaciones críticas:

Métricas insuficientes: El HPA tradicional se basa en promedios de CPU y memoria. En una arquitectura de eventos, esto es ineficiente; se necesita escalar según la longitud de una cola en Kafka o SQS, no solo por uso de procesador.
Imposibilidad de escalar a cero: Si no hay eventos en un tópico de Kafka, el HPA estándar no puede apagar completamente los pods, generando un gasto innecesario.
Ineficiencia en los nodos:El Cluster Autoscaler tradicional es lento, no es topology-aware por defecto (problemas con volúmenes zonales) y complica la gestión de instancias híbridas (Spot y On-Demand) al requerir múltiples Auto Scaling Groups.

Solución 1: KEDA para el Escalado de Workloads

Para resolver la parte de los contenedores, Fontanilla explicó la implementación de KEDA (Kubernetes Event-Driven Autoscaler). Esta herramienta no sustituye al HPA, sino que lo «vitaminiza», añadiendo un ciclo de control que alimenta al HPA con métricas externas.

Beneficios clave de KEDA explicados por el experto:

Escalado basado en eventos reales: Permite escalar basándose en el lag de un tópico de Kafka, mensajes en SQS o métricas de Datadog, en lugar de solo CPU.
Scale-to-Zero: KEDA permite que, si no hay trabajo pendiente, el número de réplicas baje a cero, eliminando el consumo de recursos ocioso.
Flexibilidad con CRDs: Utiliza Custom Resource Definitions como ScaledObject y TriggerAuthentication, lo que facilita la configuración de autenticación contra distintos proveedores (AWS, Kafka, etc.).

Es posible configurar un ScaledObject que escale tanto por el lag de Kafka como por el uso de CPU, logrando una inteligencia de escalado mucho más granular.

Solución 2: Karpenter para el Escalado de Nodos

La segunda pieza del puzle es Karpenter, un proyecto open source iniciado por AWS que revoluciona el aprovisionamiento de nodos al eliminar la necesidad de grupos de autoescalado (Auto Scaling Groups).

¿Por qué Karpenter supera al Cluster Autoscaler? Según explicó el líder de plataforma de Sender, Karpenter observa los pending pods y llama directamente a la API de EC2 Fleet para aprovisionar exactamente la capacidad necesaria.

Sin Auto Scaling Groups: Simplifica la gestión al no tener que pre-crear grupos para cada tipo de instancia.
Soporte nativo para instancias Spot: Mediante el uso de selectores en los NodePools, Karpenter puede solicitar instancias Spot (más baratas) y, si no hay disponibilidad, recurrir automáticamente a On-Demand, todo definido en un solo bloque de configuración YAML.
Consolidación Inteligente: Karpenter detecta si hay nodos infrautilizados y puede mover los pods a un nodo más barato o consolidarlos para apagar máquinas sobrantes, optimizando el coste continuamente.

Es posible configurar un ScaledObject que escale tanto por el lag de Kafka como por el uso de CPU, logrando una inteligencia de escalado mucho más granular.

La Arquitectura de Seguridad: "El huevo y la gallina"

La implementación de esta arquitectura híbrida (KEDA + Karpenter) en Sender arrojó resultados tangibles que Fontanilla compartió con métricas reales:

Reducción de Costes: Lograron reducir la factura de computación en un 40%.
Uso de Spot: Incrementaron el uso de instancias Spot casi 8 veces, aprovechando los descuentos de AWS sin sacrificar disponibilidad gracias a la rapidez de Karpenter.
Velocidad de Reacción: El sistema responde a eventos en menos de 10 segundos (a veces menos de 5), garantizando un escalado rápido ante picos de demanda.
Eficiencia en Desarrollo: Los entornos no productivos escalan a cero absoluto durante los fines de semana, reduciendo el coste a mínimos.

Recibe nuestra Newsletter de Cloud semanal

Recomendación Final para Implementar Karpenter

Para cerrar, el ponente enfatizó un requisito técnico indispensable: definir correctamente los «Resource Requests». Dado que Karpenter toma decisiones de aprovisionamiento basándose en lo que los pods «piden», si los desarrolladores solicitan más CPU/RAM de la necesaria, Karpenter sobre-aprovisionará nodos, encareciendo la factura.

SmartClouds

SmartClouds helps businesses get in front of the right technical audience. We are experts in content creation and community management. We’ll help you showcase your products and the problems you solve.