6 min. Tiempo de lectura
Kubernetes 1.36 „Haru“ es GA desde el 22 de abril de 2026 y trae dos cambios que generan una necesidad inmediata de acción para los clusters empresariales en la región DACH: cgroup v1 ya no está desactualizado, sino que ha sido completamente eliminado — la asignación dinámica de recursos para cargas de trabajo GPU ahora es estable. Quienes aún utilizan cgroup v1 no podrán realizar una actualización después de esta versión sin migrar previamente.
Lo más importante en resumen
- Kubernetes 1.36 „Haru“ ya es GA desde el 22 de abril de 2026: cgroup v1 ha sido completamente eliminado; no hay retorno al upgrade anterior.
- cgroup v2 es obligatorio: todos los nodos deben haber sido migrados a cgroup v2 antes de la actualización — RHEL 9+, Ubuntu 22.04+ y SLES 15 SP5+ ya lo tienen activado por defecto.
- La asignación dinámica de recursos (DRA) es estable: el scheduling estructurado de GPU/FPGA sin necesidad de plugins de dispositivos ya está listo para producción.
- API de trabajos: el control de paralelismo sucesivo es estable — la gestión máxima de flujos para cargas de trabajo por lotes ha mejorado significativamente.
- Recomendación: se debe suspender el freeze de actualizaciones solo después de validar cgroup v2 en todos los nodos de trabajo de todos los clusters.
¿Qué es cgroup v2? Control Groups Version 2 (cgroup v2) es el mecanismo del kernel Linux para la gestión de recursos de procesos y contenedores. A diferencia de cgroup v1, cgroup v2 funciona con una jerarquía unificada en lugar de varias subjerarquías paralelas — esto simplifica la contabilidad de recursos y permite una gestión más precisa de la memoria OOM, así como la señalización de presión y el control de la latencia de E/S para cargas de trabajo en contenedores.
cgroup v1 ya no existe – no está deprecado, sino eliminado
La diferencia más importante con respecto a anuncios anteriores: el proyecto Kubernetes no ha puesto cgroup v1 en estado de deprecación, sino que lo ha eliminado directamente. Ya no existe un “período de gracia de deprecación” para la versión 1.36. Quien actualice sin migrar previamente todos los nodos a cgroup v2, verá fallar la actualización.
Concretamente: kubelet y la runtime de contenedores (containerd, CRI-O) esperan que cgroup v2 esté activo como característica del kernel en cada nodo. En los nodos que aún funcionan en modo cgroup v1, kubelet dejará de arrancar después de la actualización. Esto afecta especialmente a las organizaciones que todavía operan en nodos RHEL 8 o Ubuntu 20.04 más antiguos – ambos sistemas utilizan cgroup v1 como configuración predeterminada.
Estado de la migración según distribución
| Distribución | cgroup v2 por defecto a partir de | Necesidad de acción |
|---|---|---|
| RHEL 9 / Rocky 9 / Alma 9 | a partir del lanzamiento (2022) | Ninguna – ya utiliza cgroup v2 |
| RHEL 8 / CentOS 8 | No es la configuración predeterminada | Actualizar el SO a RHEL 9 o habilitar manualmente cgroup v2 |
| Ubuntu 22.04 LTS | a partir del lanzamiento (2022) | Ninguna – ya utiliza cgroup v2 |
| Ubuntu 20.04 LTS | No es la configuración predeterminada | Configurar parámetros del kernel systemd o actualizar a 22.04 |
| SLES 15 SP5+ | a partir de SP5 | Ninguna a partir de SP5 – revisar versiones anteriores |
„La decisión de eliminar completamente cgroup v1 en lugar de deprecarlo refleja el grado de madurez de cgroup v2 tanto en el kernel como en las runtimes de contenedores. Ya no existe ninguna razón técnica para seguir utilizando v1.“
Kubernetes SIG-Node, Notas de lanzamiento 1.36
Asignación Dinámica de Recursos (DRA) estable: Qué significa para las cargas de trabajo de GPU
La Asignación Dinámica de Recursos ha pasado del estado Beta a Estable en la versión 1.36. DRA resuelve un problema fundamental en las cargas de trabajo de GPU y aceleradores: los plugins de dispositivos, como el NVIDIA-Device-Plugin, han implementado hasta ahora una asignación estática 1:1 de slots de GPU a pods. Varios pods no podían compartir una GPU de forma estructurada. Con DRA, los administradores de clústeres pueden dividir granularmente los recursos de GPU mediante ResourceClasses y ResourceClaims: un slice de GPU para un pod de inferencia, otro para un trabajo de entrenamiento.
Ventajas de DRA para empresas
- Compartición de GPU sin requisitos de hardware NVIDIA MIG
- Los ResourceClaims tienen ámbito de namespace – aptos para multi-inquilino
- Mejor aprovechamiento del costoso hardware de aceleradores
- Configuración declarativa en lugar de hacks de Device-Plugin
La transición requiere
- Los Device Plugins existentes deben migrar a la API de DRA
- Necesario NVIDIA-Device-Plugin v0.17+ para compatibilidad con DRA
- El scheduler y kubelet deben tener activada la feature-gate de DRA
- No existe una ruta de migración automática desde despliegues antiguos de Device-Plugin
Qué deben verificar ahora los equipos empresariales en la región DACH
Lista de verificación para la actualización a Kubernetes 1.36
- Verificar cgroup v2 en todos los nodos worker: stat -fc %T /sys/fs/cgroup/ debe devolver cgroup2fs
- Verificar la versión del Container-Runtime: containerd 1.7+ y CRI-O 1.28+ soportan cgroup v2 nativamente
- Verificar clústeres gestionados: EKS, GKE y AKS migran los nodos automáticamente al actualizar la versión de Kubernetes
- Clústeres autogestionados: rotar todos los nodos o migrar manualmente antes de la actualización
- Verificar la versión del NVIDIA-Device-Plugin si se utilizan cargas de trabajo de GPU
Fuente de los datos: Blog de Kubernetes, Notas de lanzamiento de Kubernetes 1.36, CNCF TAG-Runtime, Blog de NVIDIA abril 2026.
Más contenido de la red MBF Media
- SecurityToday: Zero-Days en Ivanti EPMM – Qué deben hacer ahora los operadores de infraestructuras críticas
- Digital Chiefs: Gobernanza de Smart City 2026 – Aprendizajes para CIOs del retraso urbano
- MyBusinessFuture: Clean Industrial Deal – Qué deben implementar las empresas productivas a partir de 2027
Preguntas frecuentes
¿Puedo activar cgroup v1 en Kubernetes 1.36?
No. Con Kubernetes 1.36, el código de cgroup v1 se ha eliminado por completo de kubelet y de las bibliotecas internas de Kubernetes. No existe ningún Feature-Gate que reactive cgroup v1. Quien permanezca en la versión 1.35 o anterior puede seguir utilizando cgroup v1, pero una actualización a 1.36+ requiere obligatoriamente cgroup v2 en todos los nodos.
¿Cómo puedo comprobar si mis nodos ya utilizan cgroup v2?
En cada nodo: stat -fc %T /sys/fs/cgroup/. Si devuelve cgroup2fs, significa que cgroup v2 está activo. Si devuelve tmpfs, aún se está usando cgroup v1. Alternativamente: cat /proc/1/cgroup – si todas las entradas convergen en una sola línea con 0::/, el sistema utiliza cgroup v2 unificado.
¿Afecta la eliminación de cgroup v1 también al Kubernetes gestionado en AWS/GCP/Azure?
En EKS, GKE y AKS, la migración de los nodos a cgroup v2 es realizada automáticamente por el proveedor de nube durante la actualización de la versión de Kubernetes – los nuevos grupos de nodos o Managed Node Groups rotan hacia imágenes base compatibles con cgroup v2. Problemáticos son los grupos de nodos autogestionados o los grupos de instancias Spot con AMIs personalizados que aún funcionan con Ubuntu 20.04 o Amazon Linux 2 (sin configuración de cgroup v2).
¿Cuándo debería comenzar la actualización a la versión 1.36?
Solo después de la validación completa de cgroup v2 en todos los nodos trabajadores del clúster. La ruta recomendada: actualizar el clúster de staging, observar todas las cargas de trabajo durante 2 semanas y luego realizar una actualización progresiva (rolling upgrade) de los clústeres de producción nodo a nodo. En clústeres gestionados con actualización automática: abrir la ventana de actualización automática solo después de validar la compatibilidad de los nodos.
¿Qué cambios hay para los equipos que ejecutan cargas de trabajo GPU con NVIDIA-Device-Plugin?
El clásico NVIDIA-Device-Plugin sigue funcionando en Kubernetes 1.36 – no utiliza la API de Device-Plugin DRA. Quien quiera migrar de Device-Plugin a DRA necesita NVIDIA-Device-Plugin v0.17+ y debe redefinir ResourceClasses y ResourceClaims para sus cargas de trabajo GPU. La migración es opcional pero recomendada para clústeres GPU multiinquilino que deben compartir hardware de acelerador.
Fuente imagen principal: Pexels | Base fáctica: Blog de Kubernetes, CNCF, Blog de desarrolladores de NVIDIA
