**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 su che si trova 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 la comunicazione tra nodi ad alte prestazioni e l'RDMA (Remote Direct Memory Access) per l'intelligenza artificiale, l'apprendimento automatico e i carichi di lavoro HPC (High Performance Computing). 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 del dispositivo EFA. * * *
Consigliamo di utilizzare i driver DRA per le nuove implementazioni con Kubernetes versioni 1.34 e successive quando si utilizza il provisioning della capacità [ statica in Karpenter, gruppi di nodi gestiti da EKS o nodi autogestiti. ](https://karpenter.sh/docs/concepts/nodepools/#static-nodepool) DRA non è attualmente supportato con EKS Auto Mode. Con il driver EFA DRA, è possibile configurare un'allocazione compatibile con la topologia che accoppia le interfacce EFA con le relative GPU o dispositivi Neuron topologicamente locali e condividere i dispositivi tra pod.
## 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 | Karpenter (solo capacità statica), gruppi di nodi gestiti, nodi autogestiti | EKS Auto Mode, Karpenter, gruppi di nodi gestiti, nodi autogestiti |
| EKS-optimized AMI | AL 2023, Bottlerocket | AL 2023, Bottlerocket |
| Pubblicità sul dispositivo | Attributi avanzati 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 AL2023) EKS-optimized |
| Neuron-EFA affinità | DRA-native consapevolezza della topologia | Riconoscimento automatico della topologia (solo AMI AL2023) EKS-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 [ posizionamento ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) con EKS Auto Mode, Karpenter, i gruppi di nodi gestiti da EKS o i gruppi di nodi autogestiti EKS. Con EKS Auto Mode, è possibile passare la configurazione per ciascuna interfaccia di rete attraverso la sezione sottostante. `NodeClass` `advancedNetworking.networkInterfaces` Con Karpenter, si passa la configurazione per ciascuna interfaccia di rete tramite. `EC2NodeClass` Con i gruppi di nodi gestiti da EKS o i nodi autogestiti, si passa la configurazione per ciascuna interfaccia di rete con [ modelli di avvio. ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html)
Quando si utilizza [`eksctl`](install-kubectl.md#eksctl-install-update) per il provisioning dei nodi EKS con questa `efaEnabled` impostazione, tutte le interfacce vengono 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](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 quello 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 [ Massimizzare la larghezza di banda di rete per i tipi ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html) di EFA-enabled istanza nella Amazon EC2 User Guide. * *
## Modalità automatica di EKS
In modalità EKS Auto, si configurano le interfacce di rete EFA utilizzando il campo in (). `advancedNetworking.networkInterfaces` `NodeClass` `eks.amazonaws.com/v1` Ogni voce specifica a`networkCardIndex`, `deviceIndex` e. `interfaceType` `interfaceType`Possono essere `interface` per interfacce di rete standard o `efa-only` per interfacce EFA dedicate al traffico RDMA senza indirizzi IP assegnati.
Una volta `networkInterfaces` configurata, le istanze avviate dal `NodePool` referente `NodeClass` utilizzano questa configurazione indipendentemente dal fatto che i Pod richiedano risorse. `vpc.amazonaws.com/efa` EKS Auto Mode non allega IP, prefissi o ENI aggiuntivi dopo l'avvio dell'istanza per i nodi con configurazione statica dell'interfaccia di rete: solo le interfacce e gli IP configurati all'avvio sono disponibili per i Pods.
Questa funzionalità può essere utilizzata con pool di nodi a capacità [ statica ](auto-static-capacity.md) per mantenere i nodi preriscaldati per carichi di lavoro di formazione e inferenza EFA-ready distribuiti.
### Esempio: EKS Auto Mode NodeClass con interfacce per P5 EFA-only
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: efa-node-class
spec:
role: MyNodeRole
subnetSelectorTerms:
- tags:
Name: "private-subnet"
securityGroupSelectorTerms:
- tags:
Name: "efa-security-group"
placementGroupSelector:
name: "ml-training-pg"
advancedNetworking:
networkInterfaces:
- deviceIndex: 0
interfaceType: interface
networkCardIndex: 0
secondaryIPv4PrefixCount: 1
- 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
```
Per l'elenco completo dei vincoli sulla configurazione dell'interfaccia di rete statica, vedere [Configurazione statica dell'interfaccia di rete](create-node-class.md#static-network-interfaces) la documentazione. NodeClass
## Karpenter
Ogni voce in `networkInterfaces` specifica a `networkCardIndex``deviceIndex`, e. `interfaceType` `interfaceType`Può essere `interface` per interfacce di rete standard o `efa-only` per interfacce EFA dedicate al traffico RDMA e a cui non sono assegnati indirizzi IP. Una volta `networkInterfaces` configurata, le istanze avviate dal `NodePool` referente `NodeClass` utilizzano questa configurazione indipendentemente dal fatto che i Pod richiedano risorse. `vpc.amazonaws.com/efa`
Quando si utilizza Karpenter senza `networkInterfaces` specificarlo`NodeClass`, le istanze create per i Pods che richiedono `vpc.amazonaws.com/efa` 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 da EKS o i nodi autogestiti, si passa alla configurazione di ciascuna 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 avvio 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 vengono utilizzate `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 ciascun tipo di istanza, consulta [ Massimizzare 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. * *
### Esempio di modello di avvio 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 * Amazon EC2 User Guide. *
**Importante**
Non specificare `SubnetId` nel modello di avvio 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 della sottorete.
```
{
"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 EKS-optimized AL2023 e tutte le AMI Bottlerocket includono i componenti a livello di host necessari per utilizzare EFA, in particolare i componenti installati da aws-efa-installer. [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable](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 questi ** devono essere installati 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, Amazon VPC CNI alloca gli indirizzi IP su tutti gli ENI IP-enabled collegati, il che può consumare un numero elevato di indirizzi IP dalla tua sottorete anche quando tali indirizzi non vengono utilizzati attivamente dai Pods. Nelle istanze con dozzine di interfacce di rete, questo 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 consumano indirizzi dalla sottorete. Ad 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 [ Massimizzare 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 e ENI caldi (preallocati). Per impostazione predefinita, il VPC CNI prealloca un pool caldo di ENI e indirizzi IP per velocizzare l'avvio del Pod, ma in casi di grandi dimensioni può riservare centinaia di indirizzi IP inutilizzati. Imposta le variabili di `WARM_ENI_TARGET` ambiente `WARM_IP_TARGET` e di ambiente su `aws-node` DaemonSet per controllare il numero di indirizzi IP e ENI di riserva che il CNI mantiene. 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` and sono a livello di cluster e si applicano a tutti i nodi gestiti da VPC CNI. Al momento non è possibile impostare valori diversi per ogni gruppo di nodi o tipo di istanza. Se hai bisogno di un controllo più granulare di queste impostazioni, fornisci un feedback sul problema \#1834 di [ containers-roadmap su. ](https://github.com/aws/containers-roadmap/issues/1834) GitHub
## Installa il driver EFA DRA (DRANET)
Il driver EFA DRA è integrato nel [ progetto ](https://github.com/kubernetes-sigs/dranet) DRANET upstream on, che fornisce la gestione dei dispositivi di rete basata sul cloud per GitHub 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 del driver e il nome. `ResourceSlice` `dra.net` `DeviceClass` `efa.networking.k8s.aws` Il driver EFA DRA viene eseguito DaemonSet su ciascun nodo e rileva automaticamente i dispositivi EFA.
### Prerequisiti
+ Un cluster Amazon EKS che esegue Kubernetes versione 1.34 o successiva con capacità statica fornita da Karpenter, gruppi di nodi gestiti da EKS o gruppi di nodi autogestiti.
+ EFA-enabled Nodi con tipi di istanza Amazon EC2. Per un elenco dei tipi di istanze supportati, consulta Tipi di istanza [ supportati ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html#efa-instance-types) nella * Amazon EC2 User Guide. *
+ Nodi con componenti a livello di host installati per EFA, consulta [ Installare il software EFA per maggiori informazioni. ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable) Le AMI NVIDIA e Neuron EKS-optimized AL2023 e le AMI Bottlerocket includono i componenti EFA a livello di host.
+ 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, consulta per ulteriori informazioni. [`Installa o aggiorna 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. Ciò può causare una sottoscrizione eccessiva silenziosa dei dispositivi sottostanti a più pod sullo stesso nodo.
1. Aggiungi il repository di grafici EKS Helm.
```
helm repo add eks https://aws.github.io/eks-charts
```
1. Aggiorna il tuo repository Helm locale.
```
helm repo update
```
1. Installa il driver EFA DRA sul tuo cluster usando Helm. Il driver EFA DRA rileva automaticamente che è in esecuzione su istanze EC2 tramite Instance Metadata Service (IMDS) e consente il rilevamento dei dispositivi EFA. Per impostazione predefinita, il driver EFA DRA viene distribuito come nel namespace. DaemonSet `kube-system` Per i parametri configurabili, consultate Helm values.yaml nell'archivio di grafici EKS Helm attivo[. ](https://github.com/aws/eks-charts/tree/master/stable/aws-dranet) GitHub
```
helm install aws-dranet eks/aws-dranet --namespace kube-system
```
1. Verificate DaemonSet che 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. Verificare 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 si verificano errori nei passaggi precedenti, è possibile 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 inseritelo 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 accoppia le interfacce EFA con GPU o 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 le 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 allocati e le interfacce EFA 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 a GPU o acceleratori Neuron allineati. 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 questi gruppi di dispositivi EFA a GPU allineate, anche se non si conosce l'esatta mappatura dei dispositivi e il numero di EFA-GPU dispositivi EFA allineati, è possibile configurare la configurazione con 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 denominato creato indipendentemente e a cui si fa riferimento da più Pod. Tutti i Pod che fanno riferimento allo stesso `ResourceClaim` condividono l'accesso agli stessi dispositivi EFA allocati e sono programmati sullo stesso nodo in cui tali dispositivi sono disponibili.
Per condividere i dispositivi EFA tra Pod, creane uno `ResourceClaim` che richieda i dispositivi EFA, quindi fai riferimento a quell'attestazione 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 riferimento `ResourceClaim` non esiste, i Pod rimangono in sospeso fino alla creazione del claim.
L'esempio seguente crea un file `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 nome `ResourceClaim` di ogni Pod che richiede l'accesso ai dispositivi EFA. Ogni Pod utilizza `resourceClaimName` per fare riferimento all'attestazione esistente anziché`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 nel nodo in cui sono allocati i dispositivi EFA. Il `ResourceClaim` ciclo di vita è indipendente dai Pod: persiste finché non li elimini, anche se tutti i Pod che vi fanno riferimento vengono rimossi.
## Installa il plug-in del dispositivo EFA Kubernetes
Il plug-in per dispositivi EFA Kubernetes pubblicizza i dispositivi EFA come risorse estese. `vpc.amazonaws.com/efa` Richiedete dispositivi EFA in container, richieste e limiti di risorse. Per una guida completa alla configurazione dell'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 delle GPU NVIDIA o dei 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 di un'allocazione dei dispositivi EFA con Bottlerocket o AMI personalizzate, usa il driver EFA DRA e il driver Neuron DRA corrispondente. Per utilizzare il driver NVIDIA DRA su Bottlerocket, devi prima disabilitare il plug-in del dispositivo NVIDIA fornito in bundle con le varianti NVIDIA Bottlerocket, che richiede Bottlerocket versione 1.63.0 o successiva. Per ulteriori informazioni, consultare [Topology-aware EFA e GPU/Neuron allocazione dei dispositivi](#efa-dra-topology-aware) e [Installa il driver NVIDIA DRA](device-management-nvidia-dra-device-plugin.md#eks-nvidia-dra-driver).
**Importante**
A partire da NVIDIA `k8s-device-plugin` v0.19.0, il flag predefinito è, il che fa sì che il plug-in del dispositivo NVIDIA monti tutti i dispositivi in contenitori che richiedono GPU. `--mofed-enabled` `true` `/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 si utilizzano gruppi di nodi gestiti da EKS o nodi autogestiti con il plug-in per dispositivi NVIDIA, è necessario disabilitare esplicitamente MOFED. Per istruzioni, consulta [Installa il plug-in del dispositivo NVIDIA Kubernetes](device-management-nvidia-dra-device-plugin.md#eks-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 tipi di istanza EFA-enabled Amazon EC2. Per un elenco dei tipi di istanze supportati, consulta Tipi di istanza [ supportati ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html#efa-instance-types) nella * Amazon EC2 User Guide. *
+ Nodi con componenti a livello di host installati per EFA, consulta [ Installare il software EFA per maggiori informazioni. ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable) Le AMI EKS-optimized AL2023 e le AMI Bottlerocket includono i componenti EFA a livello di host.
+ 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, consulta per ulteriori informazioni. [`Installa o aggiorna kubectl`](install-kubectl.md#kubectl-install-update)
### Procedura
1. Aggiungi il repository di grafici EKS Helm.
```
helm repo add eks https://aws.github.io/eks-charts
```
1. Aggiorna il tuo repository 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: ...
```