El 26 de agosto de 2026 se liberó Kubernetes v1.37 "Garhwal", y dos de sus cambios no son una feature más del changelog: tocan directamente cómo se corre un nodo y cómo escala una app en producción. El kubelet —el proceso que hasta ahora corría como root en cada nodo— puede ejecutarse sin privilegios de root, y la API que alimenta kubectl top y el Horizontal Pod Autoscaler dejó de ser beta después de casi una década.
Kubernetes 1.37 "Garhwal" es la release de agosto de 2026 del proyecto de orquestación de contenedores, con 67 enhancements: 16 graduaron a stable, 23 a beta y 27 entraron en alpha. Sus dos cambios centrales son la graduación a GA de metrics.k8s.io (v1) y la promoción a beta de KubeletInUserNamespace, el modo rootless del kubelet.
¿Qué es el kubelet rootless en Kubernetes 1.37?
Es el feature gate KubeletInUserNamespace, que permite que el kubelet, el runtime de contenedores (CRI/OCI), los plugins CNI y kube-proxy corran como usuario no-root en el host usando user namespaces de Linux. En 1.37 pasó de alpha a beta y, según reportó InfoQ, el feature gate viene habilitado por defecto en esta versión.
La idea del feature no es nueva: arrancó como experimento en 2018 y entró como alpha recién en la v1.22 (2021), bajo el KEP-2033. Lo que cambia en 1.37 es que después de cinco años de maduración, el equipo lo considera lo bastante estable para beta, según detalla el blog oficial de Kubernetes firmado por Akihiro Suda (NTT), uno de los mantenedores históricos de esta característica.
¿Es lo mismo que los user namespaces para pods?
No, son dos features distintas que suelen confundirse. Los user namespaces para pods (estables desde versiones anteriores) aíslan el proceso dentro de un contenedor de su equivalente en el host; KubeletInUserNamespace aísla el propio kubelet y el resto de los componentes de nodo del root del host.
En la práctica, que un atacante logre un container escape ya no significa automáticamente que tenga root en el nodo físico: el kubelet, el runtime y kube-proxy quedan corriendo dentro de su propio namespace de usuario, con las capacidades limitadas que eso implica.
¿Qué es la Metrics API y por qué importaba que fuera GA?
La metrics.k8s.io es la API que expone el uso de CPU y memoria de nodos y Pods, y es la que responde kubectl top y la que consulta el Horizontal Pod Autoscaler para tomar decisiones de escalado. En Kubernetes 1.37 pasó de v1beta1 a v1, es decir, alcanzó estabilidad GA.
Lo notable es el tiempo que tardó: la API se introdujo como alpha en Kubernetes v1.6 (2017) y recién en 1.37 llegó a estable, casi nueve años después, según el blog oficial de graduación. El propio anuncio es explícito sobre el alcance del cambio: "The v1 API has the same resource types and fields as v1beta1; this is an API-version graduation, not a change to the metrics that are collected or returned" ("la API v1 tiene los mismos tipos de recurso y campos que v1beta1; es una graduación de versión de API, no un cambio en las métricas que se recolectan o devuelven").
¿Cambia algo si ya uso HPA con v1beta1?
No a nivel de datos: los campos y valores de CPU y memoria son idénticos entre v1beta1 y v1. Lo que gana el ecosistema es la garantía de estabilidad propia de una API GA: política de deprecación formal, soporte de largo plazo y la confianza de que herramientas de terceros (Prometheus adapters, dashboards, operadores de autoscaling) pueden apoyarse en ella sin el riesgo de que cambie de forma disruptiva.
Para quien ya usa Horizontal Pod Autoscaler en producción, el cambio todavía no es automático: el controlador de HPA por ahora solo soporta v1beta1, y el soporte para elegir automáticamente entre v1 y v1beta1 está planeado pero no está disponible en Kubernetes v1.37.
¿Por qué estos dos cambios importan juntos?
Porque tocan las dos capas que definen el "piso" de un clúster: seguridad de nodo y observabilidad de recursos. Uno reduce la superficie de ataque si un contenedor se escapa; el otro asegura la fuente de datos de la que depende buena parte del autoscaling en producción. Ninguno es glamoroso, pero ambos son infraestructura que miles de clústeres usan todos los días sin pensarlo.
- Rootless kubelet reduce el blast radius de un container escape: si el atacante compromete un pod y logra escapar al host, ya no encuentra automáticamente un proceso root esperándolo.
- Metrics API GA da estabilidad de contrato a las herramientas de autoscaling: operadores, adapters de métricas custom y dashboards pueden depender de
v1sin miedo a breaking changes de API. - Ambas son features que ya existían de facto: no son funcionalidad nueva de cero, sino la maduración de mecanismos que venían de años atrás (2018 y 2017 respectivamente), lo que reduce el riesgo de adoptarlas.
¿Kubernetes 1.37 trae algo más relevante?
Sí: KYAML (un subconjunto más estricto y menos ambiguo de YAML para manifiestos) llegó a stable, y el soporte de scale-to-zero en HorizontalPodAutoscaler graduó a beta con el feature gate habilitado por defecto, según InfoQ. Esto último es particularmente relevante para cargas de IA/ML con GPUs en la nube, donde escalar un Deployment a cero réplicas cuando no hay tráfico puede significar un ahorro de costo directo.
¿Qué implica esto para un clúster en producción?
Antes de tocar nada, conviene separar lo que es "disponible" de lo que es "activado por defecto en tu clúster". Que el feature gate de rootless kubelet venga habilitado en el binario no significa que tu nodo ya esté corriendo sin root: activar el modo rootless real requiere configuración explícita a nivel de kubelet y compatibilidad del runtime de contenedores que estés usando (containerd o CRI-O), y todavía es beta, no GA.
- Si administrás nodos on-prem o en VMs propias: es el momento de leer el KEP y probar rootless kubelet en un entorno de staging antes de pensar en producción, dado que sigue siendo beta.
- Si dependés de HPA con métricas custom: verificá que tu adapter de métricas (Prometheus Adapter u otro) soporte
metrics.k8s.io/v1, aunque la compatibilidad conv1beta1se mantiene por ahora. - Si corrés cargas de IA/ML con autoscaling de GPU: el scale-to-zero de HPA en beta merece una prueba puntual para medir el ahorro real en tu entorno antes de generalizarlo.
- Si ya migraste a Gateway API o adoptaste Dynamic Resource Allocation (DRA): 1.37 no rompe nada de eso; son mejoras ortogonales que se suman al mismo clúster.
¿Qué puedo hacer hoy con esto?
Si tenés un clúster de prueba, lo más directo es levantar un nodo en 1.37 y correr kubectl top nodes y kubectl top pods para confirmar que la respuesta viene de la API v1 estable. Para el rootless kubelet, el propio blog oficial de graduación detalla los pasos de habilitación del feature gate y las limitaciones conocidas en esta etapa beta —vale revisarlo antes de tocar un nodo real.
Quien ya haya seguido la nota sobre Dynamic Resource Allocation (DRA) en Kubernetes o el tutorial de Horizontal Pod Autoscaler paso a paso va a reconocer el patrón: Kubernetes viene consolidando en GA mecanismos que llevaban años en beta, lo que reduce el riesgo de adoptarlos en serio. Lo mismo aplica a los que ya trabajaron aislamiento de root a nivel de contenedor con userns-remap en Docker: la lógica de reducir privilegios ahora sube un escalón, del contenedor al propio kubelet.
Preguntas frecuentes
¿Kubelet rootless ya es apto para producción?
No todavía: es beta en Kubernetes 1.37, lo que significa que el feature gate está habilitado por defecto pero el mecanismo sigue en validación activa por la comunidad, no GA.
¿Necesito migrar mis manifiestos si actualizo a Kubernetes 1.37?
No para lo básico: la Metrics API v1 mantiene los mismos campos que v1beta1, así que HPA y kubectl top siguen funcionando sin cambios de configuración.
¿Qué runtime de contenedores necesito para probar rootless kubelet?
Necesitás un runtime compatible con user namespaces de Linux, como containerd o CRI-O en versiones recientes; el detalle exacto de requisitos está en el blog oficial de graduación a beta.
¿Cuándo se liberó Kubernetes 1.37?
El 26 de agosto de 2026, bajo el nombre en código "Garhwal", según el anuncio oficial del proyecto Kubernetes.
¿Qué pasa con v1beta1 de la Metrics API?
Se mantiene disponible por compatibilidad mientras el ecosistema migra a v1, siguiendo la política estándar de deprecación de Kubernetes para APIs graduadas.
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
