La Dynamic Resource Allocation, ou DRA, de Kubernetes ne rend pas le projet HAMi de partage des unités de traitement graphique obsolète, mais elle modifie la répartition des rôles entre eux. Depuis que la DRA est devenue généralement disponible dans Kubernetes v1.34 et qu’elle est activée par défaut depuis v1.35, Kubernetes est capable de comprendre nativement les demandes de quotas partiels de ressources des périphériques et de les planifier. En revanche, l’application de ces quotas à l’intérieur du conteneur lors des appels CUDA ne relève pas de la DRA ; c’est là que le rôle de HAMi-core reste essentiel.
L’article de la CNCF, rédigé par Mesut Oezdil, propose une analyse de la différence entre ces deux étapes et explique comment HAMi reconstruit une partie de son écosystème au-dessus de la DRA au lieu d’abandonner le projet. Selon l’auteur, la question n’est pas de savoir si l’un des deux projets remplacera l’autre, mais quelle fonction de HAMi est désormais couverte par les capacités natives de Kubernetes.
Pourquoi le partage des GPU a-t-il nécessité des solutions spécifiques ?
L’interface Device Plugin de Kubernetes était essentiellement capable de compter les périphériques. Une demande traditionnelle, telle que nvidia.com/gpu: 1, signifiait réserver une carte entière, sans langage natif permettant de demander 8 000 mégaoctets de mémoire d’une carte ou 10 % de sa capacité de calcul.
Pour y remédier, HAMi utilise des ressources étendues telles que nvidia.com/gpumem et nvidia.com/gpucores. Cependant, le planificateur par défaut de Kubernetes traite ces valeurs comme des nombres abstraits : il ne sait pas que la mémoire et la capacité de calcul doivent provenir de la même carte physique, et il ne peut pas à lui seul déterminer si plusieurs quotas dépasseront la capacité d’une carte donnée.
Le chemin traditionnel repose donc sur un webhook pour modifier la demande, une extension de planificateur qui filtre les nœuds et sélectionne l’identifiant du périphérique, puis enregistre la décision dans une annotation. Le Device Plugin lit ensuite cette décision afin d’injecter des limites telles que CUDA_DEVICE_MEMORY_LIMIT_0=8000m et CUDA_DEVICE_SM_LIMIT=10, tout en préchargeant la bibliothèque libvgpu.so pour appliquer les limites.
D’après l’article, DaoCloud a fait fonctionner plus de 10 000 GPU dans plus de 10 centres de données en utilisant cette approche. Toutefois, son architecture reste liée à un format d’annotations spécifique et à des composants compris par HAMi, ce qui constitue la lacune que la DRA a été conçue pour combler.
Qu’apporte la DRA ?
La DRA remplace le modèle de comptage des périphériques par un modèle fondé sur les revendications, avec quatre objets principaux dans l’API resource.k8s.io/v1 :
- ResourceSlice : publié par le pilote du périphérique, il décrit le matériel réel de chaque nœud, notamment le modèle, la mémoire et l’architecture.
- DeviceClass : il définit les classes de périphériques et leurs filtres à l’aide d’expressions CEL.
- ResourceClaim : créé par le propriétaire de la charge de travail, il demande un périphérique selon la classe, les sélecteurs et les contraintes.
- ResourceClaimTemplate : il crée une revendication indépendante pour chaque instance de la charge de travail.
Le planificateur attribue un périphérique précis à la revendication avant de l’associer au conteneur, et le résultat apparaît dans l’état du ResourceClaim sous la forme d’un objet API structuré. La décision dispose ainsi d’un emplacement natif que kubectl peut lire, que RBAC peut protéger et sur lequel d’autres contrôleurs peuvent s’appuyer, au lieu d’être stockée sous forme de chaîne dans une annotation.
Toutefois, la DRA de base ne suffit pas à elle seule pour partager la mémoire selon le modèle de HAMi. L’extension importante ici est Consumable Capacity, apparue à titre expérimental dans v1.34 derrière la passerelle DRAConsumableCapacity, puis devenue expérimentale et activée par défaut depuis v1.36. Cette extension permet au pilote de déclarer qu’un périphérique accepte plusieurs allocations et permet à une revendication de demander une quantité précise d’une ressource nommée sur le périphérique, comme la mémoire ou la capacité de calcul.
La correspondance avec les ressources de HAMi devient ainsi presque directe : gpumem se transforme en demande de capacité mémoire, gpucores en demande de capacité de calcul, tandis que la détermination de la capacité encore disponible sur la carte est transférée de l’extension de planification de HAMi au planificateur Kubernetes lui-même.
La planification ne signifie pas l’application des limites
L’analyse souligne que la DRA suit les promesses faites par le planificateur, mais n’empêche pas le conteneur de les dépasser pendant son exécution. Les appels CUDA ne savent pas ce qu’indique le ResourceClaim, et une charge de travail gourmande peut tenter de consommer de la mémoire supplémentaire au détriment d’un autre conteneur.
HAMi-core assure cette fonction au moyen d’une bibliothèque C, libvgpu.so, qui intercepte les appels CUDA et NVIDIA Management Library et applique les limites depuis l’espace utilisateur. Selon l’exemple présenté dans l’article, si deux conteneurs obtiennent chacun 8 000 mégaoctets, le conteneur qui dépasse son quota reçoit une erreur CUDA de mémoire insuffisante lorsqu’il atteint sa limite, tandis que l’autre conteneur continue de fonctionner.
Cette protection logicielle ne remplace pas la partition matérielle dans les environnements multi-locataires hostiles. Une charge qui contourne le préchargement de la bibliothèque, utilise une liaison statique avec le pilote CUDA ou exploite des paramètres tels que CUDA_DISABLE_CONTROL peut échapper à l’interception. L’auteur indique que le NVIDIA Multi-Instance GPU, ou MIG, est plus adapté à l’isolation matérielle, tandis que l’interception logicielle offre une granularité allant jusqu’à 1 mégaoctet pour la mémoire et 1 % pour le calcul, en comparaison avec les profils MIG fixes.
Comment HAMi reconstruit-il son écosystème au-dessus de la DRA ?
La nouvelle architecture est répartie entre trois dépôts qui remplissent des fonctions différentes :
- k8s-dra-driver : il publie la mémoire et la capacité de calcul de chaque GPU comme capacité consommable dans les ResourceSlices, exécute le module complémentaire kubelet et relie les conteneurs via CDI en y attachant l’application des limites de HAMi-core.
- HAMi-DRA : webhook de mutation à l’admission, il supprime les ressources étendues traditionnelles des demandes et crée des ResourceClaims équivalentes, tout en conservant les annotations propres au ciblage par UUID et au type de périphérique. Selon l’article, HAMi-DRA v0.2.0 était prêt pour la production avec HAMi v2.9, puis la série des versions est passée à v0.2.1.
- HAMi : il documente le mode DRA comme option d’installation depuis la version v2.8, active également le composant de surveillance par défaut et expose les métriques des périphériques pour chaque conteneur via Prometheus sur le port 31995.
L’un des avantages de HAMi-DRA est de laisser la planification au planificateur qui gère le cluster, ce qui permet d’utiliser Volcano, KAI Scheduler ou tout autre planificateur comprenant la DRA sans ajouter d’intégration spécifique à HAMi. Cette décision a toutefois un coût : HAMi-DRA ne possède pas son propre planificateur et ne garantit donc pas des décisions tenant compte de la topologie, comme la sélection d’une paire de GPU reliés par NVLink.
Exigences et choix pratiques
Le mode DRA nécessite Kubernetes v1.34 ou une version ultérieure, avec l’activation de DRAConsumableCapacity. Dans les versions v1.34 et v1.35, la passerelle est expérimentale et désactivée par défaut, ce qui peut empêcher son utilisation dans les services managés qui n’autorisent pas la modification des paramètres du serveur d’API. Dans v1.36, elle est devenue expérimentale et activée par défaut. Il faut également un runtime prenant en charge CDI, tel que containerd ou CRI-O avec CDI activé, un pilote NVIDIA en version 440 ou ultérieure, ainsi qu’un pilote DRA adapté au type d’accélérateur.
L’article décrit la solution NVIDIA comme la plus mature, avec l’arrivée de la prise en charge d’Ascend et d’Enflame, ainsi que la documentation de Hygon DCU via k8s-dcu-dra-driver. En revanche, le mode traditionnel de HAMi prend en charge plus de 12 familles de périphériques depuis la v2.9, notamment les MLU de Cambricon, Iluvatar, MetaX, Moore Threads, Kunlunxin, AWS Neuron et Vastai. Les clusters multi-fournisseurs restent donc susceptibles de conserver le chemin traditionnel jusqu’à l’élargissement de la couverture des pilotes DRA.
Il ne faut pas activer le mode DRA et le mode Device Plugin traditionnel dans le même cluster, car les deux systèmes de planification donneraient l’impression de gérer la même capacité sans connaître les promesses de l’autre système. Selon l’évaluation de l’auteur, le mode traditionnel convient aux clusters gérés qui n’activent pas les feature gates, aux versions antérieures et aux flottes multi-fournisseurs. Quant aux clusters NVIDIA qui contrôlent le plan de contrôle Kubernetes, notamment sous v1.36, ils peuvent expérimenter le mode DRA dans un environnement de test, en commençant par HAMi-DRA afin d’éviter de modifier les fichiers de déploiement actuels.
Consumable Capacity reste définitivement instable dans Kubernetes ; de plus, le chart Helm de k8s-dra-driver est toujours classé comme étant en cours de développement, et la couverture des fournisseurs du côté DRA demeure inférieure à celle du mode traditionnel. La conclusion de l’article est que DRA prend en charge le langage des requêtes et la planification, tandis que HAMi-core conserve la capacité d’exécution à l’intérieur du conteneur ; autrement dit, leur relation évolue vers l’intégration plutôt que le remplacement.