Kubernetes 1.37: alpha nuevas, DRA madura y el salto a nftables

El equipo de release de Kubernetes publicó el sneak peek de la versión 1.37 y, como siempre, es el mejor mapa para saber qué revisar antes de que llegue lo estable. Esta vez el foco está en tres frentes que tocan directo a quien corre clusters en producción: una tanda grande de features alpha, la maduración de Dynamic Resource Allocation (DRA) para hardware como GPUs, y el avance sostenido de nftables como backend de kube-proxy en reemplazo de iptables e IPVS.

Kubernetes 1.37 es la próxima versión menor del orquestador de contenedores de la CNCF, con release previsto para el 26 de agosto de 2026 según el cronograma oficial de SIG Release. Su sneak peek adelanta decenas de mejoras nuevas en estado alpha, la graduación de piezas de DRA para asignar dispositivos como GPUs, y una serie de cambios en kube-proxy que empujan a nftables como futuro backend por defecto. Es la foto previa al freeze, no la lista final.

¿Cuándo sale Kubernetes 1.37 y qué es un sneak peek?

Kubernetes 1.37 está agendado para el 26 de agosto de 2026. Un "sneak peek" es el adelanto que el equipo de comunicación de release publica semanas antes: no es el changelog definitivo, sino una vista de lo que probablemente entre, con foco en deprecaciones, cambios que rompen y las features que estrenan estado alpha. Sirve para probar en staging y planificar upgrades sin sorpresas.

Los conteos que circulan sobre cuántas mejoras nuevas entran en alpha todavía se mueven hasta el enhancements freeze: el análisis de Palark habla de unas 22 nuevas en alpha, mientras que Cloudsmith cuenta 34 "net-new to alpha" en el tracker. La diferencia es normal a esta altura del ciclo; lo importante es la dirección, no el número exacto. Como referencia, la 1.37 llega poco después de la 1.36 y en la misma línea de limpieza que arrancó en la 1.35 (la que sacó cgroup v1, IPVS legacy y containerd 1.x).

¿Qué está pasando con DRA en Kubernetes 1.37?

DRA (Dynamic Resource Allocation) es el mecanismo moderno de Kubernetes para pedir y asignar dispositivos especializados —GPUs, aceleradores, interfaces de red— con mucho más detalle que el viejo modelo de device plugins. En 1.37 madura en dos sentidos: una pieza clave se gradúa a estable y llega una camada nueva de features alpha para casos reales de hardware heterogéneo.

• KEP-4817 se gradúa a estable. Estandariza cómo un driver de DRA describe la interfaz de red que quedó adjunta a un ResourceClaim, de modo que la información viaje de forma consistente entre distintos proveedores de hardware.
• Co-ubicación por NUMA (KEP-6072). Introduce un atributo estándar resource.kubernetes.io/numaNode para que el scheduler pueda ubicar recursos relacionados en el mismo nodo NUMA y evitar penalizaciones de latencia.
• Grupos de compatibilidad de dispositivos (KEP-6963). Suma compatibilityGroups al ResourceSlice para que el planificador no agende juntas configuraciones de hardware incompatibles, como modos de virtualización de GPU en conflicto.
• Atributos derivados (KEP-6080). Permite usar expresiones CEL para extraer y normalizar metadata específica de cada vendor, sin tener que tocar el código del driver.
• Preparación de nodo opcional (KEP-5945). Agrega un campo SkipNodeOperations para recursos virtuales o de nube, evitando desplegar DaemonSets "dummy" en todos los nodos.

Según el análisis de Cloudsmith sobre la 1.37, con "una convención de nombres única y consistente" y funciones auxiliares en la librería deviceattribute, los usuarios "deberían poder lograr co-ubicación entre drivers y matcheo avanzado de atributos" sin fricción. En criollo: DRA deja de ser un experimento de nicho y empieza a ser la forma seria de correr cargas con GPU en Kubernetes.

¿Qué cambia con nftables y kube-proxy?

kube-proxy es el componente que programa las reglas de red para que los Service funcionen. En 1.37 nftables todavía no es el backend por defecto, pero la versión prepara el terreno para el cambio. El modo nftables existe como reemplazo de iptables desde hace varias releases (documentado oficialmente en febrero de 2025) y ahora entra en la fase de empujar a los usuarios hacia él.

• Avisos de modo explícito (KEP-5343). Desde 1.37, si no definís el modo con --proxy-mode o el campo mode, kube-proxy loguea advertencias y genera events antes de caer a iptables. Es la antesala del switch de default.
• El default a nftables llega después. Según Cloudsmith, el cambio oficial de backend por defecto está proyectado recién para Kubernetes 1.40; la 1.37 se enfoca en preparar, no en romper.
• NodePort en localhost con nftables (KEP-6032). Suma un proxy TCP opcional en espacio de usuario para poder llegar a servicios NodePort vía 127.0.0.1 o ::1 con el backend nftables (por ejemplo, un registry local). Es alpha y requiere habilitar el feature gate.

¿Qué pasa con IPVS y iptables?

IPVS entra en deprecación en 1.37 y iptables sigue soportado por ahora. El sneak peek oficial confirma la hoja de ruta para el modo IPVS de kube-proxy, que quedó sin mantenedores activos.

• 1.37: el modo IPVS muestra una advertencia de deprecación al iniciar (KEP-5495).
• 1.40: IPVS queda deshabilitado por defecto, seleccionable solo vía feature gate.
• 1.43: se remueve el soporte por completo.

Si no estás seguro de qué modo corre tu cluster, revisalo con:

kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:'

¿Qué implica esto para tus proyectos en producción?

Para la mayoría de los clusters, 1.37 es una versión de "leer las advertencias ahora para no sufrir después". Hay tres deudas técnicas que conviene saldar antes de que se vuelvan bloqueantes:

• Fijá el modo de kube-proxy de forma explícita. Aunque hoy uses iptables, definir --proxy-mode te saca del camino de los cambios de default y te deja migrar a nftables cuando vos decidas, no cuando te sorprenda un upgrade.
• Salí de IPVS si todavía lo usás. Con la remoción confirmada para 1.43, cada release que pase sin migrar es deuda que se acumula. nftables es el destino recomendado.
• Terminá de pasar a cgroup v2. No es nuevo de 1.37, pero sigue vigente: desde 1.35 el kubelet falla al iniciar en nodos con cgroup v1 (failCgroupV1 en true), y features como el resize de pods in-place requieren cgroup v2.

¿Qué podés hacer hoy con esto?

Probá los cambios en un cluster de staging antes del 26 de agosto. Kubernetes publica alphas y release candidates que podés levantar sin esperar a lo estable.

• Levantá un cluster de prueba con una alpha reciente y activá los feature gates que te interesen (nftables NodePort en localhost, o los de DRA si trabajás con GPUs) para medir impacto real.
• Auditá tus manifiestos. Si tenés Pods estáticos que referencian Secrets o ConfigMaps por secretRef/configMapRef, esa referencia deja de funcionar en 1.37 (KEP relacionado: kubernetes/kubernetes#140226). Revisalos antes de actualizar.
• Seguí el tracker oficial. El sneak peek de v1.37 lista deprecaciones y cambios que rompen; es lectura obligada antes de cualquier upgrade en serio.

Preguntas frecuentes

¿Cuándo se libera Kubernetes 1.37?

El 26 de agosto de 2026, según el cronograma oficial de SIG Release. Las versiones alpha y release candidates están disponibles antes para pruebas.

¿nftables ya es el backend por defecto de kube-proxy en 1.37?

No. En 1.37 solo se agregan advertencias cuando el modo no está definido explícitamente; el cambio de default a nftables está proyectado recién para la versión 1.40.

¿Cuándo se elimina el modo IPVS de kube-proxy?

El soporte se remueve por completo en Kubernetes 1.43. En 1.37 aparece la advertencia de deprecación (KEP-5495) y en 1.40 queda deshabilitado por defecto.

¿Qué es DRA y por qué importa en 1.37?

Dynamic Resource Allocation es el modelo moderno para pedir y asignar dispositivos especializados como GPUs. En 1.37 gradúa a estable la descripción estandarizada de interfaces de red (KEP-4817) y suma varias features alpha para co-ubicación por NUMA y compatibilidad de hardware.

¿Tengo que hacer algo si mi cluster usa cgroup v1?

Sí: migrar a cgroup v2. Desde la 1.35 el kubelet no inicia en nodos con cgroup v1 salvo que uses el override temporal failCgroupV1: false, que es una solución de corto plazo.

Si venís siguiendo el ciclo, esta nota se complementa con "Kubernetes 1.35 deja afuera cgroup v1, ipvs y containerd 1.x" y "Kubernetes 1.34: tracing en el kubelet y VolumeAttributesClass GA", ya publicadas en este blog.

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