La versión en resumen
El proyecto Kubernetes publicó la versión v1.37.0 el 26 de agosto de 2026, con lo que completó un ciclo de 15 semanas iniciado el 18 de mayo. La versión contiene 86 mejoras: 16 pasan a estable, 28 a beta y 42 entran en alfa. Tres cambios exigen una acción explícita previa a la actualización en la mayoría de los clústeres de producción. Los equipos que usan distribuciones gestionadas de AWS EKS, Google GKE o Azure AKS absorberán algunos de ellos de forma automática, pero los clústeres autogestionados y las flotas bare-metal necesitan una verificación manual de las tres áreas antes de promover nodos.
Para los equipos que ejecutan cargas de trabajo de Cloud y DevOps en Kubernetes, v1.37 es una versión sólida, con avances significativos en la planificación de aceleradores y en la gestión de recursos. El riesgo de rotura se concentra en tres áreas, todas ellas anunciadas en versiones anteriores, pero «anunciado» no equivale a «corregido de antemano», y la mayoría de los equipos de plataforma tendrá al menos un nodo o una carga de trabajo afectados por alguna de ellas.
Cambio incompatible 1: el modo IPVS queda formalmente obsoleto
El modo de proxy IPVS de kube-proxy ha sido una opción compatible desde Kubernetes 1.8. En v1.37, el proyecto lo declara formalmente obsoleto mediante KEP-5495. Si kube-proxy arranca en modo IPVS, ahora emitirá una advertencia de obsolescencia al iniciar. El clúster sigue funcionando, pero la advertencia no es cosmética: marca el comienzo de un calendario de retirada.
El calendario previsto es: v1.40, IPVS desactivado por defecto tras una feature gate; v1.43, IPVS eliminado por completo. Dado que Kubernetes publica cuatro versiones al año, v1.43 queda a unos tres años vista. Es margen suficiente para migrar, pero no para aplazar la conversación de planificación.
El motivo de la obsolescencia es arquitectónico: la API de IPVS del kernel, por sí sola, no puede implementar por completo los Services de Kubernetes. La implementación actual superpone reglas de iptables sobre IPVS, con lo que combina la complejidad operativa de ambos sin la coherencia de ninguno. Los destinos de migración recomendados son el modo iptables (el predeterminado actual) o el más reciente modo nftables, que pasó a GA en v1.35 y gestiona los conjuntos de reglas de clústeres grandes con más eficiencia que iptables.
Para comprobar qué modo ejecuta su clúster: kubectl get cm -n kube-system kube-proxy -o yaml | grep mode. Si la salida muestra mode: ipvs, programe la migración antes de v1.40.
Cambio incompatible 2: los nodos con cgroup v1 no arrancan kubelet por defecto
Este cambio viene gestándose desde v1.35, pero v1.37 amplía la superficie de aplicación. Desde v1.35, failCgroupV1 es true por defecto en KubeletConfiguration. Un kubelet en un nodo con cgroup v1 no arrancará salvo que el operador establezca explícitamente failCgroupV1: false como anulación temporal.
En v1.37, los indicadores de línea de comandos heredados --cgroup-driver y --cgroup-root se eliminan por completo. Cualquier script de arranque de nodo, unidad de systemd o herramienta que pase estos indicadores directamente a kubelet fallará al analizarlos. El sustituto es la feature gate KubeletCgroupDriverFromCRI (estable desde v1.36), que indica a kubelet que detecte el controlador de cgroup a partir del runtime de contenedores en lugar de aceptarlo como indicador.
Antes de actualizar, ejecute stat -fc %T /sys/fs/cgroup en cada nodo. Si la salida es cgroup2fs, el nodo usa cgroup v2 y no se ve afectado. Si la salida es tmpfs, el nodo sigue en cgroup v1 y requerirá una actualización del kernel o la vía de escape temporal failCgroupV1: false en KubeletConfiguration. La mayoría de las distribuciones Linux modernas usan cgroup v2 por defecto desde sus versiones de 2024 y posteriores; los nodos con más probabilidad de verse afectados son los hosts bare-metal o locales de larga duración que no se han reaprovisionado recientemente.
Cambio incompatible 3: los Pods estáticos ya no pueden referenciar Secrets ni ConfigMaps
Los Pods estáticos, es decir, manifiestos colocados directamente en el sistema de archivos de un nodo y gestionados por kubelet en lugar de por el servidor de la API, ya no pueden usar configMapRef ni secretRef en los campos env o envFrom para incorporar valores de Secrets y ConfigMaps. La feature gate PreventStaticPodAPIReferences, que antes controlaba este comportamiento, se ha eliminado, de modo que la restricción es permanente e incondicional.
El motivo es la coherencia y la seguridad: los Pods estáticos se ejecutan antes de que el servidor de la API sea necesariamente accesible (a menudo se usan para arrancar componentes del plano de control), así que permitirles referenciar objetos de la API crea una dependencia temporal que kubelet no puede resolver de forma fiable. La restricción se aplicó como una gate alfa en v1.34, pasó por beta y ahora queda bloqueada.
Este es el más sorprendente de los tres desde el punto de vista operativo, porque los manifiestos de Pods estáticos suelen mantenerse fuera del chart principal de Helm o del repositorio GitOps y son fáciles de pasar por alto en una auditoría previa a la actualización. Ejecute grep -r "configMapRef\|secretRef" /etc/kubernetes/manifests/ en cada nodo para identificar los manifiestos afectados. En su lugar, los Secrets deben montarse como volúmenes o pasarse a través del entorno del nodo.
Qué ha pasado a estable
Más allá de los cambios incompatibles, v1.37 aporta mejoras significativas para las cargas de trabajo de IA/ML y de propósito general:
- Taints y tolerations de dispositivos DRA (GA): Dynamic Resource Allocation ahora puede marcar un dispositivo como «tainted» (una GPU degradada, una NIC que falla) y los Pods pueden expresar tolerations para esos taints, igual que en el conocido modelo de taints y tolerations de los nodos. Esto cierra una brecha importante en los clústeres con muchas GPU en los que el estado del hardware es desigual.
- Solicitudes y límites de recursos a nivel de Pod (estable): Definir CPU y memoria a nivel de Pod en lugar de a nivel de contenedor es ahora una API estable, lo que simplifica la contabilidad de recursos en las cargas de trabajo con varios contenedores.
- Metrics API (GA): La API
metrics.k8s.io, que respaldakubectl topy el HPA, pasa a estable con respuestas de error del servidor mejoradas. - Particionado de GPU (KEP-4815, camino de alfa a beta): La capacidad de dividir una GPU física en varias porciones lógicas asignables mediante DRA sigue madurando. Todavía no es GA en v1.37, pero se espera que llegue a beta en v1.38.
Qué significa para los equipos de software de EE. UU. y la UE
Para los equipos que ejecutan cargas de trabajo en Kubernetes autogestionado, el balance operativo de v1.37 es parecido al de v1.35 y v1.36: la plataforma base tiene cada vez más criterio sobre qué configuraciones son aceptables, y el coste de ignorar las advertencias de obsolescencia es ahora un ciclo de versión más corto que antes. Tres observaciones:
La migración a cgroup v2 ya no es opcional en la planificación. Kubernetes está cerrando la puerta a cgroup v1 de forma progresiva y deliberada. Si la hoja de ruta de su infraestructura aún trata cgroup v2 como una «consideración futura», v1.37 debería llevar esa conversación al próximo sprint. Las distribuciones gestionadas en la nube han resuelto en gran medida este asunto para sus clientes; los clústeres autogestionados y locales cargan con él por su cuenta.
La higiene de los Pods estáticos importa más ahora. La restricción sobre los Pods estáticos es la fuente más probable de fallos silenciosos el día de la actualización, porque sus manifiestos suelen vivir fuera del flujo de GitOps que rige todo lo demás. Una auditoría previa de los manifiestos no es opcional: lleva diez minutos y evita que un kubelet no arranque en un nodo del plano de control.
La vía de graduación de DRA indica hacia dónde va la planificación de GPU en Kubernetes. Que el modelo de taints y tolerations para aceleradores pase a GA en v1.37, junto con el particionado de GPU encaminado hacia beta, significa que Kubernetes se está convirtiendo en el planificador de referencia para la computación heterogénea, y no solo para las cargas de trabajo de propósito general. Para los equipos que construyen pipelines de IA/ML sobre Kubernetes, conviene seguir directamente la hoja de ruta de DRA en lugar de confiar en los valores predeterminados de las distribuciones gestionadas.
Lista de verificación previa a la actualización a v1.37
Ejecute estas comprobaciones antes de promover cualquier nodo a v1.37:
- Compruebe el modo de proxy.
kubectl get cm -n kube-system kube-proxy -o yaml | grep mode. Si aparecemode: ipvs, planifique la migración a iptables o nftables; la eliminación de IPVS está a tres versiones de distancia (v1.43). - Verifique la versión de cgroup en cada nodo.
stat -fc %T /sys/fs/cgroup. Salidatmpfs= cgroup v1 = kubelet no arrancará sin la anulaciónfailCgroupV1: falseen KubeletConfiguration. - Elimine los indicadores heredados de kubelet del arranque de los nodos. Busque
--cgroup-drivero--cgroup-rooten las unidades de systemd y en los scripts de cloud-init. Estos indicadores se eliminan en v1.37 y harán que kubelet falle al analizarlos. - Audite los manifiestos de Pods estáticos.
grep -r "configMapRef\|secretRef" /etc/kubernetes/manifests/en cada nodo. Mueva las referencias a Secrets a montajes de volumen o a variables de entorno a nivel de nodo. - Confirme la versión de containerd.
containerd --version. Debe ser 2.0.0 o superior (1.x no es compatible desde v1.36). - Revise el uso de DRA ResourceClaim. Si usa funciones alfa de DRA de v1.36, consulte el CHANGELOG por si hay cambios en las API alfa que exijan actualizar los manifiestos.
- Pruebe primero en un clúster que no sea de producción. Ejecute la lista, actualice el clúster y verifique que
kubectl top nodesykubectl top podsdevuelven valores correctos (el comportamiento de la Metrics API en GA puede diferir del de la beta anterior en casos límite).
Preguntas frecuentes
¿Se elimina el modo IPVS en Kubernetes 1.37?
No: IPVS queda obsoleto en v1.37, pero no se elimina. Cuando kube-proxy arranca en modo IPVS, verá una advertencia de obsolescencia en los registros, pero el clúster sigue funcionando. El calendario previsto es: desactivado por defecto tras una feature gate en v1.40 y eliminación completa en v1.43. Los equipos tienen tiempo para migrar a los modos de proxy nftables o iptables, pero el margen es limitado.
¿Cómo ejecuto Kubernetes 1.37 en un nodo con cgroup v1?
Desde v1.35, kubelet establece failCgroupV1 en true por defecto y se niega a arrancar en nodos con cgroup v1. En v1.37 también se elimina el indicador heredado --cgroup-driver; kubelet debe usar en su lugar KubeletCgroupDriverFromCRI. Para mantener en marcha un nodo con cgroup v1 durante un periodo de transición, establezca failCgroupV1: false en KubeletConfiguration. Es una vía de escape temporal; cgroup v2 es el único destino compatible.
¿Qué cambio de los Pods estáticos rompe Kubernetes 1.37?
Los Pods estáticos ya no pueden usar configMapRef ni secretRef en los campos envFrom o env para referenciar ConfigMaps y Secrets. La feature gate PreventStaticPodAPIReferences se ha eliminado, con lo que la aplicación de la restricción es permanente. Los Pods estáticos con esas referencias no arrancarán tras la actualización. Audite los manifiestos de Pods estáticos en todos los nodos antes de ejecutar la actualización.
¿Kubernetes 1.37 sigue siendo compatible con containerd 1.x?
No. Kubernetes dejó de ser compatible con containerd 1.x en v1.36; v1.37 sigue exigiendo containerd 2.0 o superior. Si sus nodos aún usan containerd 1.x, actualice el runtime antes de actualizar Kubernetes. La mayoría de las distribuciones gestionadas (EKS, GKE, AKS) ya usan containerd 2.x por defecto, pero los clústeres autogestionados deben verificarlo de forma explícita.
¿Qué nuevas funciones estables incluye Kubernetes 1.37?
Dieciséis mejoras pasan a estable en v1.37. Destacan: los taints y tolerations de dispositivos DRA, que alcanzan GA para una planificación detallada de GPU y aceleradores; las solicitudes y límites de recursos a nivel de Pod como API estable; y la Metrics API, que pasa a GA. El particionado de GPU mediante KEP-4815 sigue madurando de alfa hacia beta y permite dividir una GPU física en varias porciones asignables.
Fuentes
Kubernetes.io — Kubernetes v1.37 Sneak Peek (en inglés) (blog oficial, 31 de julio de 2026)
GitHub — kubernetes/sig-release release-1.37 schedule (en inglés) (fecha de GA confirmada: 26 de agosto de 2026)
GitHub — Kubernetes CHANGELOG-1.37.md (en inglés) (changelog oficial)