Review de DevZero: right-sizing autónomo para Kubernetes sin reinicios

Llega un momento en la vida de todo cluster de Kubernetes donde la factura de cómputo empieza a doler más que un lunes sin café. Revisás los gráficos y encontrás pods pidiendo el doble de lo que consumen, nodos a media máquina y una sensación de estar pagando fiesta para invitados que nunca llegaron. DevZero —empresa de San Francisco— lanzó en junio de este año una plataforma que promete resolver justamente eso: ajustar los recursos en tiempo real y sin reiniciar los contenedores. Suena casi demasiado bueno, así que fuimos a ver cómo funciona bajo el capó, qué limitaciones reales tiene y si el ahorro del 30-60% es cierto o puro marketing.

DevZero es una plataforma de optimización autónoma de infraestructura para Kubernetes que aplica right-sizing continuo sobre CPU, memoria y GPU sin reiniciar los pods, usando checkpoint-restore en vivo para migrar cargas entre más de 3.000 tipos de instancia y 23 tipos de GPU distintos. Su diferencial técnico es evitar el reinicio que el Vertical Pod Autoscaler nativo requiere en modo automático, eliminando la fricción operativa que frena los ajustes en producción. Según su comunicado de lanzamiento del 9 de junio de 2026, recorta entre un 30% y un 60% de los costos de cómputo.

¿Qué problema resuelve exactamente DevZero?

El sobreaprovisionamiento en Kubernetes es endémico. Se pide de más "por las dudas", se configuran requests y limits a ojo, y el resultado son clusters que —según el CEO de DevZero— están aprovisionados un 53% por encima de lo necesario. Flexera, en su informe anual sobre el estado de la nube, midió que el 29% del gasto se va en recursos infrautilizados o mal dimensionados. No es un problema menor ni exclusivo de los que recién arrancan: pasa en producción, en staging y en todos los ambientes intermedios.

Las herramientas nativas de Kubernetes atacan el problema desde ángulos distintos pero insuficientes:

• Horizontal Pod Autoscaler (HPA): escala la cantidad de réplicas según uso de CPU o métricas custom. Ideal para tráfico variable en aplicaciones stateless, pero no corrige pods que individualmente están mal dimensionados.
• Vertical Pod Autoscaler (VPA): ajusta requests y limits de cada pod. En modo recomendación no aplica cambios, solo sugiere. En modo automático, para aplicar las sugerencias, recrea el pod (modo Recreate). Ese reinicio es el que frena a medio mundo de usarlo en producción.

DevZero se posiciona arriba de ambos: orquesta el ajuste de forma autónoma combinando escalado horizontal y vertical, pero con un diferencial clave —no reinicia los contenedores para aplicar cambios en los recursos.

Checkpoint-restore: la magia detrás del "sin reinicios"

El corazón técnico de DevZero es CRIU (Checkpoint/Restore In Userspace). La operatoria funciona así: el agente congela el proceso en el pod actual, serializa todo su estado —páginas de memoria, descriptores de archivos, sockets TCP abiertos, membership de PID y namespace— a un conjunto de archivos de imagen, recrea el pod con la nueva especificación de recursos, y restaura el checkpoint en el nuevo pod. El proceso retoma exactamente donde se quedó, sin saber que se mudó de nodo. Según la documentación oficial, esta migración en vivo preserva conexiones TCP establecidas a través de nodos distintos usando la opción TCP_REPAIR de CRIU para capturar números de secuencia y opciones negociadas, silenciando paquetes entrantes durante la pausa para que el remoto nunca reciba un RST y rompa la conexión.

Este enfoque esquiva todas las restricciones del in-place vertical scaling que Kubernetes 1.33+ ofrece de forma nativa: no hay limitaciones de clase QoS, no importa la plataforma, y si el nodo actual no tiene capacidad para el nuevo tamaño, el scheduler simplemente coloca el pod en otro nodo. La migración en vivo y el in-place scaling son complementarios —DevZero intenta in-place primero y, si no es viable, recurre a la migración.

¿Cómo se instala y despliega en un cluster propio?

DevZero no es una herramienta que descargás de GitHub y desplegás en cinco minutos con un docker-compose. Es una plataforma gestionada, aunque los componentes de operación corren dentro de tu cluster. El despliegue requiere instalar dos componentes principales:

