Guías

Kubernetes-FinOps: Los mecanismos que reducen el 70 por ciento del desperdicio en los clústeres

Entre el 40 y el 70 por ciento de los recursos de Kubernetes se desperdician. Cuatro palancas cierran este desperdicio, empezando por el right-sizing.

Por Alec Chizhik 7 julio 2026 8 min de lectura

Kubernetes-FinOps: Los mecanismos que reducen el 70 por ciento del desperdicio en los clústeres

Entre el 40 y el 70 por ciento de los recursos de computación aprovisionados en Kubernetes permanecen sin utilizar. Si como ingeniero de plataforma no corriges las solicitudes, seguirás pagando por capacidad ociosa que ningún autoscaler puede optimizar. Los cuatro mecanismos clave siguen un orden fijo: el ajuste de tamaño adecuado (right-sizing) es el primero, todo lo demás se construye sobre esta base.

Por qué el right-sizing es el punto clave

Las solicitudes (requests) y los límites (limits) son la base sobre la que opera cada mecanismo posterior. Quien los ignora y pasa directamente a Karpenter o a instancias spot, optimiza sobre un fundamento defectuoso. El HPA escala con umbrales incorrectos. Karpenter proporciona tipos de nodos equivocados. Los pools de instancias spot se dimensionan mal. Sin solicitudes corregidas, ningún mecanismo posterior funciona correctamente.

El right-sizing corrige la definición en sí. Responde, para cada carga de trabajo, cuánta CPU y memoria se necesitan realmente, en lugar de guiarse por reglas generales o valores por defecto. El VPA en modo recomendación proporciona la base para ello -el modo automático no debería implementarse directamente en producción sin una estrategia de drenaje-. Quien ajusta las solicitudes trimestralmente frente a la utilización real cierra la mayor fuente de desperdicio antes de que entre en acción ningún autoscaler.

Escalar a cero con KEDA para cargas de trabajo basadas en eventos

KEDA amplía el Horizontal Pod Autoscaler con déclencheur externos como Kafka, SQS o RabbitMQ. Mientras que el HPA reacciona a umbrales de CPU o memoria, KEDA escala según la profundidad de la cola o la tasa de eventos y reduce a cero las cargas de trabajo en reposo. Para servicios que solo funcionan ante eventos, este es el mecanismo más limpio contra el consumo continuo en vacío.

KEDA no es una solución universal. Las APIs siempre activas con requisitos de latencia constantes no se benefician del escalado a cero, ya que el arranque en frío rompe los SLA. Su uso es rentable para servicios basados en eventos con fases claras de inactividad: trabajadores por lotes, procesamiento asíncrono, consumidores de webhooks. Quien utiliza KEDA donde el HPA sería la respuesta adecuada, paga con inestabilidad en lugar de con dinero.

Cluster Autoscaler o Karpenter: añadir nodos de forma dinámica

El Cluster Autoscaler está consolidado y opera sobre grupos de nodos. Añade nodos cuando los pods quedan en estado pendiente. Si la utilización disminuye, los retira. Karpenter aprovisiona nodos directamente sin la capa intermedia de grupos de nodos y es la opción más reciente y flexible para tipos de carga de trabajo dinámicos.

La elección depende de la estrategia del clúster y de la madurez del proveedor. Karpenter tiene soporte primario en EKS y está disponible en GKE en otra forma. Quien gestiona grupos de nodos fijos y una migración conservadora, se queda con el Cluster Autoscaler. Quien quiere mezclar dinámicamente tipos de nodos según los requisitos de la carga de trabajo gana en flexibilidad con Karpenter, algo que el Cluster Autoscaler, por diseño, no ofrece.

Máquinas virtuales spot y preemptible: el compromiso de riesgo

Las VM spot reducen considerablemente los costes en cargas de trabajo tolerantes a fallos, como lotes, runners de CI o workers asíncronos. El requisito es una tolerancia limpia a la preemption: PodDisruptionBudgets, apagado controlado (Graceful Shutdown) y distribución de réplicas en varios nodos. Quien no verifique este requisito, se arriesga a perder réplicas con cada oleada de preemption.

Las VM spot son rentables allí donde la pérdida repentina de un pod no rompe la aplicación. Los servicios stateful, las API críticas por latencia y las cargas de trabajo con réplica única no deben ejecutarse en spot. La separación clara por tipo de carga es el punto clave: un clúster que lo apueste todo a spot intercambia ahorro de costes por fiabilidad.

Orden y medición: qué debe aplicarse y cuándo

El orden no es opcional. Primero hay que crear la base de métricas (kube-metrics, recomendaciones de VPA), luego aplicar el Right-Sizing como fundamento. Sobre los valores corregidos actúan HPA y KEDA para el escalado de cargas. Karpenter o el Cluster-Autoscaler aprovisionan nodos según las necesidades de la carga. Las VM spot reducen costes en las cargas que toleran preemption. Los CUD y capas gestionadas como Autopilot son niveles de compromiso o comodidad que llegan al final.

Quien invierta este orden optimiza a ciegas. Usar spot sin requests corregidos afecta a las cargas equivocadas. Karpenter sin Right-Sizing despliega tipos de nodo incorrectos. La disciplina está en hacer primero el trabajo básico, algo que en Kubernetes rara vez es glamuroso, pero sí el mayor impulso económico.

Preguntas frecuentes

¿Cuándo usar KEDA en lugar de HPA?

Con disparadores externos como Kafka, SQS o RabbitMQ. HPA sigue siendo la opción adecuada para el escalado basado en CPU o memoria. KEDA solo vale la pena para cargas de trabajo dirigidas por eventos con fases claras de inactividad, no para API siempre activas con requisitos constantes de latencia.

¿Karpenter o Cluster-Autoscaler en GKE o EKS existentes?

Karpenter para tipos de nodo dinámicos y cuando el proveedor ofrece soporte principal (EKS). Cluster-Autoscaler para grupos de nodos fijos y migraciones conservadoras. La decisión depende de la estrategia del clúster, no del gusto personal.

¿Es seguro el modo recomendación de VPA?

Sí, para la medición inicial del uso real de recursos. El modo automático no debe aplicarse directamente en producción sin una estrategia de drenaje. El modo recomendación proporciona la base de datos para un Right-Sizing limpio, sin afectar activamente a los pods.

¿Son realistas los porcentajes del 70 % de desperdicio o es marketing?

Es un rango del 40 al 70 %, no una cifra fija. Su clúster puede estar en cualquier punto de ese intervalo. Mida la utilización real frente a los requests antes de adoptar un dato de un estudio: es una orientación, no un diagnóstico.

¿Vale la pena Goldilocks como herramienta para Right-Sizing?

Goldilocks visualiza las recomendaciones de VPA como propuestas de Resource-Requests y es un buen punto de partida si aún no tiene su propia canalización de métricas. En entornos maduros, suele bastar con VPA en modo recomendación más un ritmo trimestral de revisión frente a la utilización real.