Kubernetes v1.35 impone la migración a cgroup v2 en nodos Linux

El proyecto Kubernetes ha trasladado el soporte para cgroup v1 al modo de mantenimiento, señalando un cambio definitivo hacia la interfaz unificada de gestión de recursos de cgroup v2. A partir de Kubernetes v1.35, kubelet se negará a iniciarse en nodos que sigan utilizando cgroup v1, a menos que los administradores anulen explícitamente este comportamiento. Este cambio afecta a todos los clusters basados en Linux, obligando a los operadores a verificar sus versiones del kernel, los entornos de ejecución de contenedores y las configuraciones de los nodos antes de realizar la actualización.

Qué ha ocurrido

Los grupos de control, o cgroups, son una función del kernel de Linux que permite al sistema operativo asignar recursos como CPU y memoria a procesos específicos. Kubernetes depende de este mecanismo para garantizar que los contenedores no interfieran entre sí. Aunque cgroup v2 ha sido estable en Kubernetes desde la versión 1.25, el soporte para la antigua interfaz v1 está siendo eliminado progresivamente. En Kubernetes v1.35, el parámetro de configuración failCgroupV1 tiene un valor predeterminado de true. Esto significa que si un nodo ejecuta cgroup v1, el proceso kubelet fallará durante el inicio, dejando efectivamente el nodo fuera de línea.

Los administradores que aún no estén listos para migrar pueden establecer temporalmente failCgroupV1: false en su archivo de configuración de kubelet. Sin embargo, esto es solo una medida provisional. La política de obsolescencia de Kubernetes indica que la eliminación completa del soporte para cgroup v1 está próxima, siguiendo el seguimiento KEP-5573. Para los clusters gestionados mediante kubeadm, la imposición es aún más estricta. La comprobación previa SystemVerification, parte de la herramienta k8s.io/system-validators, ahora devuelve un error durante la inicialización, unión o actualización si detecta cgroup v1 en un nodo que ejecuta kubelet v1.35 o posterior. Anteriormente, esto era simplemente una advertencia.

Esta transición no se trata solo de cumplimiento; desbloquea capacidades modernas de gestión de recursos. Cgroup v2 ofrece una jerarquía unificada única, lo que simplifica la interfaz en comparación con las múltiples jerarquías de v1. Proporciona un aislamiento más fuerte y admite nuevas funciones como Pressure Stall Information (PSI) y una calidad de servicio (QoS) de memoria mejorada. Los clusters que permanecen en v1 pierden estas optimizaciones y enfrentan problemas crecientes de compatibilidad con entornos de ejecución de contenedores y herramientas de monitoreo más recientes.

Cómo funciona

Cgroup v2 reemplaza la compleja estructura multi-jerárquica de v1 con un único árbol donde todos los controladores (CPU, memoria, E/S) están adjuntos. Esta unificación permite una contabilidad de recursos más consistente y evita escenarios donde un proceso está limitado por un controlador pero no por otro debido a discrepancias de jerarquía. En Kubernetes, kubelet interactúa con estos controladores para imponer los límites definidos en las especificaciones de Pod. Con v2, kubelet puede usar funciones como memory.high para limitación y memory.min para protección dura, que no eran posibles ni fiables en v1.

La migración también cambia cómo se manejan los eventos de falta de memoria (OOM). En cgroup v2, kubelet establece memory.oom.group para cada cgroup de contenedor. Cuando ocurre un evento OOM, el kernel mata todos los procesos dentro de ese contenedor simultáneamente, en lugar de eliminarlos uno por uno. Esto evita que contenedores parcialmente funcionales permanezcan en un estado roto. Además, cgroup v2 habilita la delegación, permitiendo que contenedores sin privilegios root gestionen sus propios cgroups de forma segura a través de systemd, una capacidad que era arriesgada o imposible en v1.

Detalles clave

• Imposición por defecto: En Kubernetes v1.35, failCgroupV1 tiene un valor predeterminado de true, causando fallos de inicio de kubelet en nodos con cgroup v1.
• Requisitos del Kernel: Se requiere una versión del kernel de Linux 5.8 o posterior para el soporte de cgroup v2, recomendándose 5.9+ para la estabilidad de la QoS de Memoria.
• Soporte del Entorno de Ejecución: Containerd v1.4+ y CRI-O v1.20+ soportan cgroup v2; el descubrimiento automático del driver requiere containerd v2.0+ o CRI-O v1.28+.
• QoS de Memoria: La función alpha de QoS de Memoria, que utiliza memory.high y memory.low, está disponible exclusivamente en nodos con cgroup v2.
• Actualizaciones de Herramientas: Las herramientas de monitoreo deben actualizarse; se recomienda cAdvisor v0.43.0+, junto con versiones compatibles de bibliotecas Java y Node.js.
• Conversión de Peso de CPU: Los entornos de ejecución OCI más recientes como crun v1.23 y runc v1.3.2 utilizan una conversión no lineal desde cpu.shares de v1 a cpu.weight de v2, mejorando la granularidad para pequeñas solicitudes de CPU.

Por qué importa

Para ingenieros de software y equipos de plataforma, este cambio significa que las configuraciones de infraestructura heredadas ya no son viables. Si actualizas tu plano de control a v1.35 sin migrar tus nodos de trabajo, tu cluster se romperá. Los nodos fallarán al unirse, y los nodos existentes podrían fallar al reiniciarse después de un reboot. Esto crea una dependencia estricta de las actualizaciones del sistema operativo, ya que muchas distribuciones Linux antiguas usan cgroup v1 por defecto. Los equipos deben ahora coordinar las actualizaciones del kernel en toda su flota, lo cual puede ser un obstáculo operativo significativo en entornos grandes y heterogéneos.

Más allá del dolor inmediato de la migración, permanecer en v2 desbloquea una mejor eficiencia de recursos. Funciones como PSI proporcionan visibilidad en tiempo real sobre la contención de recursos, permitiendo decisiones de autoscaling más precisas. El manejo mejorado de OOM asegura que los fallos de aplicación sean más limpios y fáciles de depurar. Además, a medida que el escalado vertical in situ se vuelve estable, cgroup v2 es necesario para una imposición agregada precisa. Ignorar esta ruta de migración dejará eventualmente a los clusters incapaces de adoptar estas mejoras de rendimiento y fiabilidad.

Qué puedes hacer

• Verificar Estado Actual: Ejecuta stat -fc %T /sys/fs/cgroup/ en tus nodos. Si devuelve cgroup2fs, ya estás en v2.
• Verificar Versión del Kernel: Asegúrate de que todos los nodos Linux ejecuten kernel 5.8 o posterior. Actualiza el SO si es necesario antes de intentar la actualización de Kubernetes.
• Actualizar Entorno de Ejecución de Contenedores: Confirma que estás usando containerd v1.4+ o CRI-O v1.20+. Idealmente, muévete a containerd v2.0+ para aprovechar el descubrimiento automático del driver de cgroup.
• Configurar Kubelet: Si no puedes migrar inmediatamente, establece failCgroupV1: false en tu configuración de kubelet, pero planifica eliminar esta anulación pronto. Haz coincidir el driver de cgroup con tu entorno de ejecución, preferiblemente usando systemd.
• Actualizar Stack de Monitoreo: Actualiza cAdvisor a v0.43.0 o posterior y verifica que tus scrapers de Prometheus y otras herramientas de monitoreo soporten métricas de cgroup v2.
• Probar QoS de Memoria: Si usas gestión avanzada de recursos, prueba las funciones alpha de QoS de Memoria en un entorno de pruebas para entender cómo la limitación de memory.high afecta a tus cargas de trabajo.