• Workload Operator: el controlador que genera y aplica las recomendaciones de optimización. Se instala via Helm desde la consola de DevZero.
• Node Agent (DaemonSet): necesario en cada nodo que participe en migraciones en vivo. Debe etiquetarse con dakr.devzero.io/checkpoint-node=true y tener presente el shim de containerd compatible con CRIU.

Para habilitar un nodo como origen o destino de migraciones, se ejecuta:

kubectl label node <node-name> dakr.devzero.io/checkpoint-node=true
kubectl get nodes -l "dakr.devzero.io/checkpoint-node=true"  # validación

Las recomendaciones se configuran a través del CRD WorkloadRecommendation, donde se especifica si se habilita live migration para ese workload en particular con useLiveMigration: true. No hay un "modo automático universal" que aplique live migration a todo el cluster; se configura por carga de trabajo.

Modos de recomendación: ¿qué tan agresivo querés ser?

DevZero ofrece tres modos de recomendación que determinan con qué agresividad se reducen los recursos. La documentación los detalla así:

Un detalle importante: en modo automático, el operador actualmente no modifica los limits, solo los requests. Lo hacen como medida de confiabilidad. Esto significa que la reducción de costos más agresiva requiere intervención manual sobre los límites, o usar el modo Aggressive que sí los ajusta.

Limitaciones que aparecen cuando rascás la pintura

Ninguna herramienta es perfecta, y DevZero tiene sus puntos ásperos. Estos son los que encontré revisando la documentación:

• Procesos no dumpables: si una aplicación llama a prctl(PR_SET_DUMPABLE, 0), CRIU no puede checkpointearla. El operador hace fallback a rolling restart tradicional, con el reinicio que justamente querías evitar.
• Sidecar de Istio no se checkpointea: el proxy de malla de servicios arranca fresco en el destino. Para la mayoría de aplicaciones es transparente, pero conexiones extremadamente sensibles a latencia en la malla pueden notar una brevísima reconexión.
• Coherencia de imagen: si estás en medio de un rollout de Deployment donde algunos pods usan una imagen distinta a la del template, la migración en vivo se saltea. No es un problema en estado estable, pero sí en ventanas de actualización.
• Huella de memoria grande: el tamaño de la imagen de checkpoint escala con la memoria usada. Migrar un pod con 100 GB de RAM usada produce una imagen del mismo orden, y el tiempo de migración escala con ese volumen.
• No es self-hosted ni open source: los componentes de operación corren en tu cluster, pero la plataforma de control es gestionada. Si tu requisito es tener todo 100% on-premises sin dependencia externa, DevZero no encaja.
• Beta: la funcionalidad de live migration está marcada como beta al momento de escribir esto. La documentación de modos de recomendación también indica que están en etapa beta.
• Verificación independiente pendiente: los benchmarks de ahorro del 30-60% son del fabricante. No hay todavía verificación independiente publicada por terceros que valide estos números en condiciones diversas.

Pros y contras reales

Lo que suma puntos

• Elimina la fricción política del reinicio: el mayor costo del right-sizing no es técnico, es operativo. Sacar la necesidad de ventana de mantenimiento y el miedo al downtime es un argumento fuerte.
• Modelado estadístico, no reactivo: no dispara ajustes por un pico puntual; proyecta comportamiento sobre datos históricos. Eso evita el vaivén de recursos que sufren las configuraciones ingenuas de HPA/VPA.
• Cobertura amplia de instancias y GPUs: modela decisiones sobre más de 3.000 tipos de instancia y 23 tipos de GPU. Si tu cluster mezcla cargas con y sin GPU, la optimización cruzada es valiosa.
• Fallback con gracia: cuando la migración en vivo no puede completarse, aplica los cambios igual con rolling restart estándar y lo registra en el estado (AppliedWithRestartFallback).
• Preservación de estado y conexiones: no es solo “no reiniciar”; es mantener sesiones activas, trabajo en memoria y conexiones TCP establecidas a través de nodos. Para cargas stateful esto es un game-changer.

Lo que resta

