**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. 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. # 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](https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/) et aux [plug-ins d'appareils](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) 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` ou`aws.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)](https://kubernetes.io/docs/reference/using-api/cel/). + 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](https://github.com/kubernetes-sigs/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](device-management-efa.md). 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](https://github.com/kubernetes-sigs/nvidia-dra-driver-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, consultez[Utilisation P6e-GB200 UltraServers avec Amazon EKS](ml-eks-nvidia-ultraserver.md). ## 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](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/containers/tutorials/k8s-setup.html) 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](https://github.com/NVIDIA/k8s-device-plugin) 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.](https://github.com/kubernetes/kubernetes/issues/133920) 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-5004](https://github.com/kubernetes/enhancements/issues/5004)pour 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 chose`ResourceClaim`, 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` et`ResourceClaimTemplate`. | 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'`ResourceClaim`objets pour partager des appareils EFA entre des pods, voir[Partagez des appareils EFA entre plusieurs pods](device-management-efa.md#efa-dra-share). Pour des exemples d'utilisation d'`ResourceClaimTemplate`objets dotés d'une allocation adaptée à la topologie, consultez. [Topology-aware EFA et allocation GPU/Neuron d'appareils](device-management-efa.md#efa-dra-topology-aware) ## Rubriques + [Gérez les appareils EFA sur Amazon EKS](device-management-efa.md) + [Gérez les appareils Neuron sur Amazon EKS](device-management-neuron.md) + [Gérez les appareils GPU NVIDIA sur Amazon EKS](device-management-nvidia.md)