Kubernetes 1.35 ya no arranca el kubelet en cgroup v1

El blog de Kubernetes publicó el 6 de octubre una guía que ya no es un aviso de futuro. Desde la v1.35, failCgroupV1 vale true por defecto y el kubelet no arranca en un nodo Linux que siga en cgroup v1, salvo que alguien ponga el override a false.

cgroup v2 es estable en Kubernetes desde la 1.25. La v1 pasó a mantenimiento en la 1.31. El artículo de Paco Xu, de DaoCloud, ordena lo que eso implica ahora: quién tiene que migrar antes de subir, qué se gana con la jerarquía única y qué no se arregla solo con el cambio.

-InfraCrew dice: El nodo que «ya lo miraremos en el siguiente upgrade» acaba de convertirse en el nodo que no entra en el upgrade.-

Qué pasa si el nodo sigue en v1

En la configuración por defecto, un nodo cgroup v1 falla al arrancar el kubelet en 1.35 o posterior. El override existe: failCgroupV1: false en el fichero de configuración del kubelet. Kubernetes lo trata como temporal. La retirada sigue KEP-5573 y la política de deprecación. El propio texto dice que en 1.36, la release actual cuando se publicó la guía, el fallback sigue disponible, y que la eliminación está prevista en la 1.38.

En clústeres kubeadm el corte llega antes. El preflight SystemVerification, el de system-validators 1.12.1, devuelve error en kubeadm init, join y upgrade si ve cgroup v1 con kubelet 1.35 o posterior. Con un kubelet más viejo, el mismo chequeo se queda en aviso.

Quien aún no está en 1.35 tiene que pasar los nodos Linux a cgroup v2 antes de subir, o asumir el override y la fecha de caducidad. Quien ya está en 1.35 o más tiene que confirmar que cada nodo Linux está en v2, o que el override es consciente.

Qué pide el nodo y qué no arregla

Hace falta kernel 5.8 o posterior, 5.9 si se va a usar Memory QoS, runtime compatible y el mismo cgroup driver en kubelet y runtime. containerd 1.4 ya soporta v2; para el descubrimiento automático del driver, containerd 2.0 o CRI-O 1.28. Kubernetes recomienda systemd cuando kubeadm gestiona el kubelet. El descubrimiento automático del driver, KEP-4033, es estable desde la 1.34.

Migrar no convierte active_file en memoria disponible. El kubelet sigue sin contarla como reclaimable, y una carga con mucha page cache puede seguir empujando evicciones. El arreglo documentado es igualar request y limit de memoria en esos contenedores, después de medir. Memory QoS, alpha también en 1.36, solo existe en v2: memory.high para frenar y, con TieredReservation, memory.min y memory.low. El proyecto no recomienda alpha en producción.

-InfraCrew dice: cgroup v2 no perdona el request de memoria puesto a ojo. Solo cambia el sitio donde se nota.-

Por qué el cambio deja de ser opcional

En v2 el kubelet deja singleProcessOOMKill a false y marca memory.oom.group, así que un OOM mata los procesos del contenedor juntos y no deja un contenedor a medias. PSI, el control de dispositivos vía BPF y la delegación que usan los contenedores rootless dependen de esta jerarquía. El escalado vertical in-place de recursos de Pod, beta en 1.36, necesita v2 para el enforcement agregado.

Nada de eso obliga a activar funciones alpha el mismo día. Sí obliga a dejar de tratar cgroup v1 como el default silencioso de imágenes antiguas, plantillas de cloud y nodos que nadie reinstaló. El fallo, cuando llegue, no será un pod Pending. Será un kubelet que no levanta y un join que el preflight corta.

Fuentes

Kubernetes Blog | https://kubernetes.io/blog/2026/10/06/kubernetes-cgroups-v2-shift

Diccionario de la Crew

cgroup — Mecanismo del kernel Linux con el que el sistema reparte y limita CPU, memoria y otros recursos de un grupo de procesos. Kubernetes lo usa para los contenedores.