• Dependencia externa: no es una solución que puedas auditar completamente ni correr aislada. El panel de control está en la nube de DevZero.
• No toca limits en modo automático estándar: si tu ahorro viene de limits inflados, el modo Balanced no los reduce. Necesitás usar modo Aggressive o hacerlo manual.
• Requisitos de infraestructura para CRIU: necesitás nodos con el shim correcto, etiquetados explícitamente, y configurar el DaemonSet del agente. No es “instalar y olvidarse”.
• Sin visibilidad previa sin contratar: la herramienta te dice cuánto ahorrás después de implementarla. No hay un assessment gratuito que te diga “tu cluster tiene un 40% de grasa” antes de comprometerte.
• Números de ahorro con asterisco: el 60% es el techo de quien estaba pagando el doble de lo necesario. Si tu cluster ya está optimizado a mano, el ahorro marginal puede ser mucho menor.

¿Para quién es y cuándo no conviene?

DevZero es buena opción si:

• Tenés un cluster mediano o grande con decenas de workloads distintos y sobreprovisionamiento crónico que nadie quiere tocar “porque funciona”.
• La resistencia al cambio en tu organización es alta justamente por el miedo al reinicio. La promesa de aplicar ajustes sin downtime destraba conversaciones que el VPA nativo no logra.
• Mezclás cargas con GPU y CPU, y necesitás optimizar la asignación de instancias considerando ambos tipos de recurso simultáneamente.
• Tenés aplicaciones stateful donde un reinicio realmente duele (bases de datos, colas, sesiones de usuario en memoria).

No conviene cuando:

• Tu cluster es chico (menos de 10 workloads) y el sobreaprovisionamiento es marginal. El retorno no justifica la complejidad adicional.
• Necesitás una solución 100% self-hosted sin dependencia de un servicio externo para el plano de control.
• Ya tenés un proceso de right-sizing manual o con VPA en modo recomendación que funciona, y el ahorro incremental no cubre el costo de la herramienta.
• Corrés cargas muy efímeras (pods que viven minutos) donde el checkpoint-restore no tiene sentido práctico porque el pod muere antes de que termine de migrar.

¿Qué preguntar antes de evaluar la herramienta?

El primer paso antes de cualquier herramienta de optimización no es contratarla: es medir. Si no sabés cuánto desperdicio real tenés hoy, no podés proyectar cuánto vas a ahorrar. Necesitás al menos dos a cuatro semanas de datos históricos de uso de CPU, memoria y GPU por workload. Un día de métricas no alcanza: necesitás ver picos de fin de mes, cargas batch nocturnas y patrones semanales.

Preguntas concretas para hacerle al vendedor o para responder con tu propio monitoreo:

• ¿Cuál es la brecha entre requests y uso real en el percentil 95 de mis workloads principales?
• ¿Cuántos de mis pods están en QoS Burstable que podrían pasar a Guaranteed?
• ¿Tengo nodos con asignación de CPU por debajo del 40% sostenido?
• ¿Qué porcentaje de mi gasto en GPU están realmente usando los pods que las solicitan?

Con esas respuestas en la mano, la promesa del 30-60% deja de ser un número de marketing y se convierte en una proyección verificable.

Veredicto

DevZero ataca un problema real con una solución técnicamente interesante. El diferencial de checkpoint-restore sin reinicios es genuino, no humo: CRIU existe hace años, funciona, y la implementación de DevZero es coherente al delegar en él las migraciones respetando el ciclo de vida de los pods en Kubernetes. La documentación es detallada y no esconde las limitaciones —eso es una señal de madurez, no de debilidad.

Dicho eso, hay que poner los números en perspectiva. El ahorro depende enteramente de cuán inflado esté tu cluster hoy. Si estás en el extremo alto del desperdicio, los números de DevZero son alcanzables. Si ya venías haciendo deberes, el margen se achica. Y la dependencia del plano de control externo va a ser un dealbreaker para equipos con requisitos estrictos de soberanía de infraestructura.

No es una herramienta mágica ni para todos. Es una herramienta de nicho bien ejecutada para organizaciones con clusters grandes, dolor real de costos y resistencia cultural a los reinicios. Si ese es tu caso, vale la prueba. Si no, empezá por el VPA en modo recomendación y sacá tus propias conclusiones —es gratis y ya está en tu cluster.

Cloud Serversby Donweb

Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.

• Performance que te sorprenderá
• Rápida escalabilidad y sin limitaciones
• Arquitectura de alta disponibilidad
• Soporte experto y ejecutivos de cuenta
• Pagos en tu moneda y facturación local

Descubre la mejor solución de Cloud Hosting