**Contribuisci a migliorare questa pagina**
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Per contribuire a questa guida per l'utente, scegli il GitHub link **Modifica questa pagina** nel riquadro destro di ogni pagina.
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Gestisci i dispositivi EFA su Amazon EKS
[Elastic Fabric Adapter](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html) (EFA) è un dispositivo di rete per istanze Amazon EC2 che consente comunicazioni tra nodi ad alte prestazioni e RDMA (Remote Direct Memory Access) per carichi di lavoro di intelligenza artificiale, machine learning e High Performance Computing (HPC). *Amazon EKS supporta due meccanismi per la gestione dei dispositivi EFA nei cluster EKS: il *driver EFA Dynamic Resource Allocation (DRA) (DRANET)* e il plug-in per dispositivi EFA.*
Si consiglia di utilizzare il driver EFA DRA (DRANET) per nuove implementazioni su cluster EKS che eseguono Kubernetes versione 1.34 o successiva con gruppi di nodi gestiti EKS o gruppi di nodi autogestiti. Il driver EFA DRA consente di configurare un'allocazione basata sulla topologia che associa le interfacce EFA alle GPU topologicamente locali o ai dispositivi Neuron e supporta la condivisione dei dispositivi tra i Pod.
Il driver EFA DRA non è supportato con Karpenter o EKS Auto Mode. Utilizza il [plug-in del dispositivo EFA](#eks-efa-device-plugin) con Karpenter ed EKS Auto Mode. Il plug-in del dispositivo EFA rimane supportato anche per i gruppi di nodi gestiti da EKS e i nodi autogestiti.
## Driver EFA DRA e plug-in per dispositivi EFA
| Funzionalità | Driver EFA DRA | Plugin per dispositivi EFA |
| --- | --- | --- |
| Versione minima di Kubernetes | 1.34 | Tutte le versioni di EKS-supported Kubernetes |
| EKS Compute | Gruppi di nodi gestiti, nodi autogestiti | EKS Auto Mode, Karpenter, gruppi di nodi gestiti, nodi autogestiti |
| EKS-optimized AMI | AL2023 (NVIDIA, Neuron), porta bottiglia | AL2023 (NVIDIA, Neuron), porta bottiglia |
| Pubblicità sul dispositivo | Attributi completi tramite `ResourceSlice` oggetti, tra cui tipo di dispositivo, topologia e località PCIe | Numero intero di risorse estese `vpc.amazonaws.com/efa` |
| GPU-EFA affinità | DRA-native consapevolezza della topologia | Riconoscimento automatico della topologia (solo AMI AL2023EKS-optimized ) |
| Neuron-EFA affinità | DRA-native consapevolezza della topologia | Riconoscimento automatico della topologia (solo AMI AL2023EKS-optimized ) |
| Condivisione dei dispositivi | Più Pod possono condividere lo stesso dispositivo EFA tramite riferimenti condivisi `ResourceClaim` | Non supportato. Ogni dispositivo EFA è assegnato esclusivamente a un Pod. |
## Creazione di nodi EKS con interfacce EFA
Quando si creano nodi EKS con interfacce EFA, le interfacce EFA vengono collegate all'istanza durante il provisioning dell'istanza. È possibile personalizzare la configurazione EFA per dispositivo e utilizzare i gruppi di [collocamento con Karpenter, i gruppi di nodi gestiti da EKS o i gruppi](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) di nodi autogestiti da EKS. Con Karpenter, puoi passare la configurazione per ogni interfaccia di rete tramite. `NodeClass` [Con i gruppi di nodi gestiti da EKS o i nodi autogestiti, è possibile passare la configurazione per ogni interfaccia di rete con modelli di avvio.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html) Il supporto EKS Auto Mode per i gruppi di configurazione e posizionamento EFA per dispositivo sarà presto disponibile.
Quando viene utilizzato [`eksctl`](install-kubectl.md#eksctl-install-update)per il provisioning dei nodi EKS con l'`efaEnabled`impostazione, tutte le interfacce sono configurate in base al tipo di interfaccia`EFA`, viene creato un gruppo di EFA-specific sicurezza e il plug-in del dispositivo EFA viene installato sul cluster. [Se è necessario personalizzare la configurazione EFA per dispositivo durante l'utilizzo`eksctl`, si consiglia di utilizzare il supporto di `eksctl per i modelli di avvio.](https://docs.aws.amazon.com/eks/latest/eksctl/launch-template-support.html)
Gli esempi seguenti mostrano come configurare `NodeClass` e lanciare modelli con interfacce EFA. Ciò è utile per personalizzare le interfacce utilizzate per il traffico EFA rispetto a quelle standard. IP-based *Per informazioni sul numero di interfacce EFA supportate da ciascun tipo di istanza e su come configurarle per la massima larghezza di banda di rete, consulta [Massimizza la larghezza di banda di rete per i tipi di EFA-enabled istanza nella Guida per l'](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html)utente di Amazon EC2.*
## Karpenter
Ogni voce specifica un, e. `networkInterfaces` `networkCardIndex` `deviceIndex` `interfaceType` `interfaceType`Possono essere interfacce `interface` di rete standard o interfacce EFA `efa-only` dedicate al traffico RDMA e a cui non sono assegnati indirizzi IP. Una volta `networkInterfaces` configurata, le istanze avviate dal `NodePool` referenziamento `NodeClass` utilizzano questa configurazione indipendentemente dal fatto che i Pod richiedano risorse. `vpc.amazonaws.com/efa`
Quando usi Karpenter senza specificare `networkInterfaces` nel tuo`NodeClass`, le istanze create per la richiesta `vpc.amazonaws.com/efa` dei Pods hanno tutte le interfacce configurate con il tipo di interfaccia. `EFA`
La `networkInterfaces` configurazione per è stata aggiunta in Karpenter v1.11. `EC2NodeClass` L'esempio seguente mostra una `EC2NodeClass` configurazione per un' P6-B200 istanza con 1 interfaccia ENA e 8 interfacce. EFA-only
### Esempio Karpenter con interfacce EC2NodeClass per EFA-only 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
```
## Gruppi di nodi gestiti da EKS e nodi autogestiti
Con i gruppi di nodi gestiti o i nodi autogestiti EKS, è possibile passare la configurazione per ogni interfaccia di rete con modelli di [avvio](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html).
L'esempio seguente mostra un modello di lancio configurato per un' P6-B200 istanza con 1 interfaccia ENA e 8 EFA-only interfacce. L'interfaccia di rete principale (scheda di rete 0, indice del dispositivo 0) utilizza un `interface` tipo standard per il traffico IP, mentre le interfacce aggiuntive lo utilizzano `efa-only` per il traffico RDMA dedicato. Regola il numero di `efa-only` interfacce in base al tipo di istanza. *Per il numero di interfacce EFA supportate da ogni tipo di istanza, consulta [Massimizza la larghezza di banda di rete per i tipi di EFA-enabled istanza nella Guida per l'utente di](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html) Amazon EC2.*
### Esempio di modello di lancio con interfacce per EFA-only P6-B200
Sostituisci ` security-group-id ` con i tuoi valori. Il gruppo di sicurezza deve consentire tutto il traffico in entrata e in uscita da e verso se stesso per abilitare la funzionalità EFA OS-bypass . Per ulteriori informazioni, consulta la [Fase 1: Preparare un gruppo EFA-enabled di sicurezza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-security) nella Guida per l'*utente di Amazon EC2*.
**Importante**
Non specificare `SubnetId` nel modello di lancio quando si utilizzano gruppi di nodi gestiti da EKS. EKS richiede che tutte le sottoreti siano specificate tramite l'`CreateNodegroup`API e rifiuta i modelli di avvio che includono la configurazione delle sottoreti.
```
{
"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"]
}
]
}
}
```
## Utilizzo delle AMI con EFA EKS-optimized
[Le AMI accelerate EKS-optimized AL2023 (NVIDIA e Neuron) e tutte le AMI Bottlerocket includono i componenti a livello di host necessari per utilizzare EFA, in particolare i componenti installati dall'aws-efa-installer.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable) Le AMI EKS AL2023 e Bottlerocket **non includono** il driver EFA DRA o il plug-in del dispositivo EFA e devono essere installate separatamente sul cluster prima di distribuire i carichi di lavoro.
## Conservazione dell'allocazione degli indirizzi IP
EFA-enabled istanze come `p5.48xlarge` e `p6-b200.48xlarge` supportano molte interfacce di rete. Per impostazione predefinita, il CNI di Amazon VPC alloca gli indirizzi IP tra tutti gli ENI IP-enabled collegati, il che può consumare un gran numero di indirizzi IP dalla sottorete anche quando tali indirizzi non vengono utilizzati attivamente dai Pod. Nelle istanze con dozzine di interfacce di rete, ciò può esaurire rapidamente lo spazio IP disponibile della sottorete.
Per ridurre il consumo di indirizzi IP sui EFA-enabled nodi, configura le interfacce di rete in modo che vengano utilizzate `efa-only` per tutte le interfacce tranne quella principale. EFA-only le interfacce sono dedicate al traffico RDMA e non hanno indirizzi IP assegnati, quindi non utilizzano indirizzi dalla sottorete. Per esempio configurazioni, vedere e. [Karpenter](#eks-efa-auto-karpenter) [Gruppi di nodi gestiti da EKS e nodi autogestiti](#eks-efa-mng-self-managed) Per il layout di interfaccia consigliato per ogni tipo di istanza, consulta [Massimizza la larghezza di banda di rete per i tipi di EFA-enabled istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html) nella *Amazon EC2* User Guide.
Oltre a utilizzare le `efa-only` interfacce, puoi configurare Amazon VPC CNI per limitare il numero di indirizzi IP ed ENI caldi (preallocati). Per impostazione predefinita, il VPC CNI prealloca un pool caldo di ENI e indirizzi IP per un avvio più rapido dei Pod, ma su istanze di grandi dimensioni può riservare centinaia di indirizzi IP inutilizzati. Imposta le variabili `WARM_IP_TARGET` e di `WARM_ENI_TARGET` ambiente `aws-node` DaemonSet per controllare il numero di indirizzi IP ed ENI di riserva gestiti dal CNI. Per ulteriori informazioni su queste impostazioni, consulta le best practice [CNI di Amazon VPC](https://docs.aws.amazon.com/eks/latest/best-practices/vpc-cni.html#_overview).
**Nota**
Le `WARM_IP_TARGET` impostazioni `WARM_ENI_TARGET` e sono a livello di cluster e si applicano a tutti i nodi gestiti dal VPC CNI. Al momento non è possibile impostare valori diversi per gruppo di nodi o tipo di istanza. Se hai bisogno di un controllo più granulare di queste impostazioni, fornisci un feedback sul numero \#1834 di [containers-roadmap](https://github.com/aws/containers-roadmap/issues/1834).
## Installa il driver EFA DRA (DRANET)
Il driver EFA DRA è integrato nel progetto UPstream [DRANET](https://github.com/kubernetes-sigs/dranet), che fornisce una gestione dei dispositivi di rete basata sul cloud per Kubernetes DRA. Il *driver EFA DRA e *DRANET* sono usati in modo intercambiabile in questa documentazione* e fanno riferimento allo stesso strumento.
Il driver EFA DRA pubblicizza i dispositivi EFA come oggetti con il nome e il nome del driver. `ResourceSlice` `dra.net` `DeviceClass` `efa.networking.k8s.aws` Il driver EFA DRA viene eseguito come uno DaemonSet su ciascun nodo e rileva automaticamente i dispositivi EFA.
### Prerequisiti
+ Un cluster Amazon EKS che esegue Kubernetes versione 1.34 o successiva con gruppi di nodi gestiti da EKS o gruppi di nodi autogestiti.
+ Nodi con EFA-enabled tipi di istanze Amazon EC2. Per un elenco dei tipi di istanze supportati, consulta Tipi [di istanze supportati](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html#efa-instance-types) nella Guida per l'*utente di Amazon EC2*.
+ Nodi con componenti a livello di host installati per EFA, consulta [Installare il software EFA](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable) per ulteriori informazioni. Le AMI NVIDIA e Neuron EKS-optimized AL2023 e le AMI Bottlerocket includono i componenti a livello di host EFA.
+ Helm è installato nell’ambiente a riga di comando, consulta le [istruzioni di configurazione di Helm](helm.md) per ulteriori informazioni.
+ `kubectl`configurato per comunicare con il cluster, vedi per ulteriori informazioni. [Installazione o aggiornamento di `kubectl`](install-kubectl.md#kubectl-install-update)
### Procedura
**Importante**
Non installare il driver EFA DRA sui nodi in cui è in esecuzione il plug-in del dispositivo EFA. I due meccanismi non possono coesistere sullo stesso nodo. Vedi upstream [KEP-5004](https://github.com/kubernetes/enhancements/issues/5004)Kubernetes per gli aggiornamenti.
1. Aggiungi l'archivio cartografico EKS Helm.
```
helm repo add eks https://aws.github.io/eks-charts
```
1. Aggiorna il tuo archivio Helm locale.
```
helm repo update
```
1. Installa il driver EFA DRA sul tuo cluster utilizzando Helm. Il driver EFA DRA rileva automaticamente che è in esecuzione su istanze EC2 tramite l'Instance Metadata Service (IMDS) e abilita il rilevamento dei dispositivi EFA. Per impostazione predefinita, il driver EFA DRA viene distribuito come file nel namespace. DaemonSet `kube-system` [Per i parametri configurabili, consulta Helm values.yaml nell'archivio di grafici EKS Helm. GitHub ](https://github.com/aws/eks-charts/tree/master/stable/aws-dranet)
```
helm install aws-dranet eks/aws-dranet --namespace kube-system
```
1. Verifica che DaemonSet DRANET sia in esecuzione.
```
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. Verifica che sia `DeviceClass` stato creato.
```
kubectl get deviceclass
```
```
NAME AGE
efa.networking.k8s.aws 60s
```
1. Verifica che `ResourceSlice` gli oggetti siano pubblicizzati per i tuoi nodi.
```
kubectl get resourceslices --field-selector spec.driver=dra.net
```
Se riscontri errori nei passaggi precedenti, puoi controllare i log di DRANET con il seguente comando.
```
kubectl logs -n kube-system -l app=aws-dranet
```
1. Per richiedere dispositivi EFA utilizzando il driver DRA, create un `ResourceClaim` or `ResourceClaimTemplate` che faccia riferimento all'EFA `DeviceClass` e fate riferimento ad esso nelle specifiche del vostro Pod. L'esempio seguente richiede un singolo dispositivo 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 e GPU/Neuron allocazione dei dispositivi
Il driver EFA DRA supporta l'allocazione basata sulla topologia che associa le interfacce EFA alle GPU o ai dispositivi Neuron sulla stessa radice PCIe. Usa il vincolo per allineare le allocazioni dei dispositivi EFA e GPU `matchAttribute` o Neuron. Per utilizzare questa funzionalità, è necessario utilizzare anche i driver NVIDIA o Neuron DRA. Per ulteriori informazioni, consultare [Gestisci i dispositivi GPU NVIDIA su Amazon EKS](device-management-nvidia.md) e [Gestisci i dispositivi Neuron su Amazon EKS](device-management-neuron.md).
L'esempio seguente richiede 1 interfaccia EFA allineata con 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'esempio seguente richiede 4 interfacce EFA allineate con 4 dispositivi 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"
```
Il numero nel nome dell'`devicegroup`attributo corrisponde al numero di dispositivi Neuron nel gruppo di topologia connesso. Ad esempio, `resource.aws.com/devicegroup1_id` identifica un singolo dispositivo Neuron, `resource.aws.com/devicegroup4_id` identifica un gruppo di 4 dispositivi connessi e `resource.aws.com/devicegroup16_id` identifica rispettivamente gruppi di 8 `resource.aws.com/devicegroup8_id` e 16 dispositivi connessi. Scegli `matchAttribute` quello che corrisponde al dispositivo nella tua richiesta `count` in modo che i dispositivi Neuron e le interfacce EFA allocati appartengano allo stesso gruppo di topologia connessa. [Per ulteriori informazioni su questi attributi, consultate la documentazione del driver Neuron DRA.](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/containers/neuron-dra.html)
È possibile utilizzarlo `allocationMode` per semplificare il modo in cui i dispositivi EFA vengono allocati alle GPU allineate o agli acceleratori Neuron. Il `allocationMode` campo supporta due valori: `ExactCount` (impostazione predefinita) richiede un numero specifico di dispositivi specificato da e `All` richiede tutti i dispositivi `count` corrispondenti in un pool. Ad esempio, `p5.48xlarge` nelle istanze ci sono quattro dispositivi EFA che condividono la stessa radice PCIe con una GPU. Per assegnare a questi gruppi di dispositivi EFA GPU allineate, anche se non conoscete la mappatura esatta dei dispositivi e il numero di EFA-GPU dispositivi EFA allineati, potete configurare la configurazione per i dispositivi EFA. `ResourceClaimTemplate` `allocationMode: All`
```
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"
```
## Condividi i dispositivi EFA tra più Pod
Il driver EFA DRA supporta la condivisione di dispositivi EFA tra più Pod utilizzando un. `ResourceClaim` A differenza di a`ResourceClaimTemplate`, che genera un claim separato per ogni Pod, a `ResourceClaim` è un oggetto con nome creato indipendentemente e a cui si fa riferimento da più Pod. Tutti i Pod che fanno riferimento allo stesso dispositivo `ResourceClaim` condividono l'accesso agli stessi dispositivi EFA assegnati e sono programmati sullo stesso nodo in cui tali dispositivi sono disponibili.
Per condividere i dispositivi EFA tra i Pod, crea un messaggio `ResourceClaim` che richieda i dispositivi EFA, quindi fai riferimento a tale affermazione per nome nel campo di ciascun Pod utilizzando. `resourceClaims` `resourceClaimName` `ResourceClaim`Deve esistere nel cluster prima che i Pod che vi fanno riferimento vengano creati. Se un oggetto referenziato `ResourceClaim` non esiste, i Pod rimangono in sospeso fino alla creazione del reclamo.
L'esempio seguente crea un messaggio `ResourceClaim` che richiede 4 dispositivi EFA e due Pod che condividono l'accesso a tali dispositivi.
1. Creazione della `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. Fai riferimento al `ResourceClaim` nome in ogni Pod che deve accedere ai dispositivi EFA. Ogni Pod utilizza `resourceClaimName` un riferimento al claim esistente invece di`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
```
Entrambi i Pod fanno riferimento allo stesso `shared-efa` `ResourceClaim` e sono programmati per il nodo in cui sono allocati i dispositivi EFA. Il `ResourceClaim` ciclo di vita è indipendente dai Pod: persiste finché non lo elimini, anche se tutti i Pod a cui fa riferimento vengono rimossi.
## Installa il plug-in per dispositivi EFA Kubernetes
Il plug-in per dispositivi EFA Kubernetes pubblicizza i dispositivi EFA come risorse estese. `vpc.amazonaws.com/efa` Richiedete i dispositivi EFA nelle richieste e nei limiti delle risorse del contenitore. Per una procedura dettagliata sulla configurazione di EFA con carichi di lavoro di formazione, consulta. [Esecuzione dei corsi di machine learning su Amazon EKS con Elastic Fabric Adapter](node-efa.md)
**Importante**
Topology-aligned l'allocazione di GPU NVIDIA o dispositivi Neuron con interfacce EFA avviene automaticamente quando si utilizzano le AMI accelerate AL2023. EKS-optimized Questo allineamento automatico non si verifica quando si utilizzano AMI Bottlerocket o AMI personalizzate. EKS-optimized Se hai bisogno di un acceleratore allineato alla topologia e dell'allocazione dei dispositivi EFA con Bottlerocket o AMI personalizzate, usa il driver EFA DRA e il driver Neuron DRA corrispondente. Il driver NVIDIA DRA non è supportato su Bottlerocket. Per ulteriori informazioni, consulta [Topology-aware EFA e GPU/Neuron allocazione dei dispositivi](#efa-dra-topology-aware).
**Importante**
A partire da NVIDIA `k8s-device-plugin` v0.19.0, il `--mofed-enabled` flag di default è impostato su, il che fa sì che il plugin per dispositivi NVIDIA `true` monti tutti i dispositivi in contenitori che richiedono GPU. `/dev/infiniband/uverbs*` Ciò è in conflitto con il plug-in del dispositivo EFA, che dovrebbe essere il componente che gestisce l'allocazione dei dispositivi EFA in. `/dev/infiniband` Se utilizzi gruppi di nodi gestiti da EKS o nodi autogestiti con il plug-in per dispositivi NVIDIA, devi disabilitare esplicitamente MOFED. Per istruzioni, consulta [Installa il plug-in per dispositivi NVIDIA Kubernetes](device-management-nvidia.md#nvidia-device-plugin).
La modalità automatica EKS non abilita MOFED per impostazione predefinita e non è interessata da questo problema.
### Prerequisiti
+ Un cluster Amazon EKS.
+ Nodi con EFA-enabled tipi di istanze Amazon EC2. Per un elenco dei tipi di istanze supportati, consulta Tipi [di istanze supportati](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html#efa-instance-types) nella Guida per l'*utente di Amazon EC2*.
+ Nodi con componenti a livello di host installati per EFA, consulta [Installare il software EFA](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable) per ulteriori informazioni. Le AMI NVIDIA e Neuron EKS-optimized AL2023 e le AMI Bottlerocket includono i componenti a livello di host EFA.
+ Helm è installato nell’ambiente a riga di comando, consulta le [istruzioni di configurazione di Helm](helm.md) per ulteriori informazioni.
+ `kubectl`configurato per comunicare con il cluster, vedi per ulteriori informazioni. [Installazione o aggiornamento di `kubectl`](install-kubectl.md#kubectl-install-update)
### Procedura
1. Aggiungi l'archivio cartografico EKS Helm.
```
helm repo add eks https://aws.github.io/eks-charts
```
1. Aggiorna il tuo archivio Helm locale.
```
helm repo update
```
1. Installa il plug-in del dispositivo EFA.
```
helm install efa eks/aws-efa-k8s-device-plugin -n kube-system
```
1. Verifica che il plug-in del dispositivo EFA DaemonSet sia in esecuzione.
```
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. Verifica che i tuoi nodi dispongano di risorse EFA allocabili.
```
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. Per richiedere dispositivi EFA utilizzando il plug-in del dispositivo, specifica la `vpc.amazonaws.com/efa` risorsa nelle richieste e nei limiti delle risorse del contenitore.
```
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: ...
```