Allocation dynamique des ressources par rapport aux plugins d'appareils Pilotes DRA pour Amazon EKS Plug-ins d'appareils pour Amazon EKS Considérations DRA ResourceClaim contre ResourceClaimTemplate Rubriques

Aidez à améliorer cette page

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page qui se trouve dans le volet droit de chaque page.

Gérez les périphériques matériels sur Amazon EKS

Amazon EKS prend en charge deux mécanismes Kubernetes pour gérer des périphériques matériels spécialisés dans les clusters EKS : l'allocation dynamique des ressources (DRA) et les plug-ins de périphériques. Les deux mécanismes permettent aux charges de travail d'accéder à des accélérateurs matériels tels que les GPU NVIDIA et les puces AWS Trainium, et à des périphériques réseau hautes performances tels que Elastic Fabric Adapter (EFA).

Nous vous recommandons d'utiliser des pilotes DRA pour les nouveaux déploiements avec les versions 1.34 et ultérieures de Kubernetes lorsque vous utilisez le provisionnement de capacité statique dans Karpenter, des groupes de nœuds gérés par EKS ou des nœuds autogérés. Le DRA n'est actuellement pas pris en charge avec le mode automatique EKS. DRA fournit une sélection d'appareils plus riche, une planification tenant compte de la topologie et des fonctionnalités de partage d'appareils qui ne sont pas possibles avec les plug-ins d'appareils.

Consultez la documentation Kubernetes sur l'allocation dynamique des ressources et les plug-ins de périphériques pour obtenir des informations générales sur ces deux fonctionnalités de Kubernetes.

Allocation dynamique des ressources par rapport aux plugins d'appareils

Les plug-ins de périphériques Kubernetes ont été le principal mécanisme permettant d'exposer du matériel spécialisé aux charges de travail Kubernetes. Les plug-ins d'appareils présentent les appareils en tant que ressources étendues (par exemple, nvidia.com/gpu ouaws.amazon.com/neuroncore) que vous demandez dans les demandes et limites de ressources du conteneur. Bien que les plug-ins d'appareils soient largement pris en charge et utilisés, ils présentent des limites :

Les appareils sont demandés sous forme de nombres entiers opaques sans filtrage basé sur les attributs.
Le partage d'appareils entre conteneurs ou pods n'est pas pris en charge.
Aucune allocation expressive tenant compte de la topologie entre les types d'appareils.
Des extensions de planificateur personnalisées sont souvent nécessaires pour un placement intelligent.

L'allocation dynamique des ressources (DRA) est une fonctionnalité de Kubernetes généralement disponible dans la version 1.34 de Kubernetes qui répond à ces limitations. Avec DRA, les pilotes de périphériques publient des attributs de périphérique enrichis dans le planificateur Kubernetes via des objets. ResourceSlice Vous demandez des appareils en utilisant des catégories ResourceClaim et ResourceClaimTemplate des objets qui font référence à des DeviceClass catégories.

DRA permet de :

Attribute-based sélection de l'appareil à l'aide d'expressions CEL (Common Expression Language).
Topology-aware allocation qui garantit que les périphériques sont co-localisés sur le même commutateur PCIe ou le même domaine NUMA.
Partage d'appareils entre plusieurs conteneurs ou Pods via des ResourceClaim références partagées.
Partitionnement et partage dynamiques des GPU NVIDIA lors de l'utilisation du MIG ou du time-slicing

Pilotes DRA pour Amazon EKS

Les pilotes DRA suivants sont couramment utilisés pour gérer des périphériques matériels spécialisés dans les clusters Amazon EKS.

