Container Compute Service (ACS) alloue les périphériques GPU aux pods en fonction de la topologie GPU de chaque modèle de nœud GPU-HPN. Les pods s'exécutant sur le même nœud échangent des données via des canaux tels que NVLink, et les contraintes de partitionnement garantissent une communication GPU efficace et équitable.
Prérequis
Cette fonctionnalité prend uniquement en charge les pods qui utilisent la classe de calcul gpu-hpn (compute-class) ainsi que les types de nœuds GPU-HPN correspondants.
Contexte
Au sein d'un nœud GPU-HPN, les périphériques GPU se connectent et communiquent par un ou plusieurs canaux, permettant à des pods requérant différents nombres de GPU de s'exécuter sur le même nœud. Afin de maintenir une communication GPU efficace et équitable, et d'éviter que les pods ne se perturbent mutuellement, ACS planifie les pods en se basant sur la topologie GPU du nœud. Il divise les périphériques GPU en partitions correspondant aux nombres de GPU demandés par les pods, puis alloue la partition optimale à chaque pod.
La figure suivante illustre un nœud doté de huit GPU. Chaque groupe est constitué de quatre GPU. Les GPU au sein d'un même groupe sont interconnectés directement, tandis que les deux groupes sont reliés via PCIe.
ACS divise les périphériques de ce nœud selon les partitions suivantes :
|
Nombre de GPU demandés par le pod |
Résultats d'allocation des périphériques disponibles |
|
8 |
[0,1,2,3,4,5,6,7] |
|
4 |
[0,1,2,3], [4,5,6,7] |
|
2 |
[0,1], [2,3], [4,5], [6,7] |
|
1 |
[0], [1], [2], [3], [4], [5], [6], [7] |
La création et la suppression répétées de pods sur un nœud peuvent entraîner une fragmentation des partitions, empêchant la planification de nouveaux pods et les laissant dans l'état Pending. Pour libérer les périphériques requis par un pod en attente, examinez les résultats d'allocation des périphériques des pods présents sur le nœud et expulsez-en certains en fonction de vos priorités métier. La FAQ de cette rubrique explique comment planifier les ressources des nœuds pour éviter la fragmentation des partitions, comment sélectionner les pods à expulser, et comment le type, la version et la configuration du planificateur influencent la prise en compte des partitions lors de la planification.
Partitions des types de nœuds GPU-HPN
Les partitions et les modèles de GPU varient selon les types de nœuds GPU-HPN proposés par ACS. Pour vérifier quelles partitions sont utilisées sur un nœud, consultez les résultats d'allocation des périphériques des pods s'exécutant sur ce nœud.
gpu.p16en-16XL
Ce type de nœud dispose de 16 GPU du modèle P16EN. Le tableau ci-dessous répertorie les partitions correspondant aux nombres de GPU demandés par les pods.
|
Nombre de GPU demandés par le pod |
Résultats d'allocation des périphériques disponibles |
|
16 |
[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15] |
|
8 |
[0,1,2,3,4,5,6,7], [8,9,10,11,12,13,14,15] |
|
4 |
[0,1,2,3], [4,5,6,7], [8,9,10,11], [12,13,14,15] |
|
2 |
[0,3], [1,2], [4,7], [5,6], [8,11], [9,10], [12,15], [13,14] |
|
1 |
[0], [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15] |
Consulter les résultats de planification d'un pod
Résultat d'allocation des périphériques
Pour un pod GPU-HPN, le résultat d'allocation des périphériques est enregistré dans les annotations du pod, selon le format suivant :
apiVersion: v1
kind: Pod
metadata:
annotations:
alibabacloud.com/device-allocation: '{"gpus": {"minor": [0,1,2,3]}}'Message d'échec de planification dû à la fragmentation des partitions
Un pod qui ne peut pas être planifié reste dans l'état Pending. Exécutez la commande suivante pour afficher le message d'échec de planification :
kubectl describe pod pod-demoSortie attendue, avec le reste du contenu omis :
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 26m default-scheduler 0/5 nodes are available: 2 Node(s) Insufficient Partitioned GPU Devices, 1 Node(s) xxx, 2 Node(s) xxx.Dans un message similaire à 0/5 nodes are available: xxx, Insufficient Partitioned GPU Devices indique que la planification a échoué en raison d'une fragmentation des partitions sur le nœud.
FAQ
Comment planifier les ressources et les politiques des nœuds pour éviter la fragmentation des partitions ?
Planifiez les ressources et les politiques des nœuds comme suit :
Groupez les nœuds par nombre de GPU demandé — Définissez différents libellés sur vos nœuds pour gérer les ressources en fonction du nombre de GPU requis par vos pods. Par exemple, planifiez les pods demandant 8 GPU et ceux demandant 1 GPU sur des nœuds distincts.
Libérez les périphériques inactifs lorsque des pods sont déjà en attente — Lorsque la fragmentation des partitions laisse des pods dans l'état Pending dans votre cluster, utilisez des mécanismes tels que la désplanification pour expulser certains pods de faible priorité et libérer des périphériques inactifs pour les pods en attente.
Réservez de la capacité si vous ne pouvez pas planifier les libellés des nœuds — Si vous disposez de peu de nœuds ou si vous ne pouvez pas planifier les libellés des nœuds, et que vos pods demandent une large gamme de nombres de GPU, réservez de la capacité pour répondre aux exigences de ressources de vos applications. Pour plus d'informations, consultez Réservation de capacité pour les pods GPU.
Comment sélectionner les pods à expulser lors de la résolution de la fragmentation des partitions ?
Identifiez le nombre de GPU demandés par le pod en attente, par exemple 8 GPU.
Sur le nœud cible, lisez l'annotation
alibabacloud.com/device-allocationde chaque pod pour déterminer quels périphériques sont déjà alloués. Pour plus d'informations, consultez résultat d'allocation des périphériques.Décidez quels pods expulser en fonction des résultats d'allocation, et assurez-vous que les périphériques libérés par l'expulsion répondent à la fois au nombre de GPU demandé et aux contraintes de partitionnement du pod en attente. Par exemple, une demande de 8 GPU sur P16EN nécessite que les ID de périphérique [0,1,2,3,4,5,6,7] ou [8,9,10,11,12,13,14,15] soient tous non alloués.
Expulsez les pods en exécutant une commande telle que
evictoudelete.
Que dois-je savoir sur les partitions lors de l'utilisation d'un planificateur personnalisé ?
Une fois qu'un planificateur personnalisé a assigné un pod à un nœud, ACS alloue les périphériques pour ce pod sur ledit nœud. Lors de l'allocation des périphériques, ACS regroupe les périphériques aussi densément que possible afin d'éviter la fragmentation des partitions.
Un planificateur personnalisé doit uniquement prendre en compte la capacité totale en GPU d'un nœud. Pour les ressources GPU, privilégiez une politique de regroupement des nœuds MostAllocated), qui réduit la fragmentation des partitions.
Quels planificateurs sont conscients de la topologie des partitions GPU-HPN ?
Utilisez le tableau suivant pour déterminer si votre planificateur est conscient de la topologie des partitions des nœuds GPU-HPN.
Type de planificateur | Conditions | Description |
Planificateur par défaut ACS | Toutes les conditions suivantes sont remplies :
et l'une des conditions de version suivantes est remplie :
Pour les versions prises en charge, consultez kube-scheduler. | Le planificateur est conscient de l'état d'allocation des partitions du nœud actuel et exclut les nœuds dont les partitions ne peuvent pas satisfaire la demande. L'événement d'échec de planification du pod inclut le message |
Planificateur par défaut ACK | Toutes les conditions suivantes sont remplies :
Vous pouvez trouver les versions prises en charge dans kube-scheduler. | Le planificateur est conscient de l'état d'allocation des partitions du nœud actuel et exclut les nœuds dont les partitions ne peuvent pas satisfaire la demande. L'événement d'échec de planification du pod inclut le message |
Autres types de planificateurs | Le type de planificateur, les conditions ou la configuration ne répondent pas aux exigences précédentes. | Le planificateur n'est pas conscient de la topologie des partitions. Le nœud GPU-HPN alloue les périphériques aussi densément que possible. Si les partitions ne peuvent pas satisfaire la demande, le pod reste dans l'état Pending sur le nœud jusqu'à ce que les partitions puissent la satisfaire, et l'événement d'échec de planification du pod inclut le message |