¿Por qué Kubernetes dispara tu factura si no lo controlas?
Kubernetes es extraordinariamente capaz. Te permite orquestar contenedores, escalar servicios, gestionar redes y desplegar en multi-cloud. Pero si no configuras correctamente los recursos que cada workload solicita, tu clúster se convierte en una máquina de gasto innecesario.
Los números del 2026 State of Kubernetes Optimization Report son contundentes: el 69% de los clústeres sobreaprovisionan CPU, el 79% sobreaprovisiona memoria, y la utilización promedio de CPU en producción es del 8%. Esto significa que pagas por reservar recursos, no por usarlos. Y Kubernetes, por defecto, no te protege de ti mismo.
Entendiendo las cuatro capas de desperdicio
Para optimizar costos en Kubernetes, primero debes identificar en qué capa se produce el gasto innecesario. Estas son las cuatro principales:
- Pods sobreaprovisionados: Solicitudes (requests) de CPU/memoria muy por encima del consumo real. Es la causa más común y la más fácil de corregir.
- Nodos sobredimensionados: Instancias EC2/GCE más grandes de lo necesario para la carga real del clúster.
- Precio on-demand innecesario: Workloads stateless ejecutándose en instancias on-demand cuando podrían usar spot instances con hasta 70% de descuento.
- GPUs ociosas: GPUs reservadas pero infrautilizadas, un problema creciente con la adopción de AI/ML en producción.
Rightsizing: el ajuste más rentable
El rightsizing —ajustar requests y limits de cada pod a su consumo real— sigue siendo la palanca de ahorro más confiable en 2026. No requiere cambiar la arquitectura ni migrar workloads. Solo datos y voluntad de actuar.
La mayoría de equipos cometen el mismo error: configuran requests basándose en estimaciones durante el desarrollo. Un microservicio que consume 200m CPU en promedio puede tener un request de 1 CPU "por si acaso". Ese margen de seguridad, multiplicado por cientos de pods, representa decenas de miles de dólares al año.
El flujo correcto es:
- Instalar un agente de métricas (Metrics Server, Prometheus) y recolectar datos históricos de consumo.
- Analizar percentiles P50, P95 y P99 de CPU/memoria por workload.
- Ajustar requests al percentil P85-P95, y limits al doble del request.
- Establecer un VPA (Vertical Pod Autoscaler) en modo "recommender" inicialmente.
- Automatizar la aplicación de recomendaciones tras un período de observación de 7 días.
Autoscaling: horizontal vs vertical
El autoscaling complementa al rightsizing. No tiene sentido ajustar recursos si luego el clúster no escala según demanda. Dos enfoques principales:
Horizontal Pod Autoscaler (HPA)
Escala réplicas según métricas de CPU/memoria o métricas personalizadas (RPS, latencia, longitud de cola). Es el mecanismo más usado y funciona bien para workloads stateless con patrones de tráfico predecibles.
Configuración recomendada: targetUtilization al 60-70% para CPU, con un mínimo de 2 réplicas y máximo según presupuesto. Usa métricas personalizadas para servicios sensibles a latencia.
Vertical Pod Autoscaler (VPA)
Ajusta requests y limits de pods existentes sin cambiar el número de réplicas. Ideal para workloads stateful (bases de datos, colas) donde escalar horizontalmente es complejo.
Modos de operación: "off" (solo recomienda), "auto" (aplica cambios con recreación de pods), "initial" (solo aplica en creación). Recomiendo empezar en "off" y migrar a "auto" con disruption budgets.
Cluster Autoscaler / Karpenter
Escala la cantidad de nodos del clúster. Karpenter ha ganado tracción en 2026 por su capacidad de aprovisionar instancias de diferentes familias según las necesidades de los pods, optimizando el packing y reduciendo nodos infrautilizados.
Estrategia de automatización FinOps
La optimización manual no escala. Los equipos que logran mantener costos bajo control en 2026 tienen algo en común: automatización de ciclo cerrado.
- Insight → acción: Las herramientas que solo visualizan costos (dashboards) no reducen la factura. Necesitas plataformas que automaticen cambios basados en las métricas.
- Políticas de gobernanza: Define límites por namespace, equipo o entorno. Bloquea deployments que excedan ciertos thresholds de CPU/memoria sin aprobación.
- Spot instances para workloads batch: Workers de scraping, procesamiento nocturno, CI/CD y training de modelos pueden ejecutarse en spot con ahorros de hasta 70%.
- Presupuestos mensuales por equipo: Implementa chargeback/showback real. Cuando los equipos ven su propio gasto, la optimización ocurre naturalmente.
Errores comunes y cómo evitarlos
- Overprovisioning "por seguridad": Requests altos no mejoran la resiliencia. Usa limits para proteger vecinos ruidosos y requests realistas basados en datos históricos.
- Autoscaling sin cooling period: Configura períodos de estabilización (30-60 segundos) para evitar thrashing y costos de escalado innecesarios.
- Ignorar costos de egress: El tráfico entre clouds es caro. Mantén workloads y datos en la misma región siempre que sea posible.
- Multi-cloud como default: Usa multi-cloud para resiliencia y requerimientos regulatorios, no como estrategia de ahorro. Casi nunca es más barato.
Herramientas recomendadas para 2026
- Cast AI: Plataforma autónoma de optimización con rightsizing continuo, spot automation y análisis multi-cloud.
- Kubecost + OpenCost: Visibilidad granular de costos por namespace, deployment y label. Bueno para chargeback/showback.
- Karpenter: Node lifecycle manager que selecciona instancias óptimas para cada pod, reduciendo nodos infrautilizados.
- VPA + Goldilocks: Goldilocks envuelve VPA con una UI para visualizar recomendaciones de recursos.
- CloudZero: Enfoque en cost allocation basado en unidades de negocio, no en infraestructura.
Conclusión
La optimización de costos en Kubernetes en 2026 ya no es una limpieza única. Es un proceso continuo que combina rightsizing, autoscaling inteligente, automatización de ciclo cerrado y gobernanza por equipo. Las herramientas de solo visibilidad ya no son suficientes: necesitas plataformas que automaticen las decisiones de optimización.
Empieza por medir tu utilización real, ajusta requests basándote en datos históricos, implementa autoscaling progresivo, y automatiza todo lo que pueda ser automatizado. Los resultados —entre 50% y 75% de reducción en costos de infraestructura— hablan por sí solos.