Заменяет ли Kubernetes DRA проект HAMi¶
8.0/10
Контекст¶
Стандартный device plugin в Kubernetes умел лишь считать целые GPU, поэтому HAMi построил собственный обходной конвейер из webhook, расширителя планировщика и аннотаций, чтобы выражать дробные запросы памяти и вычислительных долей. С выходом Dynamic Resource Allocation в GA и появлением consumable capacity планировщик научился нативно учитывать срезы устройств, и автор разбирает, делает ли это HAMi ненужным.
Суть¶
Автор разделяет HAMi на две обязанности: кодирование дробных запросов для планировщика и принудительное соблюдение лимитов внутри контейнера. DRA с объектами ResourceSlice, DeviceClass и ResourceClaim забирает первую часть: запрос 8000 MiB и 10% ядер становится типизированной capacity-заявкой, а распределение фиксируется в статусе ResourceClaim вместо приватной аннотации. Однако DRA лишь отслеживает обещания планировщика и не мешает контейнеру нарушить лимит вызовами CUDA, поэтому HAMi-core с предзагружаемой libvgpu.so остается необходимым уровнем исполнения. Практически HAMi перестраивается вокруг DRA в трех репозиториях: k8s-dra-driver публикует память и вычисления GPU как consumable capacity, HAMi-DRA webhook переводит старые манифесты nvidia.com/gpu, gpumem и gpucores в ResourceClaims без изменения пользовательских YAML, а мониторинг продолжается через Prometheus-порт 31995. Автор отмечает требования Kubernetes v1.34+, включенный feature gate до v1.36, CDI-совместимый runtime, запрет на одновременную работу DRA и device-plugin режимов, а также ограничения: beta-статус consumable capacity, слабую топологическую осведомленность webhook-пути и возможность обхода программной изоляции.
Вывод¶
DRA не заменяет HAMi целиком: он впитывает слой запросов и планирования, но runtime-принуждение HAMi-core остается отдельной и необходимой частью GPU-шеринга. По мысли автора, зрелая архитектура объединяет нативный язык DRA с исполнительным механизмом HAMi, а не выбирает между ними.