Optimización de Kubernetes: right-sizing con DevZero

DevZero lanzó el 9 de junio de 2026 una plataforma de optimización autónoma de infraestructura que ajusta los recursos de Kubernetes en tiempo real y sin reiniciar los contenedores. Según el comunicado, recorta entre 30% y 60% de los costos de cómputo aplicando right-sizing continuo sobre CPU, memoria y GPU.

La optimización de Kubernetes es el proceso de ajustar los recursos asignados a cada carga de trabajo (CPU, memoria y GPU) a lo que realmente consume, en vez de sobreaprovisionar “por las dudas”. El right-sizing es la parte central de ese proceso: detecta cuánto pediste de más en los requests y limits y lo corrige. DevZero, una empresa con sede en San Francisco, lo hace de forma automática y sin downtime.

En 30 segundos

DevZero presentó el 9/06/2026 una plataforma que ajusta recursos de Kubernetes en tiempo real sin reiniciar contenedores.
El CEO afirma que los clusters típicos están aprovisionados 53% por encima de lo necesario.
Flexera midió que el 29% del gasto cloud se va en recursos infrautilizados o mal dimensionados.
La promesa de ahorro va de 30% a 60%, y depende de cuán sobreaprovisionado estaba tu cluster antes.
Usa checkpoint-restore para migrar cargas en vivo entre más de 3.000 tipos de instancia y 23 tipos de GPU.

¿Qué es el right-sizing en Kubernetes y por qué desperdiciamos la mitad de los recursos?

Ponele que armás un deployment nuevo. No sabés bien cuánta memoria va a comer, así que le ponés 2 GB de request y 4 GB de limit para dormir tranquilo. Multiplicá eso por 80 servicios y tres equipos que hacen lo mismo, y de golpe estás pagando un cluster que usa la mitad de lo que reservó.

No es un caso aislado. Según DevZero, los clusters de Kubernetes corren en promedio aprovisionados un 53% por encima de lo que necesitan. Y el dato de contexto lo pone Flexera: el 29% del gasto cloud de las empresas se desperdicia en recursos infrautilizados o mal dimensionados. No es plata chica.

El right-sizing ataca justo eso. En vez de adivinar, mira el consumo real histórico y ajusta los requests y limits a niveles que tengan sentido. La sobreprovisión “por seguridad” tiene una lógica: nadie quiere que un pod muera por falta de memoria (el temido OOMKilled). El problema es que esa lógica, sin datos que la respalden, termina siendo una excusa para pagar de más todos los meses. Relacionado: pipelines CI/CD modernos.

Automatización de la optimización de Kubernetes: ¿HPA, VPA o algo autónomo como DevZero?

Antes de pagar por una herramienta, conviene saber qué traés gratis con Kubernetes. Hay dos mecanismos nativos y hacen cosas distintas.

El Horizontal Pod Autoscaler (HPA) escala la cantidad de réplicas. Si la CPU pasa cierto umbral, suma pods; si baja, los saca. Necesita el Metrics Server instalado y se configura con un target, típicamente targetCPUUtilizationPercentage: 60. El Vertical Pod Autoscaler (VPA) hace lo otro: no toca la cantidad de réplicas, ajusta los requests y limits de cada pod. Uno escala a lo ancho, el otro a lo alto.

Acá viene el problema clásico: HPA y VPA en modo automático sobre la misma métrica se pelean. El VPA al aplicar cambios reinicia el pod (modo Recreate), y eso es exactamente lo que DevZero dice resolver con su enfoque sin reinicios.

Criterio	HPA	VPA
Qué ajusta	Cantidad de réplicas	requests / limits por pod
Dirección	Horizontal (más pods)	Vertical (pods más grandes)
Requiere Metrics Server	Sí	Sí
Reinicia el pod al aplicar	No	Sí (modo Recreate)
Ideal para	Tráfico variable, stateless	Cargas con consumo estable mal dimensionado

optimización de kubernetes diagrama explicativo

¿Cuál usar? Depende. Si tu app aguanta réplicas y el tráfico sube y baja, HPA. Si tenés un servicio que pediste mal de entrada, VPA en modo recomendación. DevZero se posiciona arriba de los dos: orquesta el ajuste de forma autónoma y, según la empresa, evita el reinicio que hace dudar a todo el mundo de prender el VPA en producción. Sobre eso hablamos en herramientas de automatización comparadas.

¿Cómo hace DevZero para migrar cargas sin reiniciar los contenedores?

Esta es la parte interesante. El diferencial técnico que comunica DevZero es el uso de checkpoint-restore: congela el estado de un contenedor en ejecución, lo mueve a otra instancia y lo descongela ahí mismo, sin que el proceso “sepa” que se mudó. En la práctica, una migración en vivo casi instantánea.

¿Por qué importa tanto el “sin restart”? Porque el costo real de reoptimizar no es solo técnico, es político. Subís el cambio, alguien tiene que aprobar una ventana de mantenimiento, el equipo de la app se pone nervioso porque su servicio se reinicia, y al final nadie toca nada y seguís pagando de más. Sacar el reinicio de la ecuación baja esa fricción.

El alcance que reporta la empresa es amplio: modela decisiones sobre más de 3.000 tipos de instancia, unos 69.000 puntos de precio y 23 tipos de GPU distintos, usando datos históricos para decidir dónde conviene correr cada carga. Eso último (el modelado estadístico) es clave: no reacciona a un pico puntual, proyecta el comportamiento. Habría que ver cómo se porta con cargas erráticas, pero la idea es sólida.

Resultados reales: ¿el 30% a 60% de ahorro es realista o marketing?

Seamos honestos con el rango. Cuando un proveedor te dice “ahorrás hasta 60%”, el “hasta” hace todo el trabajo. ¿De dónde sale ese número? Complementá con documentación técnica en múltiples idiomas.

DevZero menciona como clientes a DataBahn, Dentira, Starburst, OpenObserve y Outerbounds. El rango 30-60% que reporta no es magia: depende de tu punto de partida. Si tu cluster estaba muy sobreaprovisionado y con mal bin-packing (pods mal acomodados en los nodos), el margen de mejora es enorme y vas a ver el extremo alto. Si ya venías optimizando a mano, el ahorro va a estar más cerca del piso, o incluso por debajo.

Dicho de otra forma: el 60% no es una promesa para tu caso, es el techo de alguien que estaba pagando el doble. La pregunta honesta antes de firmar es ¿cuánto desperdicio real tengo hoy? Si no lo medís, no sabés cuánto vas a ahorrar. Por eso el primer paso siempre es visibilidad, no automatización.

Errores comunes en requests y limits que te inflan la factura

Copiar requests y limits genéricos sin mirar datos. El clásico “le pongo 1 CPU y 2 GB a todo”. Sin el consumo real de cada servicio, estás adivinando, y casi siempre adivinás de más.
Prender HPA sin Metrics Server o con métricas mal configuradas. El HPA sin métricas no escala nada, o escala con datos basura. Verificá con kubectl top pods: si te da error, te falta el Metrics Server.
Sobreprovisionar “por seguridad” sin análisis. El miedo al OOMKilled hace que la gente duplique la memoria preventivamente. Es razonable una vez, es un agujero de plata si lo hacés en cada deployment.
Poner limits iguales a requests en todo. Te da QoS Guaranteed, sí, pero también te impide aprovechar la capacidad ociosa del nodo. A veces conviene, a veces te ata recursos al pedo.

Guía práctica de optimización de Kubernetes: right-sizing en clusters existentes

Si querés arrancar hoy sin pagar nada, este es el camino corto y a mano:

Mirá lo que reservaste hoy. Con kubectl describe pod <nombre> revisás los requests y limits actuales de cada carga.
Instalá el Metrics Server si no lo tenés. Probá kubectl top nodes y kubectl top pods. Si dan error, ese es tu primer paso.
Activá HPA con un target realista. Algo como kubectl autoscale deployment miapp --cpu-percent=60 --min=2 --max=10 para tráfico variable.
Probá el VPA en modo recomendación primero. Con updateMode: "Off" el VPA te sugiere valores sin aplicarlos ni reiniciar nada. Mirás, comparás, decidís.
Monitoreá de 2 a 4 semanas. Un día no alcanza. Necesitás ver picos de fin de mes, batch nocturnos, todo el ciclo real.
Ajustá y repetí. El right-sizing no es una corrida única, es un hábito. Lo que hoy está bien dimensionado, en tres meses cambió.

Si además estás moviendo infraestructura web, dominios o cloud para alojar parte de este stack en Latinoamérica, donweb.com tiene opciones de hosting y servidores pensadas para la región.

¿Qué otras herramientas existen además de DevZero?

DevZero no juega solo. El ecosistema de optimización de costos en Kubernetes ya tiene varios nombres, cada uno con su enfoque.

Kubecost. Más enfocado en visibilidad y atribución de costos por namespace o equipo. AWS lo integró para right-sizing de requests dinámico, como muestra su blog de containers.
Cast.ai. El competidor más directo: automatización de scaling y elección de instancias, con material incluso en español.
Sedai. Optimización autónoma con foco en confiabilidad y performance, no solo costo.
Turbonomic (IBM). Plataforma más amplia de gestión de recursos, pensada para entornos grandes y heterogéneos.

El diferencial que DevZero pone sobre la mesa es el checkpoint-restore sin reinicios. Si eso se cumple en producción como promete, es un argumento fuerte frente a soluciones que igual te obligan a reciclar pods. Tomalo con pinzas igual: los benchmarks de ahorro son del propio fabricante y todavía falta verificación independiente. Ya lo cubrimos antes en agentes de automatización locales.

Preguntas Frecuentes

¿Qué es el right-sizing en Kubernetes?

El right-sizing en Kubernetes es el ajuste de los recursos asignados a cada carga (CPU, memoria y GPU) a lo que realmente consume, corrigiendo la sobreprovisión. Reduce costos sin afectar el rendimiento, porque elimina la capacidad reservada que nunca se usa.

¿Cuál es la diferencia entre HPA y VPA?

El HPA escala la cantidad de réplicas de un deployment según la carga, mientras que el VPA ajusta los requests y limits de cada pod. HPA crece a lo ancho (más pods), VPA a lo alto (pods mejor dimensionados). El VPA reinicia el pod al aplicar cambios; el HPA no.

¿Cuánto se puede ahorrar optimizando un cluster?

DevZero reporta reducciones de entre 30% y 60% en costos de cómputo. El ahorro real depende del punto de partida: un cluster muy sobreaprovisionado verá el extremo alto, uno ya optimizado verá mucho menos. Flexera estima que el 29% del gasto cloud típico se desperdicia.

¿Se puede reoptimizar sin downtime?

Sí. DevZero usa tecnología checkpoint-restore para migrar cargas en vivo sin reiniciar los contenedores. Esto la diferencia del VPA nativo de Kubernetes, que en su modo automático recrea los pods para aplicar los nuevos límites.

¿Necesito el Metrics Server para optimizar?

Sí, tanto HPA como VPA necesitan el Metrics Server para leer el consumo de CPU y memoria. Verificalo corriendo kubectl top pods: si devuelve un error, el componente no está instalado y ningún autoscaler nativo va a funcionar.

Conclusión

El lanzamiento de DevZero del 9 de junio de 2026 mete presión en un punto que casi todo equipo con Kubernetes conoce de memoria: se paga de más, y arreglarlo a mano da fiaca. La propuesta de optimización autónoma sin reinicios es interesante porque ataca la fricción real, no solo la técnica.

¿Conviene salir a comprarlo ya? Antes de eso, medí. Prendé el Metrics Server, corré el VPA en modo recomendación dos semanas y mirá cuánto desperdicio tenés de verdad. Si es mucho, el caso para automatizar (con DevZero o con Cast.ai o con lo que sea) se arma solo. Si ya venías prolijo, el ahorro va a ser modesto y quizás no justifique una herramienta paga. La data manda, no el comunicado de prensa.

Optimización de Kubernetes sin reinicios: qué propone