Introducción
Los equipos que gestionan clusters con GPUs, NICs de alta velocidad o aceleradores heterogéneos llevan tres releases esperando esto. Hasta Kubernetes 1.36, adopción de Dynamic Resource Allocation implicaba mantener un device plugin legacy conviviendo con el driver DRA, o reescribir cada Pod para usar ResourceClaims explícitos. Kubernetes v1.37 resuelve ese fricción de migración: DRA Extended Resource support pasa a GA y permite que un workload que solicita example.com/gpu en su spec se resuelva automáticamente contra un DeviceClass DRA, sin tocar el manifiesto ni desplegar un plugin adicional.
Pero el salto de versión no se limita a esa graduación. El release incorpora taints y tolerations a nivel de dispositivo (Stable), un campo devices en ResourceClaim.status que expone IPs y MACs por interfaz, y una optimización en el scheduler que reduce el costo de requeue de O(N²) a O(1) en escalamientos masivos. Para equipos SRE y platform engineers que operan clusters con miles de Pods y múltiples tipos de hardware, estos cambios impactan directamente en la operación diaria.
Qué ocurrió
La promoción de DRA Extended Resource support a GA marca el cierre de un ciclo de tres releases: KEP aceptado en 1.34, Alpha en 1.35, Beta en 1.36, Stable en 1.37. El mecanismo permite definir un nombre de extended resource directamente sobre un DeviceClass. Cuando un Pod solicita ese nombre en resources.limits, el scheduler lo empareja con un dispositivo DRA sin que el workload declare un ResourceClaim. El backend de asignación se mueve a DRA mientras la interfaz del workload permanece idéntica.
Paralelamente, cinco features adicionales alcanzaron estabilidad o Beta: Device Taints and Tolerations (Stable), el atributo estándar resource.kubernetes.io/numaNode (Stable directo, sin feature gate), ResourceClaim status con datos de interfaz de red (Beta), ResourceClaim support para Workloads detrás del feature gate DRAWorkloadResourceClaims (Beta, deshabilitado por default), y DRA Consumable Capacity con valores fraccionales mediante DRAFractionalCapacityRange (Beta). El release suma además un lote de Alpha 2 y features nuevos como Derived Attributes con CEL, Device Compatibility Groups y PreQueueingHint.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para clusters que corren workloads GPU-intensive en GKE, EKS, AKS o bare-metal, la graduación de Extended Resources a GA elimina la deuda técnica de mantener device plugins como DaemonSets paralelos a los drivers DRA. Eso reduce superficie de ataque (menos componentes con permisos privilegiados), baja el consumo de recursos del nodo y simplifica el upgrade path: podés migrar el backend de asignación sin reescribir manifiestos de aplicaciones.
Las taints a nivel de dispositivo cambian la operativa de mantenimiento. Un operador que necesita sacar una NIC de producción para un firmware upgrade puede aplicar un DeviceTaintRule cluster-wide y el scheduler excluye ese dispositivo de nuevos Pods. Los Pods ya asignados al dispositivo tainteado se evictan automáticamente salvo que su ResourceClaim tolere el taint explícitamente. Esto replica la semántica de node taints que los equipos SRE ya manejan, pero a granularidad de hardware individual.
La optimización PreQueueingHint tiene impacto cuantificable: en benchmarks tempranos del equipo de SIG-Scheduling, el cambio de un scan completo de Pods unschedulables a un lookup por índice del pod informer redujo el throughput de requeue de O(N²) a O(1), duplicando la capacidad de scheduling en clusters con miles de Pods esperando recursos DRA. Para equipos que escalan clústeres con autoscaling agresivo, esto elimina un cuello de botella que antes se manifestaba como pods pendientes durante picos de demanda.
Detalles técnicos
DRA Extended Resource Support (GA): Se define el campo extendedResourceName en el spec de un DeviceClass. El scheduler intercepta solicitudes en resources.limits que coincidan con ese nombre y resuelve contra dispositivos DRA. No requiere ResourceClaim en el Pod. El driver DRA implementa la lógica de preparación; no hace falta un device plugin gRPC aparte.
Device Taints and Tolerations (Stable): Los drivers aplican taints por dispositivo. Los admins usan DeviceTaintRule (resource a nivel cluster) para taintear sin reconfigurar el driver. Eviction automática de Pods en dispositivos tainteados, con escape vía toleración en el ResourceClaim.
ResourceClaim.status.devices (Beta): Nuevo campo en .status que reporta por dispositivo: interfaceName, macAddress, ipAddresses para dispositivos de red. Permite construir controllers que consumen IPs reportadas por el driver sin hacer exec dentro del Pod.
PreQueueingHint (Alpha): Feature gate SchedulerPreQueueingHints. El DRA plugin usa un índice del pod informer para identificar exactamente qué Pods se ven afectados por un evento de ResourceClaim, reemplazando el full scan previo.
Derived Attributes (Alpha nuevo): Expresiones CEL en el manifest del DeviceClass permiten mapear atributos entre drivers que usan nombres distintos (ej: numa vs numaNode), extraer subcadenas de strings de topología monolíticos, o agrupar dispositivos en tiers de performance custom.
Atributo estándar resource.kubernetes.io/numaNode (Stable): Registro directo sin feature gate. Todos los drivers que exponen topología NUMA deben usar este nombre, habilitando comparación cross-driver en el scheduler.
Resource availability visibility (Alpha 2): El usuario crea un ResourcePoolStatusRequest para obtener un snapshot puntual de disponibilidad. No es un API de monitoreo continuo; para refrescar, se elimina y recrea el request.
Qué deberían hacer los administradores y equipos técnicos
Validar la migración a Extended Resources en staging. Si tu cluster ya tiene drivers DRA (NVIDIA, Intel, AMD), definí un DeviceClass con extendedResourceName: vendor.com/gpu y deployeá un Pod de test que solicite ese recurso en limits. Verificá que el scheduler resuelva sin ResourceClaim explícito. En clusters de producción con workloads heredados, esto permite mover el backend sin cambios en CI/CD.
Habilitar Device Taints para runbooks de mantenimiento. Reemplazá los cordon/drain a nivel de nodo (que evictan todos los Pods del nodo) por DeviceTaintRule a nivel de dispositivo. Ejemplo:
apiVersion: resource.k8s.io/v1
kind: DeviceTaintRule
metadata:
name: nic-firmware-maintenance
spec:
deviceSelector:
matchLabels:
resource.kubernetes.io/pci-address: «0000:3b:00.0»
taint:
key: «maintenance.nic»
effect: «NoSchedule»
Evaluar el feature gate SchedulerPreQueueingHints en clusters con más de 500 Pods concurrentes solicitando recursos DRA. Activá en un nodo de test del scheduler (–feature-gates=SchedulerPreQueueingHints=true) y compará métricas de scheduler_pending_pods y latencia de binding antes y después.
Planificar la adopción de ResourceClaim.status.devices si tienen controllers personalizados que necesitan IPs o MACs de dispositivos. Esto elimina la dependencia de kubectl exec o sidecars que leen interfaces de red dentro del Pod.
Monitorear feature gates Beta deshabilitados por default: DRAWorkloadResourceClaims, DRADeviceCompatibilityGroups, DRAFractionalCapacityRange. No los activen en producción hasta que SIG-Scheduling y WG Device Management publiquen benchmarks de estabilidad.
Conclusión
Kubernetes 1.37 no es un release incremental para DRA: es el punto donde la adopción deja de requerir un salto de fe arquitectónico. Extended Resources en GA elimina el motivo más común para postergar la migración de device plugins. Taints de dispositivo en Stable alinean la operación de hardware con las prácticas que los SRE ya tienen documentadas para nodos. Y la optimización del scheduler aborda un problema de escala que se manifestaba en clusters de más de 1000 Pods.
El roadmap para 1.38 ya anuncia otro ciclo ambicioso. Si gestionás clusters con aceleradores heterogéneos, este es el momento de participar en el WG Device Management de Slack y las reuniones en horarios US/EU y EU/APAC. Las features en Alpha 2 actual — Derived Attributes, Consumable Capacity, Optional Node Operations — tienen alta probabilidad de llegar a Beta en el próximo release.
Fuentes
- https://kubernetes.io/blog/2026/09/03/kubernetes-v1-37-dra-updates/
- https://www.cncf.io/announcements/
- https://www.datadoghq.com/blog/