Allocation dynamique des ressources par rapport aux plug-ins d'appareils Pilotes DRA pour Amazon EKS Plug-ins d'appareil pour Amazon EKS Considérations DRA ResourceClaim c. 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 sur qui se trouve dans le volet droit de chaque page.

Gérez les appareils matériels sur Amazon EKS

Amazon EKS prend en charge deux mécanismes Kubernetes pour gérer les périphériques matériels spécialisés dans les clusters EKS : l'allocation dynamique des ressources (DRA) et les plug-ins d'appareils. 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, ainsi qu'à des périphériques réseau à hautes performances tels que Elastic Fabric Adapter (EFA). Il est recommandé d'utiliser les pilotes DRA pour les nouveaux déploiements avec les versions 1.34 et ultérieures de Kubernetes lorsque vous utilisez des groupes de nœuds gérés par EKS ou des nœuds autogérés, car le DRA fournit une sélection d'appareils plus riche, une planification adaptée à la topologie et des fonctionnalités de partage d'appareils qui ne sont pas possibles avec les plug-ins de périphériques.

Consultez la documentation Kubernetes relative à l'allocation dynamique des ressources et aux plug-ins d'appareils pour obtenir des informations générales sur ces deux fonctionnalités de Kubernetes.

Allocation dynamique des ressources par rapport aux plug-ins 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 comme des 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 de riches attributs de périphérique dans le planificateur Kubernetes par le biais d'objets. ResourceSlice Vous demandez des appareils utilisant des catégories ResourceClaim et ResourceClaimTemplate des objets qui font référence à des DeviceClass catégories.

Le DRA permet de :

Attribute-based sélection de périphériques à l'aide d'expressions CEL (Common Expression Language).
Topology-aware allocation qui garantit que les appareils sont colocalisé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.
Constraint-based planification qui aligne les différents types d'appareils

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 EFA DRA: Le pilote EFA DRA (DRANET) gère l'allocation des appareils Elastic Fabric Adapter (EFA) grâce à une planification tenant compte de la topologie qui associe les interfaces EFA à leurs GPU topologiquement locaux ou à leurs appareils Neuron, et prend en charge le partage de périphériques entre les pods. Pour de plus amples informations, veuillez consulter Gérez les appareils EFA sur Amazon EKS.
pilote Neuron DRA: Le pilote Neuron DRA gère l'allocation des appareils AWS Trainium et AWS Inferentia2 avec une planification basée sur la topologie, une allocation de sous-ensembles de périphériques connectés et une configuration logique NeuronCore (LNC), sans nécessiter d'extensions de planificateur personnalisées.
pilote NVIDIA DRA: Le pilote NVIDIA DRA pour GPU permet une allocation flexible et une reconfiguration dynamique des GPU NVIDIA, y compris la prise en charge des ComputeDomain ressources pour les charges de travail Multi-Node NVLink (MNNVL) sur les instances EC2. Grace-Blackwell Pour plus d'informations sur l'utilisation ComputeDomains avec les Grace-Blackwell instances EC2, consultezUtilisation P6e-GB200 UltraServers avec Amazon EKS.

Plug-ins d'appareil pour Amazon EKS

Les plug-ins d'appareil 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 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 annonce comme des ressources allouables et gère leur cycle de vie.
Plug-in pour appareil NVIDIA: Le plug-in pour appareil NVIDIA présente les GPU NVIDIA en tant que ressources nvidia.com/gpu étendues et suit l'état de santé des GPU.

Considérations

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

Le DRA est disponible sur Amazon EKS avec Kubernetes version 1.33 ou ultérieure, mais il est recommandé pour les versions 1.34 et ultérieures en raison d'un problème lié à Kubernetes en amont. Le plan de contrôle et les nœuds de votre cluster doivent exécuter une version de Kubernetes compatible avec le DRA.
Le DRA n'est actuellement pas compatible avec le calcul provisionné en mode automatique Karpenter ou EKS. Vous devez utiliser des groupes de nœuds gérés par EKS ou des nœuds autogérés dotés de pilotes DRA.
Les pilotes DRA et les plug-ins de périphérique pour le même type de périphérique ne doivent pas s'exécuter 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. Consultez Kubernetes en amont KEP-5004pour des mises à jour sur la compatibilité des pilotes DRA et des plug-ins de périphérique.
DRA utilise des ressources d'API Kubernetes (ResourceClaim,ResourceClaimTemplate,DeviceClass) différentes de celles des plug-ins d'appareils (resource.limits,). resource.requests La migration des plug-ins d'appareils vers le DRA nécessite de mettre à jour les spécifications de votre charge de travail.
Les plug-ins d'appareils restent entièrement pris en charge pour toutes les versions de Kubernetes. Si votre cluster exécute une version de Kubernetes antérieure à la version 1.34, ou si vous utilisez le mode automatique Karpenter ou EKS, continuez à utiliser des plug-ins pour appareils. Le pilote NVIDIA DRA n'est pas pris en charge sur Bottlerocket ; utilisez le plug-in de périphérique NVIDIA sur les nœuds Bottlerocket. Les pilotes EFA et Neuron DRA sont pris en charge sur Bottlerocket.

DRA ResourceClaim c. ResourceClaimTemplate

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

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 Pod par son nom en utilisant le resourceClaimName champ. A ResourceClaim présente les caractéristiques suivantes :

Il doit exister dans le cluster avant que tout Pod qui y fait référence ne soit créé. 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 faire référence à la même choseResourceClaim, ce qui permet le partage d'appareils. Tous les pods qui font référence à la même réclamation partagent l'accès aux mêmes appareils alloué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 le référencez dans une spécification Pod en utilisant le 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 présente les caractéristiques suivantes :

Kubernetes crée un nouveau modèle ResourceClaim pour chaque pod qui fait référence au modèle. Chaque Pod dispose 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 pod généré associé ResourceClaim est également supprimé. En ResourceClaimTemplate lui-même, cela n'est pas affecté et continue de générer de nouvelles réclamations pour les futurs Pods.

Utilisez un 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ésume les différences entre ResourceClaim etResourceClaimTemplate.

Comportement	ResourceClaim	ResourceClaimTemplate
Création	Vous le créez manuellement avant que Pods ne le référence	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 réclamation.	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, voirPartagez des appareils EFA entre plusieurs pods. Pour des exemples d'utilisation d'ResourceClaimTemplateobjets dotés d'une allocation adaptée à la topologie, consultez. Topology-aware EFA et allocation GPU/Neuron d'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

Gérer les appareils EFA