**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 EFA sur Amazon EKS
L'[Elastic Fabric Adapter](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html) (EFA) est un périphérique réseau pour les instances Amazon EC2 qui permet une communication inter-nœuds à hautes performances et un RDMA (Remote Direct Memory Access) pour les charges de travail liées à l'intelligence artificielle, à l'apprentissage automatique et au calcul haute performance (HPC). Amazon EKS prend en charge deux mécanismes pour gérer les appareils EFA dans les clusters EKS : le *pilote EFA Dynamic Resource Allocation (DRA) (DRANET)* et le *plug-in d'appareil EFA*.
Il est recommandé d'utiliser le pilote EFA DRA (DRANET) pour les nouveaux déploiements sur des clusters EKS exécutant Kubernetes version 1.34 ou ultérieure avec des groupes de nœuds gérés par EKS ou des groupes de nœuds autogérés. Le pilote EFA DRA vous permet de configurer une allocation adaptée à 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.
Le pilote EFA DRA n'est pas compatible avec le mode automatique Karpenter ou EKS. Utilisez le [plug-in de l'appareil EFA](#eks-efa-device-plugin) avec Karpenter et le mode automatique EKS. Le plug-in de périphérique EFA reste également pris en charge pour les groupes de nœuds gérés par EKS et les nœuds autogérés.
## Pilote EFA DRA ou plug-in de périphérique EFA
| Fonctionnalité | pilote EFA DRA | Plug-in pour appareil EFA |
| --- | --- | --- |
| Version minimale de Kubernetes | 1,34 | Toutes les versions de EKS-supported Kubernetes |
| Calcul EKS | Groupes de nœuds gérés, nœuds autogérés | Mode automatique EKS, Karpenter, groupes de nœuds gérés, nœuds autogérés |
| EKS-optimized AMI | AL2023 (NVIDIA, Neuron), Bottlerocket | AL2023 (NVIDIA, Neuron), Bottlerocket |
| Publicité sur les appareils | Attributs enrichis via `ResourceSlice` des objets, notamment le type de périphérique, la topologie et la localité PCIe | Nombre entier de ressources `vpc.amazonaws.com/efa` étendues |
| GPU-EFA affinité | DRA-native connaissance de la topologie | Prise en compte automatique de la topologie (AMI AL2023 uniquementEKS-optimized ) |
| Neuron-EFA affinité | DRA-native connaissance de la topologie | Prise en compte automatique de la topologie (AMI AL2023 uniquementEKS-optimized ) |
| Partage d'appareils | Plusieurs pods peuvent partager le même appareil EFA via des `ResourceClaim` références partagées | Non pris en charge. Chaque appareil EFA est exclusivement attribué à un Pod. |
## Création de nœuds EKS avec des interfaces EFA
Lorsque vous créez des nœuds EKS avec des interfaces EFA, les interfaces EFA sont attachées à l'instance lors du provisionnement de l'instance. Vous pouvez personnaliser la configuration EFA par appareil et utiliser des groupes de [placement avec Karpenter, des groupes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) de nœuds gérés par EKS ou des groupes de nœuds autogérés par EKS. Avec Karpenter, vous pouvez transmettre la configuration de chaque interface réseau via le`NodeClass`. Avec les groupes de nœuds gérés par EKS ou les nœuds autogérés, vous pouvez transmettre la configuration de chaque interface réseau à l'aide de [modèles de lancement](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html). La prise en charge du mode automatique EKS pour la configuration EFA par appareil et les groupes de placement sera bientôt disponible.
Lors de l'utilisation [`eksctl`](install-kubectl.md#eksctl-install-update)pour approvisionner des nœuds EKS avec le `efaEnabled` paramètre, toutes les interfaces sont configurées avec le type d'interface`EFA`, un groupe de EFA-specific sécurité est créé et le plug-in de périphérique EFA est installé sur le cluster. [Si vous devez personnaliser la configuration EFA par appareil lors de l'utilisation`eksctl`, il est recommandé d'utiliser le support de `eksctl pour les modèles de lancement.](https://docs.aws.amazon.com/eks/latest/eksctl/launch-template-support.html)
Les exemples suivants montrent comment configurer `NodeClass` et lancer des modèles avec des interfaces EFA. Cela est utile pour personnaliser les interfaces utilisées pour le trafic EFA par rapport au IP-based trafic standard. Pour plus d'informations sur le nombre d'interfaces EFA prises en charge par chaque type d'instance et sur la manière de les configurer pour une bande passante réseau maximale, consultez [Maximiser la bande passante réseau pour les types d' EFA-enabled instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html) dans le guide de l'*utilisateur Amazon EC2*.
## Karpenter
Chaque entrée de `networkInterfaces` spécifie un `networkCardIndex``deviceIndex`, et`interfaceType`. Il `interfaceType` peut s'agir `interface` d'interfaces réseau standard ou `efa-only` d'interfaces EFA dédiées au trafic RDMA et auxquelles aucune adresse IP n'est attribuée. Lorsqu'elle `networkInterfaces` est configurée, les instances lancées par le `NodePool` référençage `NodeClass` utilisent cette configuration, que les Pods demandent ou non des `vpc.amazonaws.com/efa` ressources.
Lorsque vous utilisez Karpenter sans le spécifier `networkInterfaces` dans votre`NodeClass`, les instances créées pour les requêtes Pods `vpc.amazonaws.com/efa` ont toutes les interfaces configurées avec le type `EFA` d'interface.
La `networkInterfaces` configuration pour `EC2NodeClass` a été ajoutée dans Karpenter v1.11. L'exemple suivant montre une instance `EC2NodeClass` configurée pour une P6-B200 instance avec 1 interface ENA et 8 EFA-only interfaces.
### Exemple de Karpenter EC2NodeClass avec des EFA-only interfaces pour P6-B200
```
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
name: efa-node-class
spec:
networkInterfaces:
- networkCardIndex: 0
deviceIndex: 0
interfaceType: interface
- networkCardIndex: 0
deviceIndex: 1
interfaceType: efa-only
- networkCardIndex: 1
deviceIndex: 0
interfaceType: efa-only
- networkCardIndex: 2
deviceIndex: 0
interfaceType: efa-only
- networkCardIndex: 3
deviceIndex: 0
interfaceType: efa-only
- networkCardIndex: 4
deviceIndex: 0
interfaceType: efa-only
- networkCardIndex: 5
deviceIndex: 0
interfaceType: efa-only
- networkCardIndex: 6
deviceIndex: 0
interfaceType: efa-only
- networkCardIndex: 7
deviceIndex: 0
interfaceType: efa-only
```
## Groupes de nœuds gérés par EKS et nœuds autogérés
Avec les groupes de nœuds gérés par EKS ou les nœuds autogérés, vous pouvez transmettre la configuration de chaque interface réseau à l'aide de [modèles de lancement](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html).
L'exemple suivant montre un modèle de lancement configuré pour une P6-B200 instance avec 1 interface ENA et 8 EFA-only interfaces. L'interface réseau principale (carte réseau 0, index de périphérique 0) utilise un `interface` type standard pour le trafic IP, tandis que les interfaces supplémentaires utilisent `efa-only` le trafic RDMA dédié. Ajustez le nombre d'`efa-only`interfaces en fonction de votre type d'instance. Pour connaître le nombre d'interfaces EFA prises en charge par chaque type d'instance, consultez [Maximiser la bande passante réseau pour les types d' EFA-enabled instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html) dans le guide de l'*utilisateur Amazon EC2*.
### Exemple de modèle de lancement avec EFA-only interfaces pour P6-B200
Remplacez ` security-group-id ` par vos valeurs. Le groupe de sécurité doit autoriser tout le trafic entrant et sortant à destination et en provenance de lui-même pour activer la fonctionnalité EFA OS-bypass . Pour plus d'informations, consultez [Étape 1 : Préparation d'un groupe EFA-enabled de sécurité](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-security) dans le guide de l'*utilisateur Amazon EC2*.
**Important**
Ne le spécifiez pas `SubnetId` dans le modèle de lancement lorsque vous utilisez des groupes de nœuds gérés par EKS. EKS exige que tous les sous-réseaux soient spécifiés via l'`CreateNodegroup`API et rejette les modèles de lancement qui incluent la configuration des sous-réseaux.
```
{
"LaunchTemplateName": "efa-launch-template",
"LaunchTemplateData": {
"InstanceType": "p6-b200.48xlarge",
"NetworkInterfaces": [
{
"NetworkCardIndex": 0,
"DeviceIndex": 0,
"InterfaceType": "interface",
"Groups": ["security-group-id"]
},
{
"NetworkCardIndex": 0,
"DeviceIndex": 1,
"InterfaceType": "efa-only",
"Groups": ["security-group-id"]
},
{
"NetworkCardIndex": 1,
"DeviceIndex": 0,
"InterfaceType": "efa-only",
"Groups": ["security-group-id"]
},
{
"NetworkCardIndex": 2,
"DeviceIndex": 0,
"InterfaceType": "efa-only",
"Groups": ["security-group-id"]
},
{
"NetworkCardIndex": 3,
"DeviceIndex": 0,
"InterfaceType": "efa-only",
"Groups": ["security-group-id"]
},
{
"NetworkCardIndex": 4,
"DeviceIndex": 0,
"InterfaceType": "efa-only",
"Groups": ["security-group-id"]
},
{
"NetworkCardIndex": 5,
"DeviceIndex": 0,
"InterfaceType": "efa-only",
"Groups": ["security-group-id"]
},
{
"NetworkCardIndex": 6,
"DeviceIndex": 0,
"InterfaceType": "efa-only",
"Groups": ["security-group-id"]
},
{
"NetworkCardIndex": 7,
"DeviceIndex": 0,
"InterfaceType": "efa-only",
"Groups": ["security-group-id"]
}
]
}
}
```
## Utilisation d' EKS-optimized AMI avec EFA
[Les AMI accélérées EKS-optimized AL2023 (NVIDIA et Neuron) et toutes les AMI Bottlerocket incluent les composants au niveau de l'hôte requis pour utiliser EFA, en particulier les composants installés par l'installateur aws-efa.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable) Les AMI EKS AL2023 et Bottlerocket **n'incluent pas** le pilote EFA DRA ni le plug-in de périphérique EFA, et ceux-ci doivent être installés séparément sur votre cluster avant de déployer des charges de travail.
## Conservation de l'allocation des adresses IP
EFA-enabled instances telles que `p5.48xlarge` et prenant `p6-b200.48xlarge` en charge de nombreuses interfaces réseau. Par défaut, le CNI Amazon VPC alloue des adresses IP à tous les ENI IP-enabled connectés, qui peuvent consommer un grand nombre d'adresses IP de votre sous-réseau même lorsque ces adresses ne sont pas activement utilisées par les Pods. Sur les instances comportant des dizaines d'interfaces réseau, cela peut rapidement épuiser l'espace IP disponible de votre sous-réseau.
Pour réduire la consommation d'adresses IP sur EFA-enabled les nœuds, configurez vos interfaces réseau pour qu'elles soient utilisées `efa-only` pour toutes les interfaces sauf l'interface principale. EFA-only les interfaces sont dédiées au trafic RDMA et n'ont pas d'adresse IP attribuée, elles ne consomment donc pas les adresses de votre sous-réseau. Pour des exemples de configurations, voir [Karpenter](#eks-efa-auto-karpenter) et[Groupes de nœuds gérés par EKS et nœuds autogérés](#eks-efa-mng-self-managed). Pour connaître la disposition d'interface recommandée pour chaque type d'instance, consultez [Maximiser la bande passante réseau pour les types d' EFA-enabled instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html) dans le guide de l'*utilisateur Amazon EC2*.
Outre l'utilisation d'`efa-only`interfaces, vous pouvez configurer le CNI Amazon VPC pour limiter le nombre d'adresses IP et d'ENI chaudes (préallouées). Par défaut, le VPC CNI préalloue un pool chaud d'ENI et d'adresses IP pour accélérer le démarrage du Pod, mais sur les grandes instances, cela peut réserver des centaines d'adresses IP inutilisées. Définissez les variables d'`WARM_ENI_TARGET`environnement `WARM_IP_TARGET` et sur le `aws-node` DaemonSet pour contrôler le nombre d'adresses IP et d'ENI de rechange gérées par le CNI. Pour plus d'informations sur ces paramètres, consultez les [meilleures pratiques Amazon VPC CNI](https://docs.aws.amazon.com/eks/latest/best-practices/vpc-cni.html#_overview).
**Note**
Les `WARM_IP_TARGET` paramètres `WARM_ENI_TARGET` et s'appliquent à l'échelle du cluster et s'appliquent à tous les nœuds gérés par le VPC CNI. Il n'existe actuellement aucun moyen de définir des valeurs différentes par groupe de nœuds ou par type d'instance. Si vous avez besoin d'un contrôle plus précis de ces paramètres, faites-nous part de vos commentaires sur le problème \#1834 de [containers-roadmap](https://github.com/aws/containers-roadmap/issues/1834).
## Installation du pilote EFA DRA (DRANET)
Le pilote EFA DRA est intégré au projet [DRANET](https://github.com/kubernetes-sigs/dranet) en amont, qui fournit une gestion des périphériques réseau adaptée au cloud pour Kubernetes DRA. *Le pilote EFA DRA* et *DRANET* sont utilisés de manière interchangeable dans cette documentation et font référence au même outil.
Le pilote EFA DRA présente les appareils EFA sous forme `ResourceSlice` d'objets portant le nom `dra.net` et le `DeviceClass` nom `efa.networking.k8s.aws` du pilote. Le pilote EFA DRA s'exécute comme un DaemonSet sur chaque nœud et découvre automatiquement les périphériques EFA.
### Conditions préalables
+ Un cluster Amazon EKS exécutant Kubernetes version 1.34 ou ultérieure avec des groupes de nœuds gérés par EKS ou des groupes de nœuds autogérés.
+ Nœuds dotés de types d'instances EFA-enabled Amazon EC2. Pour obtenir la liste des types d'instances pris en charge, consultez la section [Types d'instances pris en charge](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html#efa-instance-types) dans le *guide de l'utilisateur Amazon EC2*.
+ Nœuds sur lesquels des composants au niveau de l'hôte sont installés pour EFA, voir [Installer le logiciel EFA](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable) pour plus d'informations. Les AMI NVIDIA et Neuron EKS-optimized AL2023, ainsi que les AMI Bottlerocket incluent les composants EFA au niveau de l'hôte.
+ Helm installé dans votre environnement de ligne de commande, consultez les instructions de configuration de Helm pour plus d’informations.[Déployez des applications avec Helm sur Amazon EKS](helm.md)
+ `kubectl`configuré pour communiquer avec votre cluster, voir [Installer ou mettre à jour `kubectl`](install-kubectl.md#kubectl-install-update) pour plus d'informations.
### Procédure
**Important**
N'installez pas le pilote EFA DRA sur les nœuds sur lesquels le plug-in du périphérique EFA est en cours d'exécution. Les deux mécanismes ne peuvent pas coexister sur le même nœud. Consultez Kubernetes [KEP-5004](https://github.com/kubernetes/enhancements/issues/5004)en amont pour les mises à jour.
1. Ajoutez le référentiel de cartes EKS Helm.
```
helm repo add eks https://aws.github.io/eks-charts
```
1. Mettez à jour votre dépôt Helm local.
```
helm repo update
```
1. Installez le pilote EFA DRA sur votre cluster à l'aide de Helm. Le pilote EFA DRA détecte automatiquement qu'il s'exécute sur les instances EC2 via le service de métadonnées d'instance (IMDS) et permet la découverte des périphériques EFA. Le pilote EFA DRA est déployé DaemonSet en tant que fichier dans l'espace de `kube-system` noms par défaut. Consultez le fichier Helm values.yaml dans le [ GitHub référentiel de graphiques EKS Helm](https://github.com/aws/eks-charts/tree/master/stable/aws-dranet) pour connaître les paramètres configurables.
```
helm install aws-dranet eks/aws-dranet --namespace kube-system
```
1. Vérifiez que le DRANET DaemonSet est en cours d'exécution.
```
kubectl get daemonset -n kube-system aws-dranet
```
```
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
aws-dranet 2 2 2 2 2 60s
```
1. Vérifiez que le `DeviceClass` a été créé.
```
kubectl get deviceclass
```
```
NAME AGE
efa.networking.k8s.aws 60s
```
1. Vérifiez que `ResourceSlice` les objets sont annoncés pour vos nœuds.
```
kubectl get resourceslices --field-selector spec.driver=dra.net
```
Si vous rencontrez des erreurs lors des étapes ci-dessus, vous pouvez consulter les journaux de DRANET à l'aide de la commande suivante.
```
kubectl logs -n kube-system -l app=aws-dranet
```
1. Pour demander des appareils EFA à l'aide du pilote DRA, créez un `ResourceClaim` ou `ResourceClaimTemplate` qui fait référence à l'EFA `DeviceClass` et référencez-le dans les spécifications de votre Pod. L'exemple suivant demande un seul appareil EFA.
```
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
name: single-efa-claim
spec:
spec:
devices:
requests:
- name: efa
exactly:
deviceClassName: efa.networking.k8s.aws
count: 1
---
apiVersion: v1
kind: Pod
metadata:
name: efa-workload
spec:
containers:
- name: app
...
resources:
claims:
- name: efa-device
resourceClaims:
- name: efa-device
resourceClaimTemplateName: single-efa-claim
```
## Topology-aware EFA et allocation GPU/Neuron d'appareils
Le pilote EFA DRA prend en charge l'allocation tenant compte de la topologie qui associe les interfaces EFA aux GPU ou aux périphériques Neuron sur la même racine PCIe. Utilisez la `matchAttribute` contrainte pour aligner les allocations EFA et GPU ou Neuron. Pour utiliser cette fonctionnalité, vous devez également utiliser les pilotes NVIDIA ou Neuron DRA. Pour plus d’informations, consultez [Gérez les appareils GPU NVIDIA sur Amazon EKS](device-management-nvidia.md) et [Gérez les appareils Neuron sur Amazon EKS](device-management-neuron.md).
L'exemple suivant demande 1 interface EFA alignée sur 1 GPU NVIDIA :
```
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
name: aligned-efa-nvidia
spec:
spec:
devices:
requests:
- name: 1-efa
exactly:
deviceClassName: efa.networking.k8s.aws
count: 1
- name: 1-gpu
exactly:
deviceClassName: gpu.nvidia.com
count: 1
constraints:
- requests: ["1-gpu", "1-efa"]
matchAttribute: "resource.kubernetes.io/pcieRoot"
```
L'exemple suivant demande 4 interfaces EFA alignées sur 4 appareils Neuron :
```
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
name: aligned-efa-neuron
spec:
spec:
devices:
requests:
- name: 4-neurons
exactly:
deviceClassName: neuron.aws.com
count: 4
- name: 4-efas
exactly:
deviceClassName: efa.networking.k8s.aws
count: 4
constraints:
- requests: ["4-neurons", "4-efas"]
matchAttribute: "resource.aws.com/devicegroup4_id"
```
Le numéro figurant dans le nom de `devicegroup` l'attribut correspond au nombre de dispositifs Neuron dans le groupe topologique connecté. Par exemple, `resource.aws.com/devicegroup1_id` identifie un seul appareil Neuron, `resource.aws.com/devicegroup4_id` identifie un groupe de 4 appareils connectés `resource.aws.com/devicegroup8_id` et `resource.aws.com/devicegroup16_id` identifie des groupes de 8 et 16 appareils connectés respectivement. Choisissez `matchAttribute` celui qui correspond à l'appareil indiqué `count` dans votre demande afin que les appareils Neuron et les interfaces EFA alloués appartiennent au même groupe topologique connecté. Pour plus d'informations sur ces attributs, consultez la [documentation du pilote Neuron DRA](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/containers/neuron-dra.html).
Vous pouvez l'utiliser `allocationMode` pour simplifier la façon dont les appareils EFA sont alloués aux accélérateurs GPU ou Neuron alignés. Le `allocationMode` champ prend en charge deux valeurs : `ExactCount` (par défaut) demande un nombre spécifique d'appareils spécifié par`count`, et `All` demande tous les appareils correspondants dans un pool. Par exemple, sur les `p5.48xlarge` instances, quatre périphériques EFA partagent la même racine PCIe avec un seul GPU. Pour attribuer ces groupes d'appareils EFA avec des GPU alignés, même si vous ne connaissez pas le mappage exact des EFA-GPU appareils ni le nombre d'appareils EFA alignés, vous pouvez configurer votre compte `ResourceClaimTemplate` avec `allocationMode: All` pour les appareils EFA.
```
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
name: aligned-all-efa-one-nvidia
spec:
spec:
devices:
requests:
- name: all-efas
exactly:
deviceClassName: efa.networking.k8s.aws
allocationMode: All
- name: one-gpu
exactly:
deviceClassName: gpu.nvidia.com
allocationMode: ExactCount
count: 1
constraints:
- requests: ["all-efas", "one-gpu"]
matchAttribute: "resource.kubernetes.io/pcieRoot"
```
## Partagez des appareils EFA entre plusieurs pods
Le pilote EFA DRA prend en charge le partage de périphériques EFA entre plusieurs pods à l'aide d'un`ResourceClaim`. Contrairement à a`ResourceClaimTemplate`, qui génère une réclamation distincte pour chaque pod, a `ResourceClaim` est un objet nommé que vous créez indépendamment et que vous référencez à partir de plusieurs pods. Tous les pods qui font référence au même accès `ResourceClaim` partagent l'accès aux mêmes appareils EFA alloués et sont planifiés sur le même nœud où ces appareils sont disponibles.
Pour partager des appareils EFA entre des pods, créez un `ResourceClaim` qui demande les appareils EFA, puis référencez cette réclamation par son nom dans `resourceClaims` le champ de chaque pod en utilisant`resourceClaimName`. Le `ResourceClaim` doit exister dans le cluster avant que les pods qui le référencent ne soient créés. Si `ResourceClaim` aucune référence n'existe, les pods restent en attente jusqu'à ce que la réclamation soit créée.
L'exemple suivant crée un `ResourceClaim` qui demande 4 appareils EFA et deux pods partageant l'accès à ces appareils.
1. Créez la `ResourceClaim`.
```
apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
name: shared-efa
spec:
devices:
requests:
- name: efa
exactly:
deviceClassName: efa.networking.k8s.aws
count: 4
```
1. `ResourceClaim`Référencez le nom de chaque Pod qui doit accéder aux appareils EFA. Chaque Pod est utilisé `resourceClaimName` pour faire référence à la réclamation existante au lieu de`resourceClaimTemplateName`.
```
apiVersion: v1
kind: Pod
metadata:
name: training-worker
spec:
containers:
- name: worker
image: my-training-image
resources:
claims:
- name: efa-devices
resourceClaims:
- name: efa-devices
resourceClaimName: shared-efa
---
apiVersion: v1
kind: Pod
metadata:
name: training-monitor
spec:
containers:
- name: monitor
image: my-monitor-image
resources:
claims:
- name: efa-devices
resourceClaims:
- name: efa-devices
resourceClaimName: shared-efa
```
Les deux pods font référence à la même chose `shared-efa` `ResourceClaim` et sont planifiés sur le nœud où ces appareils EFA sont alloués. Le `ResourceClaim` cycle de vie est indépendant des pods : il persiste jusqu'à ce que vous les supprimiez, même si tous les pods qui y font référence sont supprimés.
## Installez le plugin pour appareil EFA Kubernetes
Le plugin pour appareils EFA Kubernetes présente les appareils EFA en tant que ressources étendues. `vpc.amazonaws.com/efa` Vous demandez des appareils EFA dans les demandes de ressources et les limites des conteneurs. Pour une présentation complète de la configuration d'EFA avec des charges de travail de formation, voir. [Exécuter un entraînement de machine learning sur Amazon EKS avec Elastic Fabric Adapter](node-efa.md)
**Important**
Topology-aligned l'allocation de GPU NVIDIA ou d'appareils Neuron dotés d'interfaces EFA se fait automatiquement lors de l'utilisation des AMI accélérées EKS-optimized AL2023. Cet alignement automatique ne se produit pas lors de l'utilisation des AMI Bottlerocket ou des EKS-optimized AMI personnalisées. Si vous avez besoin d'un accélérateur aligné sur la topologie et d'une allocation de périphériques EFA avec Bottlerocket ou d'AMI personnalisées, utilisez le pilote EFA DRA et le pilote Neuron DRA correspondant. Le pilote NVIDIA DRA n'est pas pris en charge sur Bottlerocket. Pour de plus amples informations, veuillez consulter [Topology-aware EFA et allocation GPU/Neuron d'appareils](#efa-dra-topology-aware).
**Important**
À partir de NVIDIA `k8s-device-plugin` v0.19.0, l'`--mofed-enabled`indicateur prend par défaut la valeur`true`, ce qui permet au plug-in de périphérique NVIDIA de monter tous les `/dev/infiniband/uverbs*` appareils dans des conteneurs demandant des GPU. Cela entre en conflit avec le plug-in de périphérique EFA, qui doit être le composant gérant l'allocation des appareils EFA sur`/dev/infiniband`. Si vous utilisez des groupes de nœuds gérés par EKS ou des nœuds autogérés avec le plug-in d'appareil NVIDIA, vous devez explicitement désactiver MOFED. Pour obtenir des instructions, veuillez consulter [Installez le plugin pour appareil NVIDIA Kubernetes](device-management-nvidia.md#nvidia-device-plugin).
Le mode automatique EKS n'active pas le mode MOFED par défaut et n'est pas concerné par ce problème.
### Conditions préalables
+ Un cluster Amazon EKS.
+ Nœuds dotés de types d'instances EFA-enabled Amazon EC2. Pour obtenir la liste des types d'instances pris en charge, consultez la section [Types d'instances pris en charge](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html#efa-instance-types) dans le *guide de l'utilisateur Amazon EC2*.
+ Nœuds sur lesquels des composants au niveau de l'hôte sont installés pour EFA, voir [Installer le logiciel EFA](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable) pour plus d'informations. Les AMI NVIDIA et Neuron EKS-optimized AL2023, ainsi que les AMI Bottlerocket incluent les composants EFA au niveau de l'hôte.
+ Helm installé dans votre environnement de ligne de commande, consultez les instructions de configuration de Helm pour plus d’informations.[Déployez des applications avec Helm sur Amazon EKS](helm.md)
+ `kubectl`configuré pour communiquer avec votre cluster, voir [Installer ou mettre à jour `kubectl`](install-kubectl.md#kubectl-install-update) pour plus d'informations.
### Procédure
1. Ajoutez le référentiel de cartes EKS Helm.
```
helm repo add eks https://aws.github.io/eks-charts
```
1. Mettez à jour votre dépôt Helm local.
```
helm repo update
```
1. Installez le plug-in de l'appareil EFA.
```
helm install efa eks/aws-efa-k8s-device-plugin -n kube-system
```
1. Vérifiez que le plug-in de l'appareil EFA DaemonSet est en cours d'exécution.
```
kubectl get daemonset -n kube-system efa-aws-efa-k8s-device-plugin
```
```
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
efa-aws-efa-k8s-device-plugin 2 2 2 2 2 60s
```
1. Vérifiez que vos nœuds disposent de ressources EFA allouables.
```
kubectl get nodes "-o=custom-columns=NAME:.metadata.name,EFA:.status.allocatable.vpc\.amazonaws\.com/efa"
```
```
NAME EFA
ip-192-168-11-225.us-west-2.compute.internal 4
ip-192-168-24-96.us-west-2.compute.internal 4
```
1. Pour demander des appareils EFA à l'aide du plug-in d'appareil, spécifiez la `vpc.amazonaws.com/efa` ressource dans les demandes de ressources et les limites de votre conteneur.
```
apiVersion: v1
kind: Pod
metadata:
name: efa-workload
spec:
containers:
- name: app
...
resources:
limits:
vpc.amazonaws.com/efa: 4
hugepages-2Mi: ...
requests:
vpc.amazonaws.com/efa: 4
hugepages-2Mi: ...
```