failCgroupV1: false en Kubernetes: cgroup v1 tiene los días contados

El 6 de octubre de 2026 el blog oficial de Kubernetes publicó "The Shift to cgroup v2 in Kubernetes: What You Need to Know" (Paco Xu, DaoCloud). Es un recordatorio público de algo que ya está en producción desde la 1.35: si un nodo todavía usa cgroup v1, el kubelet se niega a arrancar. La salida de emergencia es failCgroupV1: false, y esa salida es temporal.

cgroup v1 en Kubernetes es la interfaz antigua del kernel de Linux para limitar y medir CPU, memoria y E/S de los contenedores. Kubernetes la mantiene solo en modo mantenimiento desde la 1.31 y, desde la 1.35, el kubelet no arranca en un nodo con v1 salvo que el admin lo permita con failCgroupV1: false. Le importa a quien opere nodos propios (kubeadm, K3s, bare metal o VMs), no a quien usa un servicio gestionado que ya migró.

¿Qué pasa si el kubelet arranca en un nodo con cgroup v1?

Con la configuración por defecto de la 1.35 en adelante, el kubelet falla al inicializar y el nodo no se une al clúster o queda NotReady. Según la KEP-5573, la 1.35 cambió el default de FailCgroupV1 de false a true y actualizó el mensaje de advertencia a "cgroup v1 support is deprecated and will be removed in a future release".

Lo que más sorprende en la práctica es cuándo aparece el problema: no cuando el nodo está andando, sino en el reinicio del kubelet o al sumar un nodo nuevo. Un upgrade de versión que parecía rutinario termina siendo el momento en que descubrís que la mitad de la flota sigue en v1.

• Nodos existentes que reinician el kubelet: si el host está en v1, el kubelet 1.35+ no vuelve a levantar.
• Nodos nuevos o reemplazados: una imagen base vieja va a fallar al hacer el join.
• kubeadm: según lo que documentan las notas de la 1.35, el preflight SystemVerification devuelve error en init, join y upgrade cuando detecta cgroup v1. Verificá el detalle en las release notes de tu versión.
• Entornos de prueba: en diciembre de 2025 se abrió en el proyecto minikube un issue titulado "Set 'FailCgroupV1' to 'false'. skip this validation" (issue #22315).

¿Hasta cuándo se puede usar failCgroupV1: false?

Es un parche temporal sin fecha de vencimiento confirmada. La KEP oficial dice textualmente: "We will commit to removing cgroup v1 code but there is not yet a timeline for removal. The removal will be done no earlier than 1.38" (KEP-5573, Remove cgroup v1 support).

Ojo con las notas de terceros: varias hablan de "eliminación en la 1.38" como si estuviera agendada. Lo que dice la KEP es "no antes de la 1.38", sin versión definida. Para planificar, tomalo así: la opción puede desaparecer en cualquier release desde la 1.38, y ese día un nodo en v1 no tiene override posible. Mi postura: tratá failCgroupV1: false como una deuda con fecha límite, no como configuración.

¿Qué se rompe al migrar de cgroup v1 a v2?

Lo primero que se rompe no es Kubernetes sino lo que está debajo: kernel, runtime y herramientas que leen rutas de cgroup. Según la documentación oficial, v2 requiere kernel 5.8 o superior, containerd 1.4+ o CRI-O 1.20+ y el driver de cgroups systemd tanto en kubelet como en el runtime.

• Kernels viejos: si tenés distros con kernel anterior a 5.8, el problema no se arregla con una flag. Hay que actualizar el SO.
• Runtime desalineado: kubelet y containerd/CRI-O tienen que usar el mismo cgroup driver (systemd). Un cgroupfs en uno y systemd en el otro da pods que no arrancan o métricas inconsistentes.
• Agentes de monitoreo y scripts propios: cualquier cosa que lea /sys/fs/cgroup/cpu/... o /sys/fs/cgroup/memory/... deja de encontrar esas rutas, porque v2 usa una jerarquía unificada.
• Comportamiento de OOM: la KEP lista entre los riesgos que cgroup v2 cambia la semántica del out-of-memory killer. Revisá los límites de memoria y los reinicios por OOMKilled después de migrar.
• Prioridad de CPU: el pasaje de cpu.shares a cpu.weight tenía un problema de conversión. Según el blog de Kubernetes del 30 de enero de 2026, la fórmula vieja convertía 1 CPU (1000m) en un peso de aproximadamente 39, menos del 40% del valor por defecto de 100 en v2.

¿Cómo afecta el cambio de fórmula de CPU a mis pods?

La corrección se aplica en la capa del runtime OCI, no en Kubernetes: el kubelet calcula los shares igual que antes y runc (desde 1.3.2) y crun (desde 1.23) aplican la nueva conversión al escribir el peso. Si actualizás el runtime junto con la migración a v2, pods con requests chicos pueden recibir más CPU relativa que antes. No es un bug, pero conviene comparar la latencia de tus workloads antes y después.

¿Por qué Kubernetes abandona cgroup v1?

Porque el ecosistema Linux ya se mudó a v2 y mantener dos implementaciones cuesta. El blog oficial lo resume así: "Support for v2 cgroup management has been stable since Kubernetes v1.25" y v1 entró en modo mantenimiento con la 1.31, es decir, sin funcionalidades nuevas.

La línea de tiempo oficial es corta:

• Kubernetes 1.25: el soporte de cgroup v2 pasa a estable.
• Kubernetes 1.31: cgroup v1 entra en modo mantenimiento.
• Kubernetes 1.35: failCgroupV1 pasa a true por defecto; el kubelet no arranca en v1 sin override.
• Kubernetes 1.38 o posterior: fecha más temprana posible para eliminar el código de v1 (KEP-5573), sin versión confirmada.

Entre 1.31 y 1.35 hubo aviso previo, así que la 1.35 no debería haber sido una sorpresa. Lo que sí sorprende es lo tarde que se descubre en nodos que nadie tocó desde que se instalaron.

¿Cómo saber si mis nodos usan cgroup v1 o v2?

Con un solo comando en cada nodo. La documentación de Kubernetes indica stat -fc %T /sys/fs/cgroup/: si devuelve cgroup2fs estás en v2; si devuelve tmpfs, estás en v1.

# En cada nodo
stat -fc %T /sys/fs/cgroup/
# cgroup2fs  -> cgroup v2 (OK)
# tmpfs      -> cgroup v1 (hay que migrar)

# Kernel (v2 requiere 5.8 o superior)
uname -r

# Runtime
containerd --version

Para una flota, ejecutá el stat por SSH, con Ansible o con un DaemonSet que lo reporte, y armá la lista de nodos en tmpfs antes de planificar upgrades. Como orientación general (verificá en tu versión): Ubuntu 22.04 y 24.04, Debian 11+ y RHEL 9 arrancan con v2 por defecto, mientras que Ubuntu 20.04 y RHEL 8 suelen usar v1.

¿Cómo migro un nodo a cgroup v2 paso a paso?

El camino más seguro es rotar nodos: sumar uno con SO y kernel actuales, drenar el viejo y repetir. Cambiar la jerarquía en caliente sobre un nodo con carga es posible, pero es el camino con más riesgo.

1. Inventariá: corré el stat en todos los nodos y anotá kernel, distro y runtime.
2. Actualizá el SO si hace falta: si el kernel es anterior a 5.8, necesitás una distro más nueva.
3. Habilitá v2 en el host: si la distro lo soporta pero arranca en v1, se activa con el parámetro de kernel systemd.unified_cgroup_hierarchy=1 y un reinicio.
4. Alineá el driver: en containerd, SystemdCgroup = true en las opciones de runc; en el kubelet, cgroupDriver: systemd.
5. Probá con un nodo canario: desplegá una carga real, mirá OOMKilled, throttling de CPU y métricas.
6. Drená y reemplazá el resto: con kubectl drain, respetando tus PodDisruptionBudgets.

¿Cómo uso failCgroupV1: false como medida temporal?

Se configura en el archivo del kubelet y vale para ganar tiempo, no para quedarse. Anotá en tu tablero de deuda técnica la fecha para sacarlo.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failCgroupV1: false

Con esto el kubelet arranca en v1, pero los logs siguen mostrando la advertencia de deprecación. Si tu monitoreo la ignora, el día que el override desaparezca vas a enterarte por un nodo caído.

Preguntas frecuentes

¿Kubernetes 1.35 ya no funciona en cgroup v1?

No funciona por defecto: el kubelet 1.35 o posterior no arranca en un nodo con cgroup v1 salvo que configures failCgroupV1: false.

¿Cuándo se elimina definitivamente el soporte de cgroup v1?

No hay fecha confirmada. La KEP-5573 dice que la eliminación se hará "no antes de la 1.38" y que todavía no hay cronograma.

¿Qué kernel necesito para cgroup v2?

Linux 5.8 o superior según la documentación de Kubernetes. Para algunas funciones, como Memory QoS, se recomienda 5.9 o más.

¿Cómo verifico la versión de cgroup de un nodo?

Ejecutá stat -fc %T /sys/fs/cgroup/. cgroup2fs indica v2 y tmpfs indica v1.

¿Hace falta cambiar el runtime de contenedores?

Solo si es muy viejo. Se necesita containerd 1.4+ o CRI-O 1.20+, y que el cgroup driver sea systemd en ambos lados.

¿Los servicios gestionados están afectados?

Depende de cada proveedor y de la imagen de nodo que use. Si operás nodos propios, la responsabilidad es tuya; si no, consultá la documentación de tu servicio.

¿Qué hacer hoy?

Corré el stat en todos tus nodos esta semana. Si todo da cgroup2fs, no tenés nada que hacer. Si no, tenés un inventario de deuda con un plazo incierto pero real.

Fuentes: The Shift to cgroup v2 in Kubernetes (blog oficial, 6/10/2026), KEP-5573, New Conversion from cgroup v1 CPU Shares to v2 CPU Weight.

Cloud Serversby Donweb

Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.

• Performance que te sorprenderá
• Rápida escalabilidad y sin limitaciones
• Arquitectura de alta disponibilidad
• Soporte experto y ejecutivos de cuenta
• Pagos en tu moneda y facturación local

Descubre la mejor solución de Cloud Hosting