Introducción
Un cluster de Kubernetes que corre kubelet como root en el host tiene, en el mejor de los casos, una barrera de contenedores entre un exploit en el espacio de usuario y el control total del nodo. En el peor, un escape de contenedor significa acceso directo al kernel, a los volúmenes montados y a las credenciales de la control plane. Kubernetes 1.37, liberada el 21 de septiembre de 2026 bajo el nombre clave «Garhwal», ataca ese vector de frente: el feature gate KubeletInUserNamespace pasa a beta y queda habilitado por defecto, permitiendo que el kubelet corra como usuario no-root dentro de un user namespace de Linux. No es un parche cosmético. Es un cambio estructural en cómo el componente más privilegiado del nodo interactúa con el host.
Junto con ese cambio, la release incorpora 67 mejoras: 27 features en alpha, 23 que ascienden a beta, 16 que alcanzan general availability y una deprecación. El foco declarado por la CNCF es triple: estabilidad operativa, endurecimiento de seguridad y optimización para cargas de trabajo de AI/ML. Para quien administra clusters en producción, la combinación de Metrics API estable, certificados de pod nativos y kubelet rootless habilitado por default configura un baseline de seguridad que, hasta ahora, exigía herramientas de terceros y configuraciones manuales propensas a error.
Qué ocurrió
La CNCF publicó Kubernetes 1.37 el 21 de septiembre de 2026. La release marca la GA de la API metrics.k8s.io, el mecanismo unificado de métricas de nodo y pod que alimenta el Horizontal Pod Autoscaler, el Vertical Pod Autoscaler y comandos como kubectl top. Hasta esta versión, la API funcionaba pero no estaba formalmente estabilizada, lo que generaba incertidumbre en contratos de SLA y en integraciones con herramientas de observabilidad externas.
En paralelo, el feature gate KubeletInUserNamespace ascendió a beta con activación por defecto. Esto significa que, en instalaciones nuevas y en upgrades que no deshabiliten explícitamente la feature, el kubelet se ejecuta dentro de un user namespace Linux sin privilegios de root en el host. La CNCF posicionó esto como una mitigación directa contra ataques de container escape: un exploit que comprometa el kubelet ya no otorga uid 0 en el espacio de red y de archivos del host.
Tres features adicionales alcanzaron GA o beta con impacto operativo directo: la inicialización resiliente del watchcache en kube-apiserver (GA, activada por default), los certificados de pod para mTLS nativo (GA) y el scale-to-zero del HorizontalPodAutoscaler (beta, activado por default). La release incluye además features en alpha como InPlacePodVerticalScalingSchedulerPreemption, checkpoint/restore a nivel de pod y la estrategia Recreate para rollouts de StatefulSet.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos de SRE y plataforma, la GA de Metrics API elimina una capa de fragilidad histórica. Herramientas que consumen metrics.k8s.io para autoscaling o dashboards de capacity planning ya pueden depender de contratos de versión estables sin riesgo de breaking changes en upgrades. El scale-to-zero del HPA, activado por default, reduce costos en clusters con GPUs reservadas para inferencia de ML que pasan horas inactivas: un nodo con GPU que escala a cero deja de facturar en la capa de cómputo del cloud provider.
Desde la perspectiva de seguridad, el kubelet rootless por default cambia el modelo de amenaza del nodo. Un atacante que logre ejecutar código dentro del kubelet (por ejemplo, vía un webhook malicioso o un CVE en el runtime) se enfrenta a un proceso que no tiene CAP_SYS_ADMIN, no puede montar filesystems arbitrarios ni modificar cgroups del host. La superficie de ataque se reduce drásticamente. Los certificados de pod nativos eliminan la necesidad de sidecars Istio/Envoy o herramientas como cert-manager para bootstrap de mTLS entre servicios internos, reduciendo la cantidad de componentes con acceso a claves privadas.
La inicialización resiliente del watchcache cierra un vector de outage conocido: en clusters con miles de nodos, un restart del kube-apiserver generaba un thundering herd de requests contra etcd. Con la feature activada, el apiserver delega requests de forma acotada y responde con HTTP 429 (Too Many Requests) al resto, evitando el colapso de la control plane.
Detalles técnicos
KubeletInUserNamespace (beta, default: enabled) utiliza los user namespaces de Linux (kernel 3.8+, recomendado 4.18+) para mapear uid/gid del kubelet a un rango no-privilegiado. El proceso kubelet mantiene privilegios dentro de su namespace pero opera como usuario no-root desde la perspectiva del host. Esto requiere que el runtime de contenedores (containerd, CRI-O) también soporte ejecución en user namespaces. En instalaciones existentes, el upgrade puede requerir ajustar permisos en paths como /var/lib/kubelet, /var/run y mounts de cgroups v2.
metrics.k8s.io (GA) expone métricas de CPU y memoria por nodo y por pod con contrato de estabilidad garantizado. El HPA y el VPA consumen esta API para tomar decisiones de escalado. kubectl top nodes y kubectl top pods dependen de la misma fuente. El scale-to-zero del HPA permite que un Deployment con minReplicas: 0 elimine todos los pods cuando la métrica de utilización cae por debajo del umbral, liberando recursos GPU en nodos cloud.
Pod certificates (GA) implementan un flujo de issuance de certificados X.509 por pod directamente desde kube-apiserver, usando la API certificates.k8s.io/v1beta1 con soporte para rotation automática. Los pods obtienen un certificado firmado por la CA del cluster sin intervención de un controller externo. El handshake mTLS entre pods queda cifrado con TLS 1.3 en los runtimes que lo soportan.
Resilient watchcache initialization (GA, default: enabled) introduce un mecanismo de backpressure en el kube-apiserver al arrancar: en lugar de consultar etcd de forma síncrona por cada recurso, delega requests acotados y responde HTTP 429 al resto, permitiendo que etcd se estabilice antes de recibir carga completa.
Qué deberían hacer los administradores y equipos técnicos
Primero, revisar el estado del feature gate en clusters existentes. Para verificar si KubeletInUserNamespace está activo en un nodo:
kubelet –feature-gates 2>/dev/null | grep KubeletInUserNamespace
# o revisar el kubelet config en /var/lib/kubelet/config.yaml
Si el cluster corre en un kernel anterior a 4.18 o en un proveedor cloud que no habilita user namespaces (algunas instancias de GKE con Sandboxed Containers tienen restricciones), deshabilitar el gate explícitamente en el kubelet config antes del upgrade a 1.37.
Segundo, auditar dependencias de Metrics API. Los operadores de autoscaling custom que consumen metrics.k8s.io deben validar que no usen endpoints en desuso, ya que la GA implica contract stability y los campos deprecated pueden removerse en 1.39+.
Tercero, evaluar la migración de mTLS externo a pod certificates nativos. Si el cluster usa cert-manager + Istio para mTLS de service mesh, planificar la transición gradual: primero habilitar pod certificates para servicios críticos, validar interoperabilidad con el mesh existente y luego retirar sidecars.
Cuarto, en clusters con HPA para cargas de ML con GPUs, habilitar minReplicas: 0 en los Deployments de inferencia y monitorear el cold-start penalty. El scale-to-zero elimina costo de GPU inactiva pero introduce latencia de arranque de nodo (típicamente 60-180 segundos en GKE/AKS con node pools autoscale).
Conclusión
Kubernetes 1.37 no es una release de features espectaculares, pero consolida tres pilares que los operadores llevaban años pidiendo con workarounds: métricas con contrato estable, kubelet sin privilegios de root y mTLS de pod sin infraestructura adicional. El kubelet rootless habilitado por default es, probablemente, el cambio con mayor impacto en la postura de seguridad del nodo desde la introducción de seccomp y AppArmor. Equipos que administren clusters con cargas multi-tenant o con requisitos de compliance (SOC2, ISO 27001, NIS2) deberían priorizar la validación de esta feature en staging antes de promoverla a producción. La próxima release, 1.38, está prevista para diciembre de 2026.
Fuentes
- https://www.infoq.com/news/2026/09/kubernetes-1-37/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global