Dynamic Resource Allocation, o DRA, en Kubernetes no elimina el proyecto HAMi para compartir unidades de procesamiento gráfico, pero cambia la distribución de funciones entre ambos. Tras la llegada de DRA a la disponibilidad general en Kubernetes v1.34 y su activación predeterminada desde v1.35, Kubernetes puede comprender y programar de forma nativa solicitudes de cuotas parciales de los recursos del dispositivo. Sin embargo, imponer esas cuotas dentro del contenedor durante las llamadas a CUDA no es responsabilidad de DRA; ahí HAMi-core sigue desempeñando un papel fundamental.
Un artículo de la CNCF, escrito por Mesut Oezdil, ofrece un análisis de la diferencia entre ambas etapas y explica cómo HAMi reconstruye parte de su ecosistema sobre DRA en lugar de abandonar el proyecto. El autor señala que la cuestión no es si uno de los dos proyectos sustituirá al otro, sino qué función de HAMi ha quedado cubierta por las capacidades nativas de Kubernetes.
¿Por qué el uso compartido de GPU necesitaba soluciones específicas?
La interfaz Device Plugin de Kubernetes era capaz principalmente de contar dispositivos. Una solicitud tradicional, como nvidia.com/gpu: 1, significaba reservar una tarjeta completa, sin un lenguaje nativo para solicitar 8.000 megabytes de memoria de una tarjeta o el 10 % de su capacidad de cómputo.
Para abordar esta situación, HAMi utiliza recursos extendidos como nvidia.com/gpumem y nvidia.com/gpucores. Sin embargo, el planificador predeterminado de Kubernetes trata estos valores como cantidades opacas: no sabe que la memoria y la capacidad de cómputo deben proceder de la misma tarjeta física, ni puede determinar por sí solo si varias cuotas superarán la capacidad de una tarjeta concreta.
Por ello, el enfoque tradicional depende de un webhook para modificar la solicitud, de una extensión específica del planificador que filtra los nodos y selecciona el identificador del dispositivo, y de registrar la decisión en una annotation. Posteriormente, Device Plugin lee esta decisión para inyectar límites como CUDA_DEVICE_MEMORY_LIMIT_0=8000m y CUDA_DEVICE_SM_LIMIT=10, además de cargar previamente la biblioteca libvgpu.so para imponer los límites.
Según el artículo, DaoCloud ejecutó más de 10.000 unidades GPU en más de 10 centros de datos mediante este enfoque. Sin embargo, su arquitectura sigue vinculada a un formato específico de annotations y a componentes que HAMi entiende; esa es la brecha que DRA fue diseñado para solucionar.
¿Qué añade DRA?
DRA sustituye el modelo de conteo de dispositivos por un modelo de solicitudes, con cuatro objetos principales en la interfaz resource.k8s.io/v1:
- ResourceSlice: lo publica el controlador del dispositivo y describe el hardware real de cada nodo, incluidos el modelo, la memoria y la arquitectura.
- DeviceClass: define clases de dispositivos y sus filtros mediante expresiones CEL.
- ResourceClaim: lo crea el propietario de la carga de trabajo para solicitar un dispositivo según la clase, los selectores y las restricciones.
- ResourceClaimTemplate: crea una solicitud independiente para cada réplica de la carga de trabajo.
El planificador asigna un dispositivo específico a la solicitud antes de vincular el contenedor, y el resultado aparece en el estado de ResourceClaim como un objeto API estructurado. Esto proporciona a la decisión un lugar nativo que kubectl puede leer, que RBAC puede proteger y sobre el que otros controladores pueden construir, en lugar de almacenarla como una cadena de texto en una annotation.
Pero el DRA básico por sí solo no basta para compartir memoria al estilo de HAMi. La extensión importante aquí es Consumable Capacity, que apareció de forma experimental en v1.34 detrás de la puerta de funcionalidades DRAConsumableCapacity y pasó a ser experimental y estar activada de forma predeterminada desde v1.36. Esta extensión permite al controlador anunciar que el dispositivo acepta múltiples asignaciones y permite que la solicitud pida una cantidad específica de un recurso con nombre en el dispositivo, como memoria o capacidad de cómputo.
Así, la correspondencia con los recursos de HAMi se vuelve prácticamente directa: gpumem se convierte en una solicitud de capacidad de memoria, gpucores se convierte en una solicitud de capacidad de cómputo, y el cálculo de si la tarjeta aún dispone de la capacidad solicitada pasa de la extensión de programación de HAMi al propio planificador de Kubernetes.
Programar no significa imponer límites
El análisis subraya que DRA realiza el seguimiento de las promesas efectuadas por el planificador, pero no impide que el contenedor las supere durante la ejecución. Las llamadas a CUDA no conocen el contenido de ResourceClaim, y una carga de trabajo voraz podría intentar consumir memoria adicional a costa de otro contenedor.
HAMi-core se encarga de esta función mediante una biblioteca C, libvgpu.so, que intercepta las llamadas a CUDA y a NVIDIA Management Library y aplica los límites desde el espacio de usuario. Según el ejemplo del artículo, si dos contenedores reciben 8.000 megabytes cada uno, el contenedor que supera su cuota recibe un error de CUDA por falta de memoria al alcanzar su límite, mientras el otro contenedor continúa funcionando.
Esta protección de software no sustituye a la partición de hardware en entornos hostiles multiinquilino. Una carga de trabajo que eluda la precarga de la biblioteca, utilice un enlace estático con el controlador de CUDA o se beneficie de configuraciones como CUDA_DISABLE_CONTROL podría escapar de la interceptación. El autor señala que NVIDIA Multi-Instance GPU, o MIG, es más adecuada para el aislamiento de hardware, mientras que la interceptación de software ofrece una granularidad de hasta incrementos de 1 megabyte para la memoria y del 1 % para el cómputo, frente a los perfiles MIG fijos.
¿Cómo reconstruye HAMi su ecosistema sobre DRA?
La nueva arquitectura se distribuye en tres repositorios con funciones diferentes:
- k8s-dra-driver: publica la memoria y la capacidad de cómputo de cada GPU como capacidad consumible en ResourceSlices, ejecuta el complemento de kubelet y conecta los contenedores mediante CDI, adjuntando la aplicación de límites de HAMi-core.
- HAMi-DRA: es un webhook de mutación de admisión que elimina los recursos extendidos tradicionales de las solicitudes y crea ResourceClaims equivalentes, conservando las annotations para la selección por UUID y el tipo de dispositivo. Según el artículo, HAMi-DRA v0.2.0 estaba listo para producción con HAMi v2.9, y posteriormente la serie de versiones pasó a v0.2.1.
- HAMi: documenta el modo DRA como opción de instalación desde la versión v2.8, activa también de forma predeterminada el componente de monitorización y expone métricas de los dispositivos por contenedor mediante Prometheus en el puerto 31995.
Una de las ventajas de HAMi-DRA es que deja la programación en manos del planificador que administra el clúster, lo que permite utilizar Volcano, KAI Scheduler o cualquier otro planificador que entienda DRA sin añadir una integración específica con HAMi. Sin embargo, esta decisión tiene un coste: HAMi-DRA no cuenta con un planificador propio y, por tanto, no garantiza decisiones conscientes de la topología, como seleccionar un par de unidades GPU conectadas mediante NVLink.
Requisitos y elección práctica
El modo DRA requiere Kubernetes v1.34 o posterior con DRAConsumableCapacity activado. En las versiones v1.34 y v1.35, la puerta de funcionalidades es experimental y está desactivada de forma predeterminada, lo que puede impedir su uso en servicios gestionados que no permiten modificar la configuración del servidor de API. En v1.36 pasó a ser experimental y a estar activada de forma predeterminada. También se necesita un runtime compatible con CDI, como containerd o CRI-O con CDI activado, un controlador NVIDIA de la versión 440 o posterior y un controlador DRA adecuado para el tipo de acelerador.
El artículo describe la ruta de NVIDIA como la más madura, con la llegada de soporte para Ascend y Enflame y la documentación de Hygon DCU mediante k8s-dcu-dra-driver. En cambio, el modo tradicional de HAMi cubre más de 12 familias de dispositivos desde v2.9, incluidos Cambricon MLUs, Iluvatar, MetaX, Moore Threads, Kunlunxin, AWS Neuron y Vastai. Por ello, los clústeres con múltiples proveedores siguen siendo candidatos para continuar en la ruta tradicional hasta que se amplíe la cobertura de los controladores DRA.
No se deben ejecutar el modo DRA y el modo Device Plugin tradicional en el mismo clúster, porque los dos sistemas de programación parecerían gestionar la misma capacidad sin poder ver las promesas del otro sistema. Según la evaluación del autor, el modo tradicional es adecuado para clústeres administrados que no habilitan puertas de características, versiones anteriores y flotas de varios proveedores. En cambio, los clústeres de NVIDIA que controlan el plano de control de Kubernetes, especialmente en v1.36, pueden probar el modo DRA en un entorno de prueba, comenzando por HAMi-DRA para evitar modificar los archivos de implementación actuales.
Consumable Capacity sigue siendo completamente inestable en Kubernetes; además, el gráfico de Helm de k8s-dra-driver todavía está clasificado como en desarrollo, y la cobertura de proveedores en el lado de DRA sigue siendo inferior a la del modo tradicional. La conclusión del artículo es que DRA se encarga del lenguaje de solicitudes y de la programación, mientras que HAMi-core conserva la capacidad de ejecución dentro del contenedor; es decir, la relación entre ambos tiende a la integración, no al reemplazo.