pilote NVIDIA DRA: Le pilote NVIDIA DRA pour les GPU activés GitHub permet une allocation flexible et une configuration dynamique des GPU NVIDIA. Consultez Utilisez le pilote NVIDIA DRA ou le plug-in de périphérique sur Amazon EKS pour plus d'informations sur la gestion des GPU à l'aide du pilote NVIDIA DRA et À utiliser P6e-GB200 UltraServers avec Amazon EKS pour plus d'informations sur l'utilisation ComputeDomains des charges de travail Multi-Node NVLink (MNNVL) avec des instances EC2. Grace-Blackwell
pilote EFA DRA: Le pilote EFA DRA (DRANET activé GitHub) gère l'allocation des périphériques Elastic Fabric Adapter (EFA) grâce à une planification tenant compte de la topologie qui associe les interfaces EFA à leurs GPU topologiquement locaux ou à leurs périphériques Neuron, et prend en charge le partage de périphériques entre les Pods. Pour de plus amples informations, veuillez consulter Gérer les appareils EFA sur Amazon EKS.
pilote Neuron DRA: Le pilote Neuron DRA gère l'allocation des appareils AWS Trainium et AWS Inferentia2 grâce à une planification tenant compte de la topologie, à l'allocation de sous-ensembles d'appareils connectés et à une configuration logique NeuronCore (LNC), sans nécessiter d'extensions de planificateur personnalisées. Pour de plus amples informations, veuillez consulter Gérer les appareils Neuron sur Amazon EKS.

Plug-ins d'appareils pour Amazon EKS

Les plug-ins de périphériques suivants sont couramment utilisés pour gérer des périphériques matériels spécialisés dans les clusters Amazon EKS.

Plug-in pour appareil NVIDIA: Le plug-in de périphérique NVIDIA présente les GitHub GPU NVIDIA en tant que ressources nvidia.com/gpu étendues et suit l'état de santé des GPU.
Plug-in pour appareil EFA: Le plug-in EFA découvre tous les appareils EFA disponibles sur chaque nœud et annonce les appareils EFA en tant que ressources vpc.amazonaws.com/efa étendues.
Plug-in pour appareil Neuron: Le plug-in de l'appareil Neuron expose le matériel Neuron sous forme aws.amazon.com/neuroncore de ressources étendues. aws.amazon.com/neuron Il découvre les appareils Neuron disponibles sur chaque nœud, les présente comme des ressources allouables et gère leur cycle de vie.

Considérations

Avant d'utiliser les pilotes DRA sur Amazon EKS, prenez en compte les points suivants :

DRA est disponible sur Amazon EKS avec les versions 1.33 et supérieures de Kubernetes, mais il est recommandé pour les versions 1.34 et ultérieures de Kubernetes en raison d'un problème en amont de Kubernetes sur. https://github.com/kubernetes/kubernetes/issues/133920 GitHub Le plan de contrôle et les nœuds de votre cluster doivent exécuter une version de Kubernetes prenant en charge DRA.
DRA n'est actuellement pas compatible avec le mode automatique EKS.
DRA n'est actuellement pas compatible avec Karpenter lors de l'utilisation de capacités provisionnées dynamiquement. Vous devez utiliser le provisionnement de capacité statique dans Karpenter, ou des groupes de nœuds gérés par EKS ou des nœuds autogérés avec des pilotes DRA.
Les pilotes DRA et les plug-ins de périphériques pour le même type de périphérique ne doivent pas être exécutés simultanément sur le même nœud. Désinstallez le plug-in du périphérique avant d'installer le pilote DRA correspondant, ou déployez-le sur des nœuds distincts. L'exécution du pilote DRA et du plug-in de périphérique pour le même périphérique sur le même nœud peut entraîner un surabonnement silencieux des périphériques matériels sous-jacents.
DRA utilise des ressources d'API Kubernetes différentes (ResourceClaim,ResourceClaimTemplate,DeviceClass) de celles des plugins de périphériques (resource.limits,). resource.requests Vous pouvez utiliser DRA pour gérer les ressources étendues du plug-in de l'appareil sans modifier les spécifications de votre charge de travail. Pour plus d'informations sur les ressources étendues de DRA, consultez la documentation Kubernetes sur le site Web de Kubernetes.
Les pilotes DRA pour NVIDIA, EFA et Neuron sont compatibles à la fois avec les AMI EKS-optimized AL2023 et les AMI Bottlerocket. Si vous utilisez le pilote NVIDIA DRA avec Bottlerocket, désactivez le plug-in de périphérique NVIDIA inclus dans les variantes NVIDIA de Bottlerocket.
Les plugins de périphériques restent entièrement pris en charge pour toutes les versions de Kubernetes.

DRA ResourceClaim contre ResourceClaimTemplate

Lorsque vous utilisez DRA, vous demandez des appareils via ResourceClaim ou ResourceClaimTemplate des objets. Ces deux types de ressources ont des objectifs différents et ont des comportements différents tout au long de leur cycle de vie.

ResourceClaim

A ResourceClaim est un objet Kubernetes nommé que vous créez indépendamment de tout Pod. Vous le référencez dans une spécification de pod par son nom à l'aide du resourceClaimName champ. A ResourceClaim possède les caractéristiques suivantes :

Il doit exister dans le cluster avant la création de tout Pod qui le référence. Si la réclamation n'existe pas, le Pod reste en attente.
Il persiste jusqu'à ce que vous le supprimiez explicitement, que des Pods y fassent référence ou non.
Plusieurs pods peuvent référencer le même objetResourceClaim, ce qui permet de partager les appareils. Tous les Pods qui font référence à la même réclamation partagent l'accès aux mêmes appareils attribués et sont planifiés sur le même nœud.

Utilisez un ResourceClaim lorsque vous avez besoin de plusieurs Pods pour partager l'accès aux mêmes appareils, ou lorsque vous avez besoin d'une réclamation pour exister au-delà de la durée de vie d'un seul Pod.

ResourceClaimTemplate

A ResourceClaimTemplate définit un modèle que Kubernetes utilise pour générer automatiquement un modèle unique ResourceClaim pour chaque pod. Vous y faites référence dans une spécification de pod à l'aide du resourceClaimTemplateName champ. Le modèle ResourceClaimTemplate lui-même n'est lié à aucun Pod. Il s'agit d'un modèle réutilisable qui persiste indépendamment. A ResourceClaimTemplate possède les caractéristiques suivantes :

Kubernetes en crée un nouveau ResourceClaim pour chaque pod qui fait référence au modèle. Chaque Pod possède son propre ensemble d'appareils.
Chaque élément généré ResourceClaim est lié au cycle de vie du Pod qui a déclenché sa création. Lorsque le Pod est supprimé, le contenu généré associé ResourceClaim est également supprimé. Le Pods ResourceClaimTemplate lui-même n'est pas affecté et continue de générer de nouvelles réclamations pour les futurs Pods.

À utiliser ResourceClaimTemplate lorsque chaque pod d'une charge de travail a besoin de ses propres appareils dédiés avec des configurations similaires. Par exemple, utilisez un ResourceClaimTemplate for Pods dans un Job qui utilise une exécution parallèle où chaque pod a besoin de son propre GPU ou de ses propres périphériques EFA.

Le tableau suivant récapitule les différences entre ResourceClaim etResourceClaimTemplate.

Comportement	ResourceClaim	ResourceClaimTemplate
Création	Vous le créez manuellement avant que les pods ne le référencent	Kubernetes génère automatiquement une réclamation par Pod
Cycle de vie	Persiste jusqu'à ce que vous le supprimiez	Le modèle est conservé jusqu'à ce que vous le supprimiez. Chaque élément généré `ResourceClaim` est lié au Pod qui a déclenché sa création.
Partage d'appareils entre Pods	Pris en charge. Plusieurs pods peuvent faire référence à la même allégation.	Non pris en charge. Chaque Pod fait l'objet d'une réclamation distincte.
Champ de spécification du pod	`resourceClaimName`	`resourceClaimTemplateName`

Pour des exemples d'utilisation d'ResourceClaimobjets pour partager des appareils EFA entre des Pods, consultezPartagez des appareils EFA entre plusieurs Pods. Pour des exemples d'utilisation d'ResourceClaimTemplateobjets dotés d'une allocation tenant compte de la topologie, consultez. Topology-aware EFA et attribution des GPU/Neuron appareils

Rubriques

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Utilisation P6e-GB200 avec EKS

Appareils EFA