Optimización de costes de Kubernetes: 8 pasos, 23 herramientas y casos prácticos
Los clústeres de Kubernetes pueden parecer totalmente saludables mientras la factura sube. La escalabilidad automática está configurada, los paneles están en verde y el gasto aumenta de todos modos. En una encuesta, el 42 % de los 455 ingenieros de plataformas señaló el coste como su principal desafío de Kubernetes, mientras que el 88 % vio aumentar el coste total de propiedad año tras año.1
Recopilamos 68 casos prácticos de optimización de costes de Kubernetes y asignamos cada caso de uso mencionado a cada proveedor que lo publicó:
Las celdas más oscuras significan más menciones. Las celdas vacías significan que esa herramienta no tiene ningún caso publicado para ese caso de uso.
Sigue leyendo para ver una guía de 8 pasos con ejemplos reales para reducir el gasto en clústeres y la comparación de la herramienta de optimización de costes de Kubernetes.
1. Mide antes de cambiar nada
Todos los números del resto de esta guía son un delta, y un delta necesita un punto de partida. Sin una línea base capturada antes del primer cambio, no hay forma de saber si el paso 1 funcionó ni de atribuir los ahorros del paso 3 a la consolidación en lugar de al redimensionamiento que lo precedió. Esto importa más aquí que en la mayoría del trabajo de ingeniería, porque las seis acciones reducen la misma factura y sus ahorros no se suman. Liberar capacidad en el paso 1 no produce nada en la factura hasta que el paso 3 elimina los nodos.
Mide cuatro cosas:
- CPU y memoria solicitados frente a utilizados, por carga de trabajo. La diferencia es tu trabajo pendiente del paso 1, ordenado por tamaño.
- Coste por espacio de nombres y por carga de trabajo. Esto es lo que convierte las cuotas del paso 2 en una negociación y no en una imposición.
- Eficiencia de bin packing, asignable frente a solicitado por nodo. Es el objetivo del paso 3.
- Coste en inactividad por hora del día y día de la semana en entornos no productivos. Dimensiona el paso 5 antes de que lo construyas.
Mide a lo largo de al menos un ciclo de negocio completo. Siete días es el mínimo y treinta es mejor. El periodo no es una precaución de procedimiento. El paso 1 establece las solicitudes de memoria en el máximo observado, y un máximo observado solo es tan bueno como el periodo que lo observó. Un máximo tomado durante 48 horas omite un trabajo por lotes semanal y provoca un OOMKill el domingo siguiente.
Herramientas
- Asignación de costes: OpenCost, el proyecto de CNCF que hay detrás del modelo de asignación, es la base gratis. El nivel gratis de Kubecost envuelve el mismo motor en una interfaz de usuario hasta 250 núcleos.
- Utilización: Prometheus con kube-state-metrics es el sustrato. Robusta KRR lo lee directamente sin instalar nada dentro del clúster.
- Gasto más amplio: Cuando Kubernetes es una parte de una factura que finanzas también tiene que explicar, CloudZero, Vantage y Finout se sitúan por encima de esta capa en lugar de reemplazarla.
Ambas herramientas de costes atribuyen por etiquetas, así que el etiquetado es lo primero. El gasto sin etiquetar es la razón más habitual por la que una línea base resulta inútil tres semanas después.
Cada acción a continuación indica la recomendación, el método, la configuración y una empresa que dio ese paso. Cada caso práctico y cada estadística incluye un enlace a la fuente.
2. Establece cuotas de espacio de nombres como barreras de protección
Los ahorros disminuyen cuando los equipos despliegan nuevas cargas de trabajo sin solicitudes especificadas. Un LimitRange proporciona solicitudes predeterminadas a los contenedores que las omiten, y una ResourceQuota limita lo que un espacio de nombres puede consumir en total.
Despliega el LimitRange antes que la ResourceQuota. Una vez que una cuota restringe un recurso, cualquier pod sin una solicitud para ese recurso se rechaza en la admisión, de modo que el orden inverso rompe los despliegues.2
El proveedor de la nube factura cada balanceador de carga por separado, y los volúmenes huérfanos siguen facturando después de que sus pods desaparezcan.
2. Redimensiona las solicitudes de CPU y memoria
Las solicitudes determinan el número de nodos, y el número de nodos determina la factura. La mayoría de los clústeres funcionan muy por debajo de la capacidad que pagan, porque las solicitudes se estimaron una vez y nunca se revisaron. Un análisis de 23.000 clústeres de producción en AWS, Azure y Google Cloud encontró una utilización media de CPU del 8 %, de memoria del 20 % y de GPU del 5 %. 3
Establece las solicitudes de CPU cerca del percentil 95 del uso observado. Establece las solicitudes de memoria en el máximo observado y no en un percentil, y establece el límite de memoria igual a la solicitud. Un percentil deja al contenedor corto durante el tráfico restante y, como el límite coincide con la solicitud, esa carencia se manifiesta como un OOMKill y no como una ralentización.
Omite el límite de CPU. La limitación de CPU degrada la latencia sin matar el pod, y la solicitud ya reserva lo que la carga de trabajo necesita.
El Vertical Pod Autoscaler en modo de solo recomendación produce estas cifras sin riesgo para producción.
Lee las recomendaciones con kubectl describe vpa payments-api y compara el valor objetivo con la solicitud actual.
Caso práctico real: Tryg Insurance
Tryg Insurance es la mayor aseguradora general de la región nórdica y ejecuta Kubernetes en Oracle Cloud Infrastructure. Su equipo de ingeniería combinó el Horizontal Pod Autoscaler y el Vertical Pod Autoscaler para redimensionar las cargas de trabajo de forma dinámica manteniendo los niveles de servicio, y redujo los costes de nube de Kubernetes en un 50 % usando únicamente autoescaladores de código abierto, sin ninguna plataforma comercial de optimización.4
4. Consolida nodos con Karpenter y escala a cero las cargas de trabajo inactivas
El redimensionamiento libera capacidad, pero esa capacidad permanece en nodos que siguen funcionando hasta que algo los elimina. Karpenter aprovisiona instancias justo a tiempo y reubica las cargas de trabajo en menos nodos. KEDA reduce a cero réplicas las cargas de trabajo basadas en colas, algo que un Horizontal Pod Autoscaler estándar no puede hacer.
Establece la política de consolidación en WhenEmptyOrUnderutilized. La alternativa, WhenEmpty, restringe la interrupción a nodos que no alojan ningún pod de carga de trabajo, algo que rara vez ocurre sin intervención. 5
Una lista estrecha de instancias lo impide, porque Karpenter no puede encontrar opciones económicas atípicas y tu resiliencia de spot disminuye. Deberías dejar que elija entre familias de instancias completas.
Caso práctico real: Adidas
Adidas ejecuta varios clústeres de Kubernetes en AWS EKS. Su equipo de ingeniería de plataformas adoptó Karpenter para el aprovisionamiento de nodos, añadió KEDA para el escalado basado en eventos, creó automáticamente objetos de Vertical Pod Autoscaler mediante políticas de Kyverno y usó kube-downscaler para entornos inactivos. Redujeron el coste de ejecutar sus clústeres de Kubernetes en AWS hasta en un 50 % usando una pila totalmente de código abierto.6
5. Prepárate adecuadamente antes de mover cargas de trabajo a spot
Las instancias spot ofrecen el mayor descuento disponible y la aplicabilidad más limitada. No se debe mover nada a spot hasta que estén preparados los PodDisruptionBudgets, la diversificación de instancias, la distribución topológica y la gestión de terminaciones.
Un PodDisruptionBudget que no deja margen bloquea toda interrupción voluntaria, incluida la consolidación de Karpenter, por lo que los valores necesitan holgura. 7
Caso práctico real: Delivery Hero
Delivery Hero opera 390 aplicaciones en 43 países, con aproximadamente el 90 % de las cargas de trabajo ejecutándose en AWS EKS. Su equipo migró a instancias spot a lo largo de unos seis meses, incorporando al proceso la gestión de terminaciones y un descheduler en lugar de cambiar directamente el tipo de capacidad.
- Los costes de infraestructura cayeron alrededor de un 70 %.
- Los descuentos de spot alcanzaron hasta un 90 % frente a los precios bajo demanda.
- La plataforma absorbe picos de tráfico de 4 a 5 veces el volumen normal.8
6. Apaga los entornos no productivos según un horario
Los entornos de desarrollo y staging llevan poca o ninguna carga por la noche y los fines de semana. El apagado programado es técnicamente sencillo y no genera controversia, lo que lo convierte en el ahorro más rápido de entregar y en una primera acción útil cuando los cambios más difíciles necesitarán apoyo después.
Aplica el horario de forma predeterminada en todos los espacios de nombres no productivos y exige a los equipos que se excluyan explícitamente. Una política que exige actuar para participar llega a menos equipos que una que exige actuar para salir.
El ahorro solo llega a la factura si la consolidación de nodos ya está en marcha, porque los despliegues reducidos dejan nodos vacíos.
Caso práctico real: Bud Financial
Bud Financial enriquece datos de transacciones financieras para el sector de servicios financieros y ejecuta aproximadamente 25 clústeres en Google Kubernetes Engine. Su equipo utilizó la pausa y reanudación programadas para reducir los nodos de los clústeres por la noche y los fines de semana, junto con un reequilibrado diario.
- Los costes cayeron un 47 % solo con el cambio de programación.
- El horario eliminó 80 horas de funcionamiento del clúster por semana.
- La utilización de recursos subió por encima del 90 %.9
7. Migra las cargas de trabajo compatibles a ARM
Las instancias basadas en ARM cambian el precio unitario en lugar de competir por la misma capacidad inactiva que las acciones anteriores, por lo que estos ahorros se suman de verdad al resto. Los bloqueadores serán las dependencias sin compilaciones para ARM64.
Los usuarios deberían aplicar esto carga por carga en lugar de en toda la infraestructura, y crear imágenes multiarquitectura antes de programar nada.
Caso práctico real: Pinterest
Pinterest migró su carga de trabajo de API web a instancias AWS Graviton que se ejecutan en ARM64, motivado tanto por la reducción de costes como de carbono.
- Los costes cayeron un 47 %.
- El consumo de cómputo cayó un 38 %.
- Las emisiones de carbono cayeron un 62 %.10
8. Cuando el ajuste se agota, cambia la arquitectura
Las seis acciones anteriores ajustan las cargas de trabajo dentro de los clústeres existentes. Una vez agotadas, obtener más mejoras exige un cambio arquitectónico en lugar de más ajustes.
Hay dos resultados publicados que marcan el límite práctico. InCred Finance redujo el gasto un 30 % en clústeres que su equipo ya consideraba optimizados11, y Yotpo consiguió un 30–40 % mientras ya ejecutaba el 80 % de las cargas de trabajo en instancias spot12. Más allá de ese rango, el desperdicio restante ya no está dentro de los clústeres, sino en el número de clústeres. Cada uno conlleva un cargo por plano de control y forma una isla de programación que el bin packing no puede cruzar.
La multitenencia elimina ambos costes. En lugar de dedicar un clúster a cada cliente, equipo o entorno, los clústeres virtuales se ejecutan en infraestructura física compartida. Cada inquilino recibe su propio servidor de API y su plano de control virtual mientras los nodos se agrupan. Esto elimina el cargo por plano de control de cada clúster y permite el bin packing en el conjunto de nodos compartido en lugar de dentro de infraestructuras aisladas.
yaml
bash
Hay dos mecanismos disponibles. Los espacios de nombres siempre son más baratos, por lo que la elección se toma según la separación que necesiten los inquilinos, no según el coste.
- Los espacios de nombres dividen un único clúster y no añaden ningún plano de control propio. Son suficientes cuando los inquilinos confían entre sí y pueden compartir un único servidor de API y un solo conjunto de CRD.
- Los clústeres virtuales dan a cada inquilino su propio servidor de API, que se ejecuta como una carga de trabajo en el host. Ese coste se justifica en dos casos: inquilinos que necesitan sus propios recursos con ámbito de clúster y requisitos de aislamiento que un servidor de API compartido no puede cumplir.
Caso práctico real: Atlan
Atlan es una empresa de catálogo de datos que aloja la plataforma para aproximadamente el 95 % de sus clientes, muchos de ellos en sanidad y finanzas, donde el aislamiento de datos es contractual. Ejecutaba un clúster EKS completo por cliente y superó los 100 clústeres, una infraestructura cara de operar las 24 horas y difícil de mantener. Desde el primer trimestre de 2022 evaluó opciones de multitenencia y reconstruyó sobre vCluster, dando a cada cliente un clúster virtual en lugar de uno físico.
- Los clústeres EKS físicos pasaron de más de 100 a 20, y siguen sirviendo a más de 100 clientes.
- El gasto en Kubernetes se redujo en 600.000 dólares.14
Añadir como fuente preferidaOrden de ejecución
Los compromisos van al final, a pesar de ser la acción más fácil. Comprarlos antes de redimensionar fija entre uno y tres años del desperdicio que el redimensionamiento estaba a punto de eliminar. Es el error de secuenciación más caro que existe, y es habitual porque requiere una compra en lugar de trabajo de ingeniería.
La acción 7 es una rama, no un paso. Aplícala solo cuando las seis primeras estén completas y el resultado siga siendo insuficiente, ya que cambia cuántos clústeres se ejecutan y no con qué eficiencia se ejecuta cada uno.
Herramientas de optimización de costes de Kubernetes
Hemos representado las herramientas con tres o más casos prácticos publicados que cubren 47 de los 68 casos prácticos del conjunto de datos:
- Horizontal: cuántos casos prácticos tiene cada herramienta, contados una vez cada uno.
- Vertical: cuántas categorías distintas de casos de uso abarcan esos casos, de un total de diez. Una herramienta cuenta una vez por categoría sin importar cuántas veces aparezca en ella, por lo que las 12 menciones separadas de redimensionamiento de CAST IA contribuyen con 1 a su puntuación de 10.
- Tamaño de la burbuja: en cuántas de las ocho etapas de estrategia aparece la herramienta.
Frameworks de código abierto
Los frameworks de código abierto se pueden desplegar para las etapas de 0 a 6. Los usuarios asumen las actualizaciones, el cambio de versiones, la factura de retención de Prometheus y las decisiones que un recomendador comercial tomaría por ellos.
Cada una de estas herramientas se ocupa de un ámbito distinto, por eso varias se ejecutan a la vez.
- Robusta KRR o VPA en
updateMode: "Off"producen el trabajo pendiente del paso 1. No escriben nada. - Karpenter se ocupa de los nodos: aprovisionamiento, consolidación, selección de instancias, diversificación de spot y arquitectura. Abarca los pasos 3, 4 y 6.
- KEDA se ocupa del número de réplicas, incluido el escalado a cero, algo que HPA por sí solo no puede hacer.
- py-kube-downscaler o kube-green se ocupa del horario de no producción. Es el ahorro más barato de la lista.
- OpenCost mide de principio a fin y no participa en nada.
Plataformas comerciales
Toda herramienta comercial adopta una de tres posturas en la capa de nodos. Esa es la decisión, y importa más que el precio o la cantidad de funciones, porque el manifiesto de NodePool del paso 3 o bien sobrevive o bien no.
- Déjalas tranquilas: StormForge, PerfectScale, Sedai y Kubex solo redimensionan las cargas de trabajo. Necesitan Karpenter o Cluster Autoscaler por debajo y nunca lo tocan. Es la incorporación más segura a una configuración existente.
- Trabaja con ello: ScaleOps añade bin packing encima de Karpenter. nOps ajusta un Cluster Autoscaler o Karpenter existente en lugar de sustituirlo por el suyo. Más cobertura, el aprovisionador sigue siendo tuyo.
- Sustitúyelo: CAST IA y Spot Ocean instalan su propio aprovisionador y descartan el manifiesto. La cobertura más amplia, el menor control.
- Las herramientas de visibilidad se sitúan fuera: OpenCost, Kubecost, CloudZero, Vantage y Finout solo leen, por lo que no entran en conflicto con nada y se combinan libremente. Ejecuta una independientemente de qué más se adopte.
Cómo combinar estas herramientas
La factura se basa en los nodos en ejecución, no en las solicitudes declaradas. El redimensionamiento reduce las solicitudes, lo que libera espacio en los nodos existentes pero no elimina ninguno de ellos, por lo que la factura no cambia hasta que una herramienta de nodos consolida ese espacio. Las herramientas de nodos fallan solas por la razón contraria: empaquetan las solicitudes que se les dan, así que las solicitudes sobreajustadas simplemente se empaquetan de forma más densa.
Dos formas de cubrir ambas capas:
- Dos herramientas: VPA, StormForge o PerfectScale para las solicitudes, más Karpenter para los nodos. Más barato, y la capa de nodos permanece bajo control directo.
- Una plataforma: CAST IA, Zesty o Spot Ocean hacen ambas cosas en un único producto. Más caro, y su aprovisionador sustituye a Karpenter.
Cinco combinaciones de herramientas que rompen cosas:
- Dos redimensionadores mutables en un mismo despliegue: VPA en
Autojunto con StormForge, ScaleOps, PerfectScale o Zesty significa dos controladores escribiendo números distintos en el mismo campo. Un controlador de admisión mutante por carga de trabajo. - Karpenter y Cluster Autoscaler en un mismo grupo de nodos: Ambos aprovisionan contra los mismos pods no programables, por lo que el clúster acaba con aproximadamente el doble de nodos de los que necesita.
- VPA y HPA sobre la misma métrica: El uso sube, VPA aumenta la solicitud, la utilización medida cae porque es uso entre solicitud, HPA elimina réplicas, la carga por pod sube, y se repite. Es seguro cuando HPA escala en algo que VPA no toca, como la profundidad de cola mediante KEDA.
- Dos herramientas de compromisos en una misma cuenta de pago: Ambas compran contra el mismo gasto no cubierto, fijando un sobrecompromiso de uno a tres años.
- Dos plataformas completas: CAST IA, Zesty y Spot Ocean instalan cada una su propio aprovisionador y esperan ser sus dueñas.
Filtra todos los casos prácticos que recopilamos:
Lecturas adicionales
Lee más para dominar la colocación de pods y reducir tu gasto en cómputo en la nube:
- Compara las mejores herramientas de orquestación de contenedores
- Compara 20+ orquestadores de nube
- Los mejores programadores de trabajos para nube híbrida
Cita esta investigación
Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.
@misc{simsek2026,
author = {Şimşek, Hazal},
title = {{Optimización de costes de Kubernetes: 8 pasos, 23 herramientas y casos prácticos}},
year = {2026},
month = sep,
howpublished = {\url{https://aimultiple.com/kubernetes-cost-optimization}},
note = {AIMultiple. Recuperado el 18 de septiembre de 2026}
}Resultados y marcas de tiempo de 114 puntos de datos. Descargue los datos resumidos que se muestran en los gráficos y las tablas de este artículo como un archivo ZIP que contiene 4 archivos CSV.
¿Quieres los datos granulares que hay detrás? Únete a Premium
Enlaces de referencia
Siguiente para leer
Los 10 mejores sistemas ERP de IA agéntica y 6 soluciones
Comparar IBM Tivoli Workload Scheduler
LLM Orquestación: 22 frameworks y pasarelas
Compara más de 20 plataformas y bibliotecas de IA responsable
Descubra las 6 últimas integraciones de IA de SAP Datasphere
Opcon Automation: Ventajas, desventajas, funciones y 4 alternativas
Sé el primero en comentar
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.