8 min de lectura
Kubernetes 1.36 alcanzó la disponibilidad general (GA) el 22 de abril de 2026. Dos cambios ocupan el centro de atención: la eliminación definitiva de cgroup-v1 y la disponibilidad general de Dynamic Resource Allocation (DRA). Para los equipos de operaciones empresariales, esto implica tareas concretas en los próximos 60 días, antes de que expiren el soporte upstream y los parches de seguridad para versiones antiguas de clústeres. Una lista de verificación para la migración sin sobrecarga teórica.
Lo más importante en resumen
- Kubernetes 1.36 GA 22.04.2026: se elimina el soporte para cgroup-v1, DRA alcanza la disponibilidad general
- Quienes aún ejecuten cgroup-v1 (identificable por –cgroup-driver=cgroupfs) deben migrar a containerd + cgroup-v2 antes de actualizar
- DRA-GA: la instalación del controlador de recursos y las CRD NodeFeature son ahora obligatorias para cargas de trabajo GPU/FPGA
- Requisito mínimo de containerd: 1.7.x para soporte con 1.36, se recomienda 2.0
- Ventana temporal: Kubernetes 1.33 llega al fin de vida útil en octubre de 2026; quienes aún usen 1.33 deben actualizar ahora
RelacionadoEdge Computing 2026: ThinkEdge SE60n Gen 2 en prueba práctica / FinOps 2026: Control de costes cloud empresariales
¿Qué es Kubernetes 1.36 y por qué esta versión es crítica para la migración?
¿Qué es Kubernetes 1.36? Kubernetes 1.36 es la versión publicada el 22 de abril de 2026 del sistema de orquestación de contenedores de código abierto y marca la eliminación definitiva del soporte para cgroup-v1, así como la disponibilidad general de Dynamic Resource Allocation (DRA) para recursos de hardware como GPUs y FPGAs.
Kubernetes 1.36 es la primera versión que elimina completamente cgroup-v1. cgroup v1 (Control Groups version 1) era la interfaz clásica del kernel de Linux para el aislamiento de recursos: límites de RAM, cuotas de CPU, jerarquías de procesos. Desde Kubernetes 1.25, cgroup-v2 era la ruta estándar. Con 1.36, cgroup-v1 ya no está obsoleto de forma opcional, sino eliminado.
Esto significa: quien opere un nodo aún con el controlador cgroupfs bajo cgroup-v1 no podrá iniciarlo tras actualizar a 1.36. El Kubelet arrojará un error durante la comprobación de inicialización. No es una transición suave, es una parada en seco.
Cifras sobre la migración
23%
de los clústeres empresariales seguían usando cgroup-v1 o tenían un estado incierto según la encuesta CNCF T1 2026
Oct 2026
K8s 1.33 Fin de vida útil: quienes aún usen 1.33 tienen 5 meses
containerd 2.0
Versión recomendada para K8s 1.36: 1.7.x es el mínimo, 2.0 es la ruta con soporte
Paso 1: Comprobar el estado del clúster (versión cgroup y containerd)
Antes de que nadie actualice, cada nodo necesita un inventario. Dos comprobaciones, ambas pueden ejecutarse de forma remota mediante kubectl:
Versión cgroup por nodo:
xargs -I{} kubectl describe node {} | grep «Container Runtime»
# O directamente en el nodo:
stat -fc %T /sys/fs/cgroup
# Salida «tmpfs» = cgroup-v1, «cgroup2fs» = cgroup-v2
Versión y configuración de containerd:
# Mín: 1.7.x | Recomendado: 2.0.x
# Comprobar el controlador cgroup de containerd:
grep -i cgroup /etc/containerd/config.toml
# Debería mostrar «SystemdCgroup = true» (cgroup-v2)
Quien vea SystemdCgroup = false o no tenga ninguna entrada, aún funciona en modo cgroupfs. Este es el principal obstáculo para la actualización a 1.36.
Paso 2: Migración a cgroup-v2 a nivel de nodo
La migración del nodo de cgroup-v1 a cgroup-v2 requiere un cambio en los parámetros del kernel y un ciclo de reinicio con drenaje del nodo. No es posible una actualización progresiva (rolling upgrade); cada nodo debe ser drenado.
1. Ajustar los parámetros de arranque del kernel (GRUB o systemd-boot según el SO):
GRUB_CMDLINE_LINUX=»systemd.unified_cgroup_hierarchy=1 cgroup_no_v1=all»
update-grub && reboot
2. Actualizar la configuración de containerd:
[plugins.»io.containerd.grpc.v1.cri».containerd.runtimes.runc.options]
SystemdCgroup = true
3. Ajustar la configuración de Kubelet:
cgroupDriver: systemd
# Secuencia de reinicio:
kubectl drain <node> –ignore-daemonsets
systemctl restart containerd kubelet
kubectl uncordon <node>
«Un nodo que no se reinicia correctamente tras el drenaje es el momento en que la planificación choca con la realidad. Planifica 45 minutos por nodo, no 15.»
– Alec Chizhik, cloudmagazin
Paso 3: Configurar DRA – Asignación Dinámica de Recursos
DRA está disponible como General Availability en 1.36. ¿Qué significa esto para los equipos con cargas de trabajo de GPU o FPGA? DRA reemplaza el antiguo mecanismo de Device Plugin para recursos de hardware. Quien ejecute GPUs NVIDIA mediante el NVIDIA Device Plugin debe comprobar si el driver del fabricante ya es compatible con DRA.
Comprobaciones obligatorias de DRA para entornos GPU:
kubectl get –raw /api/v1 | grep -i «dynamic»
# Comprobar las CRDs ResourceSlice y DeviceClass:
kubectl get crd | grep resource.k8s.io
# Salida esperada:
# deviceclasses.resource.k8s.io
# resourceclaims.resource.k8s.io
# resourceslices.resource.k8s.io
NVIDIA introdujo el soporte DRA con NVIDIA GPU Operator 25.x. El soporte DRA de AMD ROCm está anunciado para el segundo trimestre de 2026. Quien utilice GPUs Intel (Gaudi, Arc) debe comprobarlo por separado; las Intel Extensions for Kubernetes tienen su propio ciclo de lanzamiento.
Ventajas e inconvenientes: directamente a 1.36 o paso intermedio por 1.35
Habla a favor de ir directamente a 1.36
- Una migración en lugar de dos (sin versión intermedia)
- DRA-GA disponible inmediatamente
- Mayor horizonte de soporte (EOL 1.36: ~abril 2027)
- Una ventana de inactividad en lugar de dos
Habla a favor del paso intermedio por 1.35
- Migración cgroup-v2 preparable en 1.35 sin cambios de 1.36
- DRA aún en beta en 1.35 – menos sorpresas si no hay carga de trabajo GPU
- División de riesgos: migración de infraestructura + actualización de API separadas
Preguntas frecuentes
¿Debo activar cgroup-v2 antes de actualizar a K8s 1.36?
Sí, es un requisito obligatorio. K8s 1.36 no se inicia en nodos que aún funcionan en modo cgroup-v1. La migración debe completarse a nivel de nodo antes de la actualización de Kubernetes (parámetros GRUB + configuración containerd + config kubelet).
¿Qué versión de containerd necesito para Kubernetes 1.36?
El mínimo es containerd 1.7.x. Se recomienda containerd 2.0.x para soporte completo. containerd 1.6.x ya no es compatible. Verificar con containerd –version.
¿Es DRA un reemplazo para NVIDIA Device Plugin?
A medio plazo sí, a corto plazo ambos en paralelo. DRA es GA desde K8s 1.36, pero los controladores de fabricantes tienen sus propias hojas de ruta. NVIDIA GPU Operator soporta DRA desde 25.x. El Device Plugin sigue funcionando en paralelo hasta que los fabricantes cambien oficialmente a solo DRA.
¿Qué pasa con mis cuotas de recursos existentes tras la migración a cgroup-v2?
Los límites de memoria y CPU permanecen semánticamente idénticos bajo cgroup-v2. La diferencia: cgroup-v2 aplica los límites con mayor precisión, especialmente en escenarios de sobrecompromiso de memoria. En casos raros, las cargas de trabajo que funcionaban al límite bajo cgroup-v1 pueden recibir señales OOM antes bajo cgroup-v2.
¿Cómo verifico si mi servicio de Kubernetes gestionado (EKS, GKE, AKS) ya está en cgroup-v2?
EKS: Amazon Linux 2023 usa cgroup-v2 por defecto. Amazon Linux 2 sigue usando cgroup-v1. GKE: Todos los nodos con Container-Optimized OS desde 2023 usan cgroup-v2. AKS: Los nodos Ubuntu estándar están en cgroup-v2 desde AKS 1.25. Verificar con stat -fc %T /sys/fs/cgroup en un nodo.
Red
Industria 5.0: Lo que los CIO deben decidir ahora (Digital Chiefs) | Nearshoring 2026: Marco de decisión (MyBusinessFuture)
Fuente imagen principal: Pexels / cottonbro studio (px:6804597)
