Volver al Blog
Cloud e Infraestructura 15 de mayo de 2026 5 min read

Kubernetes v1.36 'Haru': User Namespaces en GA y DRA Mejorado para Cargas de IA y GPU

Kubernetes 1.36 trae 70 mejoras, con User Namespaces alcanzando Disponibilidad General y un marco de Dynamic Resource Allocation que madura para la programación de cargas de IA y GPU a escala.

Kubernetes v1.36 'Haru': User Namespaces en GA y DRA Mejorado para Cargas de IA y GPU

Kubernetes v1.36, con el nombre en clave “Haru” (primavera en japonés), se lanzó el 12 de mayo de 2026 con 70 mejoras — 18 alcanzando el estado Estable, 25 entrando en Beta y 25 en Alpha. Es la versión más orientada a la seguridad desde la 1.30 y la más significativa para la infraestructura de IA y GPU desde que se introdujo Dynamic Resource Allocation.

User Namespaces llega a Disponibilidad General

La función de seguridad principal: User Namespaces ya es estable. Esto asigna el usuario root dentro de un contenedor a un usuario sin privilegios en el host, lo que significa que un exploit de escape de contenedor que logre privilegios de root en el host ya no obtiene root en el nodo. El atacante aterriza como usuario sin privilegios y se enfrenta a los límites de permisos estándar de Linux.

Esta ha sido la mejora de seguridad de contenedores más demandada durante años. El retraso fue arquitectónico: requería cambios profundos en la forma en que kubelet gestiona el mapeo UID/GID y tenía que funcionar en múltiples tiempos de ejecución de contenedores (containerd, CRI-O). La versión 1.36 cierra esa brecha.

Para los equipos de seguridad: User Namespaces debería activarse por defecto en nuevas cargas de trabajo. Cualquier carga existente que no requiera acceso real al root del host debería migrarse para usarlo.

Otras dos funciones también alcanzaron el estado Estable: las Mutating Admission Policies (un reemplazo basado en CEL para los Mutating Admission Webhooks sin la sobrecarga de viajes de red) y la Autorización de API de Kubelet de Grano Fino (que permite a los operadores controlar qué kubelets pueden realizar qué llamadas a la API, fundamental en clústeres multi-inquilino).

DRA madura: ResourceClaims para CPU, memoria y PodGroups

Dynamic Resource Allocation (DRA) se introdujo para resolver un problema real: la API de plugins de dispositivos de Kubernetes nunca fue diseñada para la complejidad de programación que exigen las cargas de trabajo de IA. Asignar GPUs fraccionadas, coordinar la topología de GPU entre nodos y manejar aceleradores especializados requiere un contrato más rico entre el programador y el hardware.

En la versión 1.36, DRA se extiende más allá de las GPU a los recursos nativos de CPU y memoria. Más significativamente, los ResourceClaims ahora pueden tener el alcance de PodGroups — un conjunto de pods que deben programarse juntos o no ejecutarse en absoluto. Esta es la primitiva fundamental para la programación en grupo de trabajos de entrenamiento de IA. Tienes 8 pods que cada uno necesita una GPU específica; o los 8 aterrizan en la topología correcta o ninguno se ejecuta.

Esto no resuelve todos los problemas de programación de IA, pero proporciona el núcleo sobre el que los equipos de plataforma de IA pueden construir. Los frameworks de ML nativos en la nube comenzarán a apuntar a las reclamaciones de PodGroup de DRA en sus próximas versiones principales.

Funciones Alpha a seguir

La mejora Alpha más práctica: el redimensionamiento en línea de PersistentVolume para AWS EBS. Actualmente, ampliar un PVC en EBS requiere desconectar el volumen y volver a conectarlo, causando tiempo de inactividad. La función Alpha permite el redimensionamiento en línea sin reinicio del pod. Esto importa más de lo que parece para cargas de trabajo con estado (bases de datos, checkpoints de ML) que se ejecutan en EBS.

El Node Lifecycle Controller graduó a Beta, estandarizando cómo los nodos informan su estado de salud y se vacían graciosamente.

Notas de actualización

La versión 1.36 elimina el soporte para varias APIs obsoletas señaladas en la 1.33. Revisa la guía de migración antes de actualizar clústeres de producción, especialmente si todavía usas versiones antiguas de FlowSchema o ClusterCIDR. Los cambios en kubectl diff para las políticas de admisión son sustanciales si tienes muchos webhooks.

La versión 1.36 es el lanzamiento donde la arquitectura de seguridad de Kubernetes se pone a la altura del modelo de amenazas de 2026.

Kubernetes CNCF cloud security AI infrastructure