Todos los equipos de infraestructura acaban enfrentándose a la misma pregunta: ¿por qué es tan alta nuestra factura de Kubernetes? La respuesta es casi siempre la misma — el sobreaprovisionamiento. Los ingenieros solicitan más CPU y memoria de la que las cargas de trabajo necesitan realmente, los autoescaladores están configurados de forma demasiado agresiva y nadie tiene un proceso sistemático de right-sizing.
El resultado son clústeres funcionando con un 15-25% de utilización real mientras pagas por el 100%.
La Site Reliability Engineering te da el marco para arreglarlo sin romper nada. Las prácticas SRE conectan directamente la optimización de costes con la fiabilidad — así no recortas costes a ciegas, sino que eliminas desperdicio manteniendo los niveles de servicio de los que dependen tus usuarios.
Estas son siete prácticas SRE que reducen sistemáticamente los costes de Kubernetes.
1. Ajusta el tamaño de los resource requests
La mayor fuente de desperdicio de costes en Kubernetes son los resource requests incorrectos. Los ingenieros fijan los requests de CPU y memoria a ojo y nunca los vuelven a revisar. Un contenedor que solicita 2 núcleos de CPU pero consume de media 200 milicores desperdicia el 90% de los recursos asignados.
Cómo solucionarlo:
Analiza el uso real de recursos en una ventana de 14 días. Compara el uso P95 con los requests actuales. Cualquier contenedor cuyo request sea más de 2x el uso P95 es candidato a right-sizing.
La fórmula es sencilla: fija los requests de CPU en el uso P95 más un margen del 20%. Fija los requests de memoria en el uso máximo observado más un margen del 15% (la memoria es menos elástica que la CPU — quedarse corto provoca OOMKills).
Herramientas como el Vertical Pod Autoscaler (VPA) de Kubernetes en modo recomendación pueden automatizar este análisis en todo tu clúster. Plataformas como SRExpert ofrecen analítica de recursos a nivel de carga de trabajo que muestra recomendaciones de optimización en varios clústeres a la vez — indicándote exactamente qué deployments están sobreaprovisionados y en cuánto.
Impacto esperado: reducción del 30-50% de los recursos solicitados, lo que se traduce directamente en menos nodos necesarios.
2. Usa el Cluster Autoscaler con nodos del tamaño adecuado
El Cluster Autoscaler añade y elimina nodos en función de los pods pendientes, pero solo funciona bien si tus node pools tienen el tamaño correcto. Usar un único tipo de nodo (p. ej., m5.2xlarge para todo) garantiza casi con seguridad el desperdicio.
Cómo solucionarlo:
Crea varios node pools optimizados para distintos tipos de carga de trabajo. Las cargas intensivas en CPU van a instancias optimizadas para cómputo. Las bases de datos con mucha memoria van a instancias optimizadas para memoria. Los jobs batch van a instancias spot o preemptible.
Configura el Cluster Autoscaler con umbrales de reducción adecuados. Por defecto, reduce los nodos que están por debajo del 50% de utilización durante 10 minutos. Para optimizar costes, puedes bajarlo con seguridad al 40% de utilización y 5 minutos en las cargas de trabajo no críticas.
Activa el flag --balance-similar-node-groups para distribuir los pods de forma equilibrada entre zonas de disponibilidad y evitar que una zona tenga nodos casi vacíos.
Impacto esperado: reducción del 15-25% en el coste de los nodos gracias a un mejor bin-packing y a un mejor ajuste del tipo de instancia.
3. Define y aplica cuotas de recursos
Sin cuotas de recursos, cualquier namespace puede consumir recursos ilimitados del clúster. Un deployment descontrolado de un equipo puede inflar tu factura cloud en miles de dólares antes de que nadie se dé cuenta.
Cómo solucionarlo:
Define ResourceQuotas en cada namespace. Establece límites para el total de requests de CPU, el total de requests de memoria y el número de pods. Basa estas cuotas en las necesidades reales de cada equipo más un margen de crecimiento del 30%.
Implanta LimitRanges para fijar requests y limits por defecto en los pods que no los especifican. Esto evita el patrón habitual de desplegar pods sin resource requests — lo que hace que el scheduler los trate como pods sin recursos cuando en realidad consumen recursos significativos.
Usa una plataforma de gestión unificada que ofrezca dashboards de cuotas de recursos entre clústeres. Esto te da visibilidad sobre qué equipos se están acercando a sus cuotas y cuáles tienen una asignación significativa sin usar que podría recuperarse.
Impacto esperado: evita los picos de coste descontrolados y crea responsabilidad por equipo.
4. Aprovecha las instancias spot y preemptible
Las instancias spot cuestan un 60-90% menos que las instancias on-demand. La contrapartida es que el proveedor cloud puede recuperarlas con un aviso mínimo. Para cargas de trabajo stateless con la redundancia adecuada, esta contrapartida casi siempre merece la pena. Mira cómo redujimos un 47% la factura de Kubernetes de un cliente con instancias spot.
Cómo solucionarlo:
Identifica las cargas de trabajo que toleran interrupciones: jobs batch, runners de CI/CD, entornos de desarrollo, servicios web stateless con varias réplicas y pipelines de procesamiento de datos.
Usa node affinity y taints para programar estas cargas de trabajo exclusivamente en nodos spot. Ejecuta las cargas críticas (bases de datos, servicios stateful, deployments de una sola réplica) en nodos on-demand.
Implanta pod disruption budgets (PDBs) para que las terminaciones de spot no tumben todas las réplicas a la vez. Un PDB con maxUnavailable: 1 garantiza que al menos N-1 réplicas sigan disponibles durante la recuperación de instancias spot.
Configura varios tipos de instancia en tus node pools de spot. La disponibilidad de spot varía según el tipo de instancia — usar 5-10 tipos distintos reduce drásticamente la frecuencia de interrupciones.
Impacto esperado: reducción de costes del 40-70% en las cargas de trabajo elegibles, que suelen representar el 30-50% del total de recursos del clúster.
5. Implanta políticas de escalado automatizadas
El Horizontal Pod Autoscaler (HPA) evita tanto el sobreaprovisionamiento (demasiadas réplicas) como el infraaprovisionamiento (réplicas insuficientes), pero la mayoría de los equipos o no lo usan o lo configuran mal.
Cómo solucionarlo:
Configura HPA en cada deployment stateless. Usa la utilización de CPU como métrica principal, con un objetivo del 65-75%. Esto deja margen suficiente para los picos de tráfico y evita réplicas ociosas.
Para un escalado más sofisticado, usa métricas personalizadas de Prometheus. Escala en función de la tasa de peticiones, la profundidad de la cola o métricas específicas del negocio en lugar de la CPU en bruto. Un deployment que procesa mensajes de una cola debería escalar según la longitud de la cola, no según la utilización de CPU.
Configura ventanas de estabilización adecuadas. La estabilización por defecto para reducir es de 5 minutos — auméntala a 10-15 minutos en las cargas de trabajo de producción para evitar oscilaciones rápidas de escalado durante las fluctuaciones de tráfico.
Las plataformas SRE con integración de monitorización pueden analizar tus patrones de escalado y recomendar configuraciones óptimas de HPA a partir de los patrones históricos de tráfico, eliminando las conjeturas en el ajuste del autoescalador.
Impacto esperado: reducción del 20-35% del número medio de réplicas manteniendo los SLOs de tiempo de respuesta.
6. Programa las cargas no críticas fuera del horario de máxima demanda
Los entornos de desarrollo, los clústeres de staging, los pipelines de CI/CD y el procesamiento batch no necesitan funcionar 24/7. Ejecutarlos solo en horario laboral reduce su coste en un 65%.
Cómo solucionarlo:
Usa CronJobs o schedulers externos para escalar a cero réplicas los namespaces que no son de producción fuera del horario laboral. Un CronJob sencillo que ejecute kubectl scale deployment --replicas=0 -n staging --all a las 7 de la tarde y vuelva a escalar a las 8 de la mañana ahorra 13 horas de cómputo al día.
Para los clústeres de desarrollo, plantéate usar la capacidad de escalar a cero del Cluster Autoscaler. Cuando todos los deployments de desarrollo están escalados a cero, el autoescalador elimina por completo los nodos subyacentes — no pagas nada hasta que los desarrolladores empiezan su jornada.
Implanta políticas de programación a nivel de namespace que apliquen automáticamente estos patrones. Las plataformas de operaciones pueden automatizarlo con una programación basada en políticas que respete las diferencias horarias entre equipos distribuidos.
Impacto esperado: reducción de costes del 50-65% en las cargas de trabajo que no son de producción.
7. Monitoriza las métricas de coste como SLIs
SRE trata todo como medible. El coste no debería ser distinto. Si no sigues la eficiencia de costes como un Service Level Indicator, no puedes optimizarla de forma sistemática.
Cómo solucionarlo:
Define SLIs de eficiencia de costes: coste por petición, coste por transacción, coste por cliente o coste por carga de trabajo. Síguelos a lo largo del tiempo junto a tus SLIs de fiabilidad.
Crea dashboards de Grafana que muestren las tendencias de coste junto a las métricas de rendimiento. Cuando el coste por petición aumente, investiga si se debe a cambios en el tráfico, a desperdicio de recursos o a cambios de precio en la infraestructura.
Configura alertas de coste con tu stack de monitorización. Si el coste de un namespace aumenta más de un 20% de una semana a otra sin un aumento equivalente del tráfico, dispara una alerta para investigarlo.
Usa plataformas que ofrezcan visibilidad de costes integrada junto a la salud de las cargas de trabajo. Las mejores herramientas de gestión de Kubernetes correlacionan el uso de recursos con el gasto cloud real, para que veas exactamente qué deployments están provocando los aumentos de coste y tomes decisiones de optimización basadas en datos.
Impacto esperado: mejora continua. Los equipos que siguen las métricas de coste reducen el gasto un 10-15% trimestre a trimestre mediante optimizaciones incrementales.
Cómo encaja todo
Estas siete prácticas no son independientes — se refuerzan entre sí. Ajustar el tamaño de los recursos significa menos nodos. Menos nodos con instancias spot significa un coste por nodo drásticamente menor. El autoescalado evita el sobreaprovisionamiento cuando hay poco tráfico. La programación fuera del horario de máxima demanda elimina el desperdicio durante las noches y los fines de semana. Y los SLIs de coste garantizan que las mejoras se mantienen.
Un entorno de Kubernetes típico que implanta las siete prácticas reduce el gasto cloud un 40-60% en un trimestre.
La idea clave de SRE es que la optimización de costes no es un proyecto puntual — es una práctica continua. Los patrones de uso de recursos cambian a medida que evoluciona tu aplicación. Se despliegan nuevos servicios. Los patrones de tráfico cambian. Sin monitorización y optimización continuas, los costes vuelven a subir poco a poco.
Integra estas prácticas en tu cultura SRE, mídelas de forma consistente y trata la eficiencia de costes como una preocupación de ingeniería de primer nivel, al mismo nivel que la fiabilidad, la latencia y la disponibilidad. Tu factura cloud — y tu CFO — te lo agradecerán.
¿Quieres ver tus oportunidades de optimización de costes en Kubernetes? SRExpert ofrece analítica de recursos a nivel de carga de trabajo, recomendaciones de optimización y visibilidad de costes en todos tus clústeres. Pruébalo gratis o habla con nuestro equipo sobre una evaluación de optimización de costes.