La respuesta corta
Kubernetes v1.37 «Garhwal» (26 de agosto de 2026) contiene tres cambios incompatibles que exigen una revisión inmediata de la infraestructura: (1) los nodos que usan cgroup v1 se niegan a arrancar kubelet, un bloqueo duro y no una advertencia; (2) kube-dns se retira con fecha límite de migración en v1.40; (3) IPVS en kube-proxy entra en su cuenta atrás de obsolescencia con vistas a su eliminación en v1.43. En el lado positivo, la API metrics.k8s.io, que alimenta HorizontalPodAutoscaler y kubectl top, pasa de Beta a Estable (v1) tras nueve años de uso en producción. Los equipos con Kubernetes gestionado en la nube e imágenes de nodo actuales apenas se ven afectados. Los clústeres autogestionados con imágenes de nodo antiguas deberían tratar esta actualización como un proyecto de modernización de la infraestructura, no como un cambio de versión rutinario.
67 mejoras: qué se ha incluido
El ciclo de la versión v1.37 duró 15 semanas, del 18 de mayo al 26 de agosto de 2026, con contribuciones de 1,754 personas de 212 empresas. El recuento final: 67 mejoras, de las cuales 16 pasaron a Estable, 23 a Beta, 27 entraron en Alfa y 1 pasó a obsolescencia o eliminación. La versión se llama «Garhwal» por una región del Himalaya de Uttarakhand, en la India, y su logotipo muestra cumbres nevadas y un río sinuoso, una imagen elegida para reflejar cómo «cada capa, ruta y contribución está conectada» entre los muchos SIG del proyecto.
Entre las graduaciones a estable además de la Metrics API, las más relevantes en la práctica son la salida KYAML de kubectl, las definiciones de recursos a nivel de Pod y los taints y tolerations a nivel de dispositivo para Dynamic Resource Allocation (DRA). Este último punto es especialmente importante para los equipos que ejecutan cargas de trabajo con GPU o aceleradores personalizados: DRA se está convirtiendo en el mecanismo fundamental para la planificación de hardware heterogéneo en los pipelines de IA/ML, y conviene revisar ya las nuevas incorporaciones en Alfa de v1.37, antes de su futura graduación a estable. Para los equipos que ejecutan clústeres de Kubernetes en producción, sin embargo, la decisión de actualizar suele depender de los cambios incompatibles y no de las funciones nuevas, y esta versión trae tres.
Eliminación de cgroup v1: el bloqueo duro
Desde Kubernetes v1.35, los nodos que usan cgroup v1 generan advertencias al arrancar. En v1.37 el comportamiento se endurece: si kubelet detecta cgroup v1 al iniciar, el nodo no se inicializa. No hay degradación gradual. Actualizar un clúster afectado dejará esos nodos inutilizables de inmediato.
Para comprobar un nodo, ejecute stat -fc %T /sys/fs/cgroup/. La salida tmpfs indica cgroup v1; cgroup2fs indica cgroup v2 y que el nodo está a salvo. Entre las distribuciones que usan cgroup v1 por defecto están CentOS 7, RHEL 7 (kernel EL7 3.10) y Ubuntu 18.04. La mayoría de las imágenes de nodo gestionadas en la nube de EKS, GKE y AKS migraron a cgroup v2 entre 2022 y 2023, por lo que los equipos con grupos de nodos actuales gestionados por el proveedor de nube no suelen verse afectados.
Un campo failCgroupV1: false en KubeletConfiguration puede suprimir el bloqueo duro. El proyecto Kubernetes lo califica de peligroso: deja al nodo sin Memory QoS, sin las métricas de Pressure Stall Information (PSI) y sin ciertas configuraciones de swap que requieren cgroup v2, y se eliminará en una versión futura. Es un seguro de migración, no una configuración permanente.
El camino práctico es actualizar la imagen del nodo antes de tocar la versión de Kubernetes. Los equipos con infraestructura local deberían pasar a RHEL 8+, Rocky Linux, AlmaLinux 8+ o Ubuntu 20.04+. Los equipos en la nube con grupos de nodos autogestionados deberían actualizar la AMI o la imagen de VM. El esfuerzo de ingeniería de cloud y DevOps es real, pero está bien acotado: cgroup v2 lleva años siendo estable y la ruta de migración está bien documentada.
Calendario de obsolescencia de kube-dns e IPVS
kube-dns se retira en v1.37. CoreDNS, que es el valor predeterminado desde Kubernetes 1.13 (2018), lo sustituye por completo. Los clústeres que aún ejecutan kube-dns tienen hasta Kubernetes 1.40 para migrar; después, el DNS del clúster dejará de funcionar. La migración a CoreDNS implica sustituir el DaemonSet de kube-dns por un Deployment de CoreDNS y actualizar los ConfigMaps para usar la sintaxis de Corefile. La mayoría de los servicios gestionados de Kubernetes en la nube automatizaron esta migración hace años. Si su clúster muestra pods de kube-dns en kube-system, programe la migración para este trimestre.
IPVS en kube-proxy entra en su cuenta atrás formal de obsolescencia en v1.37, con la eliminación prevista para v1.43. El sustituto es nftables, que ofrece mejor rendimiento, expresiones de reglas más ricas y mantenimiento upstream activo. Si su equipo de redes tiene monitorización, alertas o herramientas propias construidas sobre los contadores de IPVS, planifique la migración a nftables antes del límite de v1.43: aproximadamente cuatro ciclos de versión, o entre 12 y 18 meses con el ritmo de publicación actual.
La Metrics API pasa a estable
La API metrics.k8s.io, que proporciona el uso de CPU y memoria de pods y nodos, pasa de Beta a Estable (v1) en v1.37. El Release Lead Dipesh Rawat señaló la ironía sin rodeos: «A pesar de la etiqueta Beta, la API metrics.k8s.io se ha utilizado ampliamente en producción durante años». Esta API es la que hace funcionar kubectl top nodes, kubectl top pods, HorizontalPodAutoscaler (HPA) y VerticalPodAutoscaler (VPA).
La consecuencia práctica de la graduación a estable es que la superficie de la API metrics.k8s.io v1 queda ahora sujeta a la garantía de compatibilidad de Kubernetes: no cambiará de forma incompatible en un futuro previsible. Si su equipo ha mantenido discretamente en sus runbooks una nota que advierte de que HPA depende de una API Beta, puede eliminarla. La superficie de autoescalado de la que depende su equipo de fiabilidad forma ahora parte del contrato de compatibilidad de Kubernetes.
Qué significa para los equipos de software de EE. UU. y la UE
La eliminación de cgroup v1 es el punto operativamente más urgente de esta versión. A diferencia de la mayoría de los cambios incompatibles de Kubernetes, que afectan a versiones de API o esquemas de manifiestos, este apunta a la infraestructura a nivel de nodo. Eso exige coordinar al equipo de plataforma con quien gestione las imágenes de nodo: el equipo de infraestructura cloud, operaciones locales o quien aprovisione las imágenes de VM. Los responsables de ingeniería deberían ejecutar esta semana la comprobación stat -fc %T /sys/fs/cgroup/ en todos los nodos del clúster y clasificar los resultados antes de la próxima ventana de actualización.
Los clústeres locales e híbridos soportan el mayor riesgo. Las empresas que ejecutan Kubernetes en distribuciones Linux empresariales antiguas, en particular infraestructura de la era de RHEL 7, pueden afrontar una doble migración: actualizar la distribución de Linux a la vez que la versión de Kubernetes. En sectores regulados (FinTech, HealthTech, seguros, sector público), las actualizaciones de versión mayor del sistema operativo suelen requerir la aprobación del equipo de seguridad, el visto bueno del análisis de vulnerabilidades y, en ocasiones, la aprobación de un comité de gestión de cambios. Incluya ese plazo en su planificación ya, y no en el momento de la ventana de actualización.
Los plazos de kube-dns e IPVS son más flexibles, pero no indefinidos. v1.40 para kube-dns y v1.43 para IPVS dan varios ciclos de versión de margen, pero estas tareas deberían entrar en su backlog en este ciclo de planificación y no a última hora. El ritmo de publicación de Kubernetes se ha acelerado; la distancia entre un margen cómodo y una fecha límite inapelable se cierra más rápido que antes.
La graduación a estable de metrics.k8s.io beneficia específicamente a los equipos de FinTech y HealthTech. Las organizaciones reguladas suelen documentar las dependencias de API y sus garantías de estabilidad para los auditores de cumplimiento. La graduación de la Metrics API a estable simplifica esa documentación: el mecanismo de autoescalado del que depende su equipo de fiabilidad está ahora cubierto por el contrato de compatibilidad de Kubernetes, y no por una función Beta de mejor esfuerzo.
¿Planea una actualización de Kubernetes o una migración de nodos a cgroup v2?
Nuestros ingenieros definen el alcance y ejecutan actualizaciones de clústeres de Kubernetes, migraciones de nodos a cgroup v2 y transiciones a CoreDNS para equipos de producto de EE. UU. y la UE, incluidos sectores regulados en los que las actualizaciones del sistema operativo requieren la aprobación de cumplimiento. Identificamos los cambios incompatibles que afectan a la configuración concreta de su clúster antes de que toque un solo nodo.
Hablar con un ingenieroQué deben hacer ahora los responsables de ingeniería
| Acción | Plazo | Notas |
|---|---|---|
Ejecutar stat -fc %T /sys/fs/cgroup/ en todos los nodos del clúster | Esta semana | Salida tmpfs = cgroup v1; kubelet fallará en ese nodo al actualizar. Audite antes de cualquier intento de actualización a v1.37. |
| Actualizar las imágenes de los nodos con cgroup v1 antes de actualizar Kubernetes | Antes de la próxima ventana de actualización | Apunte a RHEL 8+, Rocky Linux 8+, AlmaLinux 8+, Ubuntu 20.04+ o la AMI actual del proveedor de nube. cgroup v2 debe estar activo en el sistema operativo antes de actualizar kubelet. |
| Verificar DNS: confirmar que se ejecuta CoreDNS, no kube-dns | Este sprint | Ejecute kubectl get pods -n kube-system | grep dns. kube-dns debe migrarse antes de v1.40 o el DNS del clúster dejará de funcionar. |
| Auditar la configuración de kube-proxy en busca del modo IPVS | Este sprint | Compruebe kubectl get configmap kube-proxy -n kube-system -o yaml en busca de mode: ipvs. Si está establecido, planifique la migración a nftables antes de v1.43. |
| Revisar las funciones Alfa de DRA si se ejecutan cargas de trabajo con GPU o aceleradores | Este ciclo de planificación | Los taints y tolerations a nivel de dispositivo alcanzaron la versión Estable. Evalúe las incorporaciones Alfa de DRA para reducir la complejidad de la planificación personalizada en los pipelines de IA/ML. |
| Actualizar los runbooks de HPA para reflejar el estado estable de la Metrics API | Próximo ciclo de planificación | Elimine las salvedades relacionadas con Beta. La API metrics.k8s.io v1 queda cubierta ahora por la garantía de compatibilidad de Kubernetes. |
Fuentes: Kubernetes v1.37: Garhwal — Official release blog (en inglés) (kubernetes.io, 26 de agosto de 2026); Kubernetes cleans house, bins legacy kube-dns, IPVS, and cgroup v1 (en inglés) (The Register, 26 de agosto de 2026).
Preguntas frecuentes
¿Qué es cgroup v1 y por qué lo elimina Kubernetes 1.37?
cgroup v1 es el mecanismo original de grupos de control de Linux que Kubernetes usa para agrupar y limitar los recursos de CPU, memoria y E/S de los contenedores. Desde v1.35, Kubernetes emite advertencias de arranque para los nodos que aún usan cgroup v1. En v1.37, el comportamiento pasa a ser un bloqueo duro: si kubelet detecta cgroup v1 al iniciar, el nodo no se inicializará. cgroup v2, disponible desde el kernel de Linux 4.5 y predeterminado en la mayoría de las distribuciones modernas desde 2021, ofrece una jerarquía unificada, mejor QoS de memoria, métricas de Pressure Stall Information (PSI) y una gestión de swap más eficiente. El proyecto Kubernetes concluyó que mantener la compatibilidad dual ya no estaba justificado.
¿Cómo compruebo si mis nodos usan cgroup v1?
Ejecute stat -fc %T /sys/fs/cgroup/ en cada nodo. La salida tmpfs indica cgroup v1; cgroup2fs indica cgroup v2 y que el nodo es seguro para actualizar. En los nodos con v1.35 y v1.36, la detección de cgroup v1 también genera una advertencia en el registro de kubelet. Entre las distribuciones que usan cgroup v1 por defecto están CentOS 7, RHEL 7 (kernel EL7 3.10) y Ubuntu 18.04. La mayoría de las imágenes de nodo gestionadas en la nube de EKS, GKE y AKS pasaron a cgroup v2 entre 2022 y 2023.
¿Qué es la solución alternativa failCgroupV1 y debería usarla?
KubeletConfiguration incluye un campo failCgroupV1 que puede establecerse en false para suprimir el bloqueo duro de arranque. El proyecto Kubernetes lo califica expresamente de peligroso: deja al nodo sin las funciones de Memory QoS, sin las métricas de PSI y sin las configuraciones de swap que requieren cgroup v2. El campo se eliminará en una versión futura. Úselo solo como seguro de migración a corto plazo mientras prepara la actualización de la imagen del nodo, no como configuración permanente.
¿Qué ocurre con kube-dns e IPVS en Kubernetes 1.37?
kube-dns se retira en v1.37 en favor de CoreDNS, que es la solución de DNS predeterminada desde Kubernetes 1.13 (2018). Los clústeres que aún usan kube-dns deben migrar antes de Kubernetes 1.40 o el DNS del clúster dejará de funcionar. Por separado, la compatibilidad con IPVS en kube-proxy queda obsoleta en v1.37 y se eliminará en v1.43, sustituida por nftables. Si el ConfigMap de kube-proxy muestra mode: ipvs, planifique la migración a nftables antes del límite de v1.43.
¿Qué significa para HPA la graduación a estable de metrics.k8s.io?
La API metrics.k8s.io, que respalda kubectl top, HorizontalPodAutoscaler (HPA) y VerticalPodAutoscaler (VPA), pasa de Beta a Estable (v1) en Kubernetes 1.37 tras nueve años de uso en producción en Beta. La graduación a estable significa que la superficie de la API queda sujeta a la garantía de compatibilidad de Kubernetes y no cambiará de forma incompatible. Para los equipos que dependen de HPA para el autoescalado, esto formaliza una base que ya era estable de facto en producción.