Hasta esta semana, el driver que controla cómo Kubernetes asigna GPUs a los workloads de IA era propiedad de NVIDIA. No en el sentido de que fuera secreto — el código estaba en GitHub — sino en el sentido que importa: NVIDIA decidía la dirección, los plazos y las prioridades. Eso acaba de cambiar. En KubeCon Europa 2026 en Ámsterdam, NVIDIA donó su Dynamic Resource Allocation (DRA) Driver for GPUs a la Cloud Native Computing Foundation (CNCF), que pasa a tener propiedad plena bajo el proyecto Kubernetes.
El movimiento no es solo simbólico. Es la diferencia entre una pieza crítica de infraestructura que evoluciona según el roadmap de un vendedor y una que evoluciona según las necesidades de los miles de equipos que la usan en producción.
¿Qué es DRA y por qué importaba que fuera de NVIDIA?
La asignación dinámica de recursos (DRA, Dynamic Resource Allocation) es el mecanismo que permite a Kubernetes gestionar aceleradores como GPUs con granularidad real. Antes de DRA, Kubernetes trataba las GPUs como recursos genéricos: solicitabas una GPU, el scheduler te asignaba una GPU, punto. Sin distinción entre tipos, sin configuración, sin compartición inteligente.
Claude Desbloqueado
Mi curso avanzado para aprender a sacarle mucho más provecho a Claude en el trabajo y en el día a día, con funciones y usos más potentes. Comienza el 23 de marzo.
→ Inscríbete hoy 🚀Con DRA, un workload puede pedir exactamente lo que necesita: una fracción de GPU, una GPU con MIG (Multi-Instance GPU) habilitado, un par de GPUs conectadas por NVLink, o una configuración multinodo para entrenar modelos masivos en clústeres de Grace Blackwell. El driver actúa como el intermediario que traduce esos requerimientos en asignaciones reales de hardware.
El problema con el modelo anterior es de incentivos. NVIDIA tiene razones legítimas para que su driver soporte bien su propio hardware — eso está bien. Pero cuando Amazon Web Services, Google Cloud, Red Hat, Microsoft o CERN necesitan un comportamiento específico que no está en el roadmap de NVIDIA, dependían de NVIDIA para hacerlo. Para infraestructura crítica de producción, esa dependencia es un riesgo real.
Lo que cambia con la donación
La transferencia a la CNCF no es solo un cambio de repositorio. Bajo el gobierno de la CNCF, el driver se convierte en un proyecto comunitario con el mismo peso que otras piezas centrales del ecosistema cloud-native. Los contribuidores de cualquier empresa — Red Hat, Canonical, SUSE, AWS, Google, usuarios independientes — pueden proponer cambios, revisar código y definir la dirección técnica en igualdad de condiciones.
El impacto práctico es inmediato en tres áreas:
Compartición más inteligente de GPUs. El driver actualizado soporta Multi-Process Service (MPS) y Multi-Instance GPU (MIG), lo que permite que múltiples workloads compartan el mismo hardware físico con aislamiento real. Para una empresa que paga $2 por hora por una GPU H100, poder ejecutar cuatro jobs en simultáneo sin interferencia vale mucho más que una mejora de benchmark.
Escala multinodo. El driver ahora soporta nativamente NVLink multinodo, la tecnología que conecta GPUs de distintos servidores como si fueran una sola unidad. Esto es requisito para entrenar modelos de la escala de los que usan los grandes labs hoy — y hasta ahora requería configuración manual compleja fuera de Kubernetes.
Reconfiguración en vuelo. Los equipos pueden cambiar cómo están asignados los recursos sin reiniciar los workloads. En un clúster de producción donde los modelos corren 24/7, eso reduce el downtime a cero en la mayoría de los escenarios de reconfiguración.
El movimiento de gobernanza que nadie menciona
La donación del driver no ocurre en el vacío. NVIDIA lleva varias semanas construyendo un ecosistema open source alrededor de su infraestructura de IA: NemoClaw y OpenShell para agentes autónomos en enterprise, el KAI Scheduler que acaba de entrar como proyecto sandbox de la CNCF, y ahora el DRA driver.
El patrón es consistente: NVIDIA dona las capas de infraestructura que necesitan confianza comunitaria para adoptarse masivamente en enterprise, mientras retiene el control sobre el hardware y los modelos de alto valor. Es la misma lógica que usó Red Hat con el kernel de Linux hace décadas: hacer open source lo que fortalece el ecosistema y retener lo que diferencia tu negocio.
Hay además un segundo actor en este anuncio que merece atención: la integración con Kata Containers, los contenedores con aislamiento de máquina virtual. Con este soporte, los workloads de IA pueden correr en GPU con garantías de aislamiento mucho más fuertes que un contenedor estándar. Para sectores como salud, finanzas o gobierno — donde los datos de entrenamiento son sensibles — eso elimina un obstáculo de adopción real. La inferencia distribuida con hardware de NVIDIA en ambientes enterprise siempre tuvo este problema de fondo: la compartición de hardware implicaba compartir garantías de seguridad.
¿Quién gana y quién pierde?
Los equipos de plataforma que gestionan clústeres Kubernetes para workloads de IA son los beneficiarios directos. Dejan de ser rehenes del roadmap de un solo vendedor y ganan visibilidad sobre cómo funciona exactamente la capa de asignación de su infraestructura más cara.
Los proveedores de cloud también salen ganando: AWS, Google y Microsoft ya colaboraron activamente en este proyecto, y la CNCF es precisamente el entorno donde tienen voz técnica real. Que el KAI Scheduler también entre como proyecto CNCF sandbox refuerza este punto — la gestión de carga de trabajo de IA en GPU se está estandarizando en capas que ningún proveedor controla unilateralmente.
¿Y NVIDIA? No pierde nada que importara en el largo plazo. Lo que vende son las GPUs físicas, los sistemas Grace Blackwell, los clusters NVLink. Que el software de orquestación sea open source no le quita ni una sola venta de hardware. Al contrario: reduce la fricción de adopción y amplía el universo de equipos que pueden poner sus GPUs en producción sin necesitar consultores especializados.
Por qué importa ahora
La mayoría de las empresas que corren IA seria lo hacen en Kubernetes. No porque sea la solución perfecta para todo, sino porque es donde ya vive el resto de su infraestructura. La pregunta nunca fue si Kubernetes soportaría IA — era cuándo lo haría bien.
El DRA driver era el eslabón que faltaba para que la gestión de GPUs en Kubernetes fuera tan madura como la gestión de CPU y memoria. Con la donación a la CNCF, ese componente crítico pasa a ser infraestructura neutral que cualquier equipo puede usar, auditar, extender y confiar.
Para los equipos que están planificando su infraestructura de IA para los próximos 12-18 meses, la señal es clara: la capa de orquestación de GPU se está consolidando alrededor de estándares abiertos. Apostar a soluciones propietarias en esta capa ahora es un riesgo que no se justifica.
