Kubernetes 1.37 mejora la gestión de cargas de IA y acelera la retirada de cgroup v1 y kube-dns
Fecha efectiva / observada:
Qué ha cambiado
Kubernetes 1.37, llamado Garhwal, introduce 67 mejoras y combina nuevas capacidades para cargas complejas —incluidas IA/ML y HPC— con varios avisos de migración que los administradores de clústeres no deberían dejar para el final. QUÉ HA CAMBIADO Kubernetes 1.37 fue publicado el 26 de agosto de 2026. La release incluye: - 16 mejoras que pasan a Stable; - 23 que pasan a Beta; - 27 que entran en Alpha; - 1 deprecación o retirada formal. No todas tienen el mismo impacto. Para RA, los cambios más útiles para seguir son: - gang scheduling en Beta para cargas multipod; - KYAML en Stable; - metrics.k8s.io en Stable; - SELinuxMount y SELinuxChangePolicy en Stable; - deprecación de kube-dns; - deprecación del modo ipvs de kube-proxy; - prohibición definitiva de referencias a Secrets o ConfigMaps desde static Pods; - avance de la retirada de cgroup v1. GANG SCHEDULING: UNA MEJORA IMPORTANTE PARA IA, ML Y HPC El planificador tradicional de Kubernetes evalúa Pods de forma individual. Eso puede ser problemático para trabajos distribuidos donde varias partes deben arrancar juntas. Un entrenamiento de IA, una simulación HPC o una carga paralela puede reservar algunos Pods mientras otros quedan pendientes por falta de recursos. El resultado puede ser: - recursos ocupados sin que el trabajo llegue a arrancar; - bloqueos entre cargas que compiten; - utilización ineficiente del clúster. Kubernetes 1.37 lleva el gang scheduling a Beta. La idea es tratar un grupo de Pods como una unidad y programarlo con una política de “todo o nada”, o al menos respetando un `minCount` definido. Si no hay recursos suficientes para cumplir ese mínimo, los Pods no se vinculan a nodos todavía. PERO BETA NO SIGNIFICA ACTIVADO POR DEFECTO Este matiz es importante. En Kubernetes 1.37 el gang scheduling está en Beta, pero sigue desactivado por defecto. Para utilizarlo hay que habilitar el feature gate `GenericWorkload` en los componentes correspondientes y utilizar la API de scheduling asociada. Por tanto, actualizar a 1.37 no convierte automáticamente los Jobs existentes en gang scheduled. El comportamiento tradicional sigue disponible y, cuando no se configura una política de gang scheduling, los Pods pueden continuar programándose de forma individual. WORKLOAD-AWARE PREEMPTION La misma evolución incluye preemption consciente de grupos de trabajo. Cuando un PodGroup no puede programarse, el scheduler puede evaluar qué recursos liberar pensando en el grupo completo en vez de tratar cada Pod aisladamente. Esto intenta evitar preemptions que expulsan cargas pero no consiguen liberar suficientes recursos para que el trabajo que espera pueda avanzar. Es especialmente relevante en clústeres con GPUs u otros recursos caros y escasos. KYAML PASA A STABLE KYAML alcanza Stable en Kubernetes 1.37. Es un subconjunto más estricto y menos ambiguo de YAML pensado para Kubernetes. No sustituye YAML ni obliga a reescribir los manifiestos existentes. Un archivo KYAML sigue siendo YAML válido, y Kubernetes puede continuar leyendo los manifiestos actuales. La utilidad está en ofrecer una representación más predecible para personas y herramientas. `kubectl get -o kyaml` también pasa a Stable. METRICS.K8S.IO PASA A STABLE La API `metrics.k8s.io`, utilizada para exponer métricas de CPU y memoria de Pods y nodos, alcanza Stable después de años en Beta. Esta API está detrás de funciones conocidas como: - `kubectl top`; - HorizontalPodAutoscaler; - herramientas que consumen métricas básicas de recursos. La versión `v1beta1` no desaparece inmediatamente. Kubernetes mantiene un periodo de transición conforme a su política de deprecación de APIs. SELINUX: CAMBIO QUE PUEDE AFECTAR A VOLÚMENES `SELinuxMount` y `SELinuxChangePolicy` llegan a Stable y se habilitan por defecto. Cuando un CSI driver declara soporte mediante `.spec.seLinuxMount: true`, Kubernetes puede montar un volumen con un contexto SELinux específico en lugar de relabelar recursivamente todo el contenido. Esto puede ser mucho más eficiente. Sin embargo, hay un caso que debe revisarse antes de actualizar: Pods con etiquetas SELinux distintas que comparten un mismo volumen en el mismo nodo pueden dejar de arrancar bajo determinadas configuraciones. Kubernetes permite conservar temporalmente el comportamiento anterior mediante `seLinuxChangePolicy: Recursive` para cargas que lo necesiten. KUBE-DNS ENTRA EN LA RECTA FINAL CoreDNS es el DNS por defecto de Kubernetes desde la versión 1.13. `kube-dns` ha quedado rezagado y no soporta capacidades modernas como EndpointSlices o servicios dual-stack de la misma forma. En Kubernetes 1.37, el proyecto formaliza su deprecación. La previsión anunciada es que después de Kubernetes 1.40 dejen de generarse nuevos paquetes de kube-dns. Si un clúster todavía utiliza kube-dns, RA considera que ya debería existir un plan de migración a CoreDNS. No conviene esperar a la versión en la que deje de empaquetarse. KUBE-PROXY IPVS TAMBIÉN INICIA SU RETIRADA El modo `ipvs` de kube-proxy queda deprecado. A partir de 1.37, los clústeres que usan `mode: ipvs` reciben una advertencia de deprecación al arrancar. El plan publicado por Kubernetes es: - alrededor de 1.40: desactivarlo por defecto; - alrededor de 1.43: retirar completamente el soporte, si se cumple la hoja de ruta prevista. Antes de actualizar conviene comprobar qué modo usa kube-proxy. Un comando útil es: kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config.conf}' | grep 'mode:' El objetivo no es cambiar a ciegas, sino identificar si existe una dependencia que necesitará migración. STATIC PODS: SE CIERRA UNA EXCEPCIÓN Los static Pods no se crean a través del API server y nunca estuvieron diseñados para leer directamente objetos API como Secrets o ConfigMaps. Una excepción histórica permitía hacerlo en ciertos casos. En Kubernetes 1.37 esa posibilidad queda prohibida de forma estricta y se elimina el feature gate que permitía el comportamiento anterior. Si una infraestructura utiliza static Pods que dependen de: - `secretRef`; - `configMapRef`; - referencias equivalentes a recursos del API; debe revisarse antes de actualizar. CGROUP V1: LA MIGRACIÓN YA NO DEBERÍA POSPONERSE El soporte para cgroup v1 continúa camino de desaparecer. Desde Kubernetes 1.35, `failCgroupV1` vale `true` por defecto. Eso significa que el kubelet no inicia en un nodo que siga usando cgroup v1, salvo que el administrador aplique explícitamente una excepción temporal: apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration failCgroupV1: false Kubernetes 1.37 todavía permite esa excepción. Pero el propio proyecto la considera una solución temporal. Además, capacidades modernas de gestión de recursos dependen de cgroup v2. Si una organización sigue usando cgroup v1, la pregunta ya no debería ser “¿podemos mantenerlo indefinidamente?”, sino “¿qué bloquea la migración a cgroup v2 y cuándo la terminamos?”. QUÉ SIGNIFICA PARA CARGAS DE IA La relevancia de Kubernetes 1.37 para IA no está en que Kubernetes “se convierta en una plataforma de IA”. El cambio concreto es que el scheduler entiende mejor grupos de Pods que necesitan avanzar juntos. Eso puede ser útil para: - entrenamiento distribuido; - jobs con múltiples workers; - cargas que consumen varias GPUs; - simulaciones HPC; - trabajos donde arrancar solo una fracción del grupo no aporta valor. La ventaja potencial es reducir recursos atrapados por trabajos incompletos. Pero el administrador debe habilitar y probar explícitamente estas funciones. No hay una mejora automática solo por instalar 1.37. QUÉ DEBERÍA REVISARSE ANTES DE ACTUALIZAR Para un clúster real, RA recomienda revisar al menos: 1. Qué versión de cgroup utilizan todos los nodos. 2. Si existe `failCgroupV1: false` como excepción temporal. 3. Si todavía se utiliza kube-dns. 4. Qué modo utiliza kube-proxy y si aparece `ipvs`. 5. Si existen static Pods que referencian Secrets o ConfigMaps. 6. Qué CSI drivers declaran soporte para SELinuxMount. 7. Si hay Pods con contextos SELinux diferentes compartiendo volúmenes. 8. Qué APIs Beta o Alpha consume software externo. 9. Compatibilidad de CNI, CSI, runtimes, operadores y herramientas de observabilidad. 10. Si se quiere probar gang scheduling, hacerlo primero en un entorno controlado con `GenericWorkload` habilitado. UNA ACTUALIZACIÓN DE KUBERNETES NO ES SOLO EL CONTROL PLANE El procedimiento oficial de actualización recuerda que también hay que comprobar: - etcd; - kube-apiserver; - controller manager; - scheduler; - cloud controller manager si existe; - kubelets de cada nodo; - kubectl; - extensiones de terceros. CNI, CSI, admission controllers, operadores, runtimes y otros componentes pueden tener su propia matriz de compatibilidad. Por tanto, “Kubernetes 1.37 soporta una función” no significa que todo el ecosistema instalado en un clúster concreto esté listo para ella. A QUIÉN PUEDE INTERESAR Si administras Kubernetes: revisa deprecaciones y compatibilidad antes de planificar la actualización. Si trabajas con IA/ML: gang scheduling puede mejorar el aprovechamiento de recursos en cargas distribuidas, pero requiere habilitación y pruebas. Si gestionas GPUs: interesa especialmente evitar que grupos incompletos retengan recursos costosos sin avanzar. Si trabajas en seguridad: revisa static Pods, SELinux y la retirada progresiva de mecanismos antiguos. Si mantienes distribuciones o plataformas gestionadas: hay que decidir cuándo exponer las funciones Beta y cómo migrar dependencias heredadas. Si eres usuario final de una aplicación: probablemente no notarás Kubernetes 1.37 directamente, pero puede afectar a la fiabilidad y eficiencia de la infraestructura que la ejecuta. QUÉ PUEDES HACER AHORA Antes de pasar un clúster a 1.37: 1. Lee las release notes completas. 2. Inventaría nodos y confirma cgroup v2. 3. Comprueba si kube-dns sigue presente. 4. Revisa el modo de kube-proxy. 5. Busca static Pods con referencias al API. 6. Valida CNI, CSI, runtime y operadores contra 1.37. 7. Prueba la actualización en staging o un clúster representativo. 8. Si utilizas IA/ML distribuida, crea una prueba separada para gang scheduling. 9. Mide utilización, tiempos de espera y comportamiento de preemption antes y después. 10. Documenta cualquier excepción temporal para que no se convierta en deuda permanente. RECURSOS Anuncio oficial de Kubernetes 1.37: https://kubernetes.io/blog/2026/08/26/kubernetes-v1-37-release/ Gang scheduling: https://kubernetes.io/docs/concepts/scheduling-eviction/gang-scheduling/ Scheduling Group: https://kubernetes.io/docs/concepts/workloads/pods/scheduling-group/ Actualización de un clúster: https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade/ Release notes: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.37.md QUÉ VIGILARÁ RADARABIERTO RA debe seguir: - evolución de gang scheduling después de Beta; - si `GenericWorkload` acaba activándose por defecto; - rendimiento real en cargas de IA/ML y HPC; - interoperabilidad con gestores de colas y controladores externos; - retirada definitiva de cgroup v1; - calendario real de desaparición de kube-dns; - evolución de la deprecación de kube-proxy ipvs; - incidencias derivadas de SELinuxMount; - transición de `metrics.k8s.io` a v1; - nuevas versiones 1.37.x y correcciones de seguridad; - compatibilidad de runtimes, CNI, CSI y operadores; - regresiones detectadas en producción; - diferencias entre mejoras anunciadas y efectos medidos en clústeres reales. Esta señal debe mantenerse como historia viva. Kubernetes 1.37 no es solo una colección de 67 mejoras: obliga a separar funciones nuevas que todavía requieren activación de dependencias antiguas que ya tienen una fecha de caducidad cada vez más cercana.
Por qué puede importarte
La versión introduce capacidades de scheduling por grupos útiles para trabajos distribuidos y, al mismo tiempo, convierte varias dependencias heredadas en tareas de migración cada vez menos aplazables. Para operadores, el valor no está solo en instalar la nueva versión, sino en identificar qué nodos, DNS, networking, SELinux, static Pods y extensiones de terceros requieren cambios antes del upgrade.
Cómo ha evolucionado
Estado actual: actual. Añadiremos los cambios posteriores sin borrar este registro.
Qué todavía no sabemos
Gang scheduling es Beta pero permanece desactivado por defecto y requiere el feature gate GenericWorkload, por lo que su impacto depende de que cada operador lo habilite y valide. Los calendarios de retirada de kube-proxy ipvs y otros componentes son hojas de ruta anunciadas y pueden ajustarse. La compatibilidad final depende también de runtimes, CNI, CSI, operadores y proveedores gestionados externos al núcleo de Kubernetes.
Seguir el contexto
La señal conserva procedencia y relaciones internas para que puedas comprobar el origen y explorar cambios relacionados.
Esta ficha verificable es igual para todos. Puedes indicar si te afecta, si no se entiende, si quieres seguirla o si no te interesa. Para que seguir u ocultar cambie solo tu selección, crea Mi Radar.