**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à.
# Gestione dei dispositivi hardware su Amazon EKS
*Amazon EKS supporta due meccanismi Kubernetes per la gestione di dispositivi hardware specializzati nei cluster EKS: *Dynamic Resource Allocation (DRA)* e plugin per dispositivi.* Entrambi i meccanismi consentono ai carichi di lavoro di accedere ad acceleratori hardware come GPU NVIDIA e chip AWS Trainium e dispositivi di rete ad alte prestazioni come Elastic Fabric Adapter (EFA). Si consiglia di utilizzare i driver DRA per nuove implementazioni con le versioni 1.34 e successive di Kubernetes quando si utilizzano gruppi di nodi gestiti EKS o nodi autogestiti, poiché DRA offre una selezione di dispositivi più ricca, una pianificazione basata sulla topologia e funzionalità di condivisione dei dispositivi che non sono possibili con i plug-in dei dispositivi.
[https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/](https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/)
## Dynamic Resource Allocation e plugin per dispositivi
I plugin per dispositivi Kubernetes sono stati il meccanismo principale per esporre hardware specializzato ai carichi di lavoro Kubernetes. I plug-in dei dispositivi pubblicizzano i dispositivi come risorse estese (ad esempio, `nvidia.com/gpu` o`aws.amazon.com/neuroncore`) che richiedi nelle richieste e nei limiti delle risorse del contenitore. Sebbene i plug-in dei dispositivi siano ampiamente supportati e utilizzati, presentano delle limitazioni:
+ I dispositivi vengono richiesti come conteggi interi opachi senza filtri basati sugli attributi.
+ Nessun supporto per la condivisione dei dispositivi tra contenitori o Pod.
+ Nessuna allocazione espressiva basata sulla topologia tra i tipi di dispositivi.
+ Le estensioni di pianificazione personalizzate sono spesso necessarie per un posizionamento intelligente.
Dynamic Resource Allocation (DRA) è una funzionalità di Kubernetes resa generalmente disponibile nella versione 1.34 di Kubernetes che risolve queste limitazioni. Con DRA, i driver di dispositivo pubblicano ricchi attributi di dispositivo nello scheduler Kubernetes tramite oggetti. `ResourceSlice` I dispositivi richiedono l'utilizzo di oggetti `ResourceClaim` e `ResourceClaimTemplate` oggetti che fanno riferimento a categorie. `DeviceClass`
DRA consente:
+ Attribute-based selezione dei dispositivi utilizzando le espressioni del [Common Expression Language (CEL)](https://kubernetes.io/docs/reference/using-api/cel/).
+ Topology-aware allocazione che garantisce che i dispositivi siano collocati nello stesso switch PCIe o dominio NUMA.
+ Condivisione dei dispositivi tra più contenitori o Pod tramite riferimenti condivisi. `ResourceClaim`
+ Constraint-based pianificazione che allinea diversi tipi di dispositivi
## Driver DRA per Amazon EKS
I seguenti driver DRA sono comunemente usati per gestire dispositivi hardware specializzati nei cluster Amazon EKS.
Driver EFA DRA
Il driver EFA DRA ([DRANET](https://github.com/kubernetes-sigs/dranet)) gestisce l'allocazione dei dispositivi Elastic Fabric Adapter (EFA) con una pianificazione basata sulla topologia che associa le interfacce EFA alle GPU topologicamente locali o ai dispositivi Neuron e supporta la condivisione dei dispositivi tra Pod. Per ulteriori informazioni, consulta [Gestisci i dispositivi EFA su Amazon EKS](device-management-efa.md).
Driver Neuron DRA
Il driver Neuron DRA gestisce l'allocazione dei dispositivi AWS Trainium e AWS Inferentia2 con pianificazione basata sulla topologia, allocazione di sottoinsiemi di dispositivi connessi e configurazione Logical (LNC), senza richiedere estensioni di pianificazione personalizzate. NeuronCore
Driver NVIDIA DRA
Il [driver NVIDIA DRA per GPU consente l'allocazione flessibile e la riconfigurazione dinamica delle GPU](https://github.com/kubernetes-sigs/nvidia-dra-driver-gpu) NVIDIA, incluso il supporto per le `ComputeDomain` risorse per Multi-Node i carichi di lavoro NVLink (MNNVL) su istanze EC2. Grace-Blackwell Per ulteriori `ComputeDomains` informazioni sull'utilizzo Grace-Blackwell con le [Utilizzo P6e-GB200 UltraServers con Amazon EKS](ml-eks-nvidia-ultraserver.md) istanze EC2, consulta.
## Plugin di dispositivi per Amazon EKS
I seguenti plug-in per dispositivi sono comunemente usati per gestire dispositivi hardware specializzati nei cluster Amazon EKS.
Plugin per dispositivi EFA
Il plug-in EFA per dispositivi rileva tutti i dispositivi EFA disponibili su ciascun nodo e pubblicizza i dispositivi EFA come risorse estese. `vpc.amazonaws.com/efa`
Plugin per dispositivi Neuron
Il [plug-in del dispositivo Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/containers/tutorials/k8s-setup.html) espone l'hardware Neuron come `aws.amazon.com/neuroncore` risorse estese. `aws.amazon.com/neuron` Rileva i dispositivi Neuron disponibili su ciascun nodo, li pubblicizza come risorse allocabili e ne gestisce il ciclo di vita.
Plugin per dispositivi NVIDIA
Il [plug-in per dispositivi NVIDIA](https://github.com/NVIDIA/k8s-device-plugin) pubblicizza le GPU NVIDIA come risorse `nvidia.com/gpu` estese e monitora lo stato delle GPU.
## Considerazioni
Prima di utilizzare i driver DRA su Amazon EKS, esamina le seguenti considerazioni:
+ [DRA è disponibile su Amazon EKS con Kubernetes versione 1.33 e successive, ma è consigliato per le versioni 1.34 e successive di Kubernetes a causa di un problema di Kubernetes upstream.](https://github.com/kubernetes/kubernetes/issues/133920) Il piano di controllo e i nodi del cluster devono eseguire una versione di Kubernetes che supporti DRA.
+ DRA non è attualmente compatibile con l'elaborazione con provisioning Karpenter o EKS Auto Mode. È necessario utilizzare gruppi di nodi gestiti EKS o nodi autogestiti con driver DRA.
+ I driver DRA e i plug-in di dispositivo per lo stesso tipo di dispositivo non **devono essere** eseguiti contemporaneamente sullo stesso nodo. Disinstallate il plug-in del dispositivo prima di installare il driver DRA corrispondente o distribuitelo su nodi separati. Consulta upstream Kubernetes [KEP-5004](https://github.com/kubernetes/enhancements/issues/5004)per gli aggiornamenti sulla compatibilità del driver DRA e dei plug-in del dispositivo.
+ DRA utilizza risorse API Kubernetes diverse (,,) rispetto ai plug-in dei dispositivi (`ResourceClaim`,`ResourceClaimTemplate`). `DeviceClass` `resource.limits` `resource.requests` La migrazione dai plug-in dei dispositivi a DRA richiede l'aggiornamento delle specifiche del carico di lavoro.
+ I plug-in dei dispositivi rimangono completamente supportati per tutte le versioni di Kubernetes. Se il tuo cluster esegue una versione di Kubernetes precedente alla 1.34 o se utilizzi Karpenter o EKS Auto Mode, continua a utilizzare i plug-in del dispositivo. Il driver NVIDIA DRA non è supportato su Bottlerocket; usa il plug-in del dispositivo NVIDIA sui nodi Bottlerocket. I driver EFA e Neuron DRA sono supportati su Bottlerocket.
## DRA vs. ResourceClaim ResourceClaimTemplate
Quando si utilizza DRA, si richiedono dispositivi tramite `ResourceClaim` o `ResourceClaimTemplate` oggetti. Questi due tipi di risorse hanno scopi diversi e hanno comportamenti diversi durante il ciclo di vita.
ResourceClaim
A `ResourceClaim` è un oggetto Kubernetes denominato che crei indipendentemente da qualsiasi Pod. Si fa riferimento ad esso in una specifica Pod per nome utilizzando il campo. `resourceClaimName` A `ResourceClaim` ha le seguenti caratteristiche:
+ Deve esistere nel cluster prima di creare qualsiasi Pod che vi fa riferimento. Se il reclamo non esiste, il Pod rimane in sospeso.
+ Persiste finché non lo elimini esplicitamente, indipendentemente dal fatto che i Pod vi facciano riferimento.
+ Più Pod possono fare riferimento allo stesso`ResourceClaim`, il che consente la condivisione dei dispositivi. Tutti i Pod che fanno riferimento alla stessa dichiarazione condividono l'accesso agli stessi dispositivi assegnati e sono programmati per lo stesso nodo.
Usa un Pod `ResourceClaim` quando hai bisogno di più Pod per condividere l'accesso agli stessi dispositivi o quando hai bisogno che una dichiarazione duri oltre la durata di vita di un singolo Pod.
ResourceClaimTemplate
A `ResourceClaimTemplate` definisce un modello che Kubernetes utilizza per generare automaticamente un modello univoco `ResourceClaim` per ogni Pod. Vi si fa riferimento in una specifica del Pod utilizzando il campo. `resourceClaimTemplateName` Di per `ResourceClaimTemplate` sé non è legato a nessun Pod: è un modello riutilizzabile che persiste indipendentemente. A `ResourceClaimTemplate` ha le seguenti caratteristiche:
+ Kubernetes ne crea uno nuovo `ResourceClaim` per ogni Pod che fa riferimento al modello. Ogni Pod ha il proprio set separato di dispositivi.
+ Ogni elemento generato `ResourceClaim` è legato al ciclo di vita del Pod che ne ha innescato la creazione. Quando il Pod viene eliminato, viene eliminato anche `ResourceClaim` quello generato associato. La `ResourceClaimTemplate` stessa non ne risente e continua a generare nuove richieste per i Pod futuri.
Usa a `ResourceClaimTemplate` quando ogni Pod in un carico di lavoro necessita di dispositivi dedicati con configurazioni simili. Ad esempio, usa a `ResourceClaimTemplate` for Pods in un Job che utilizza l'esecuzione parallela in cui ogni Pod necessita della propria GPU o dei propri dispositivi EFA.
La tabella seguente riassume le differenze tra e. `ResourceClaim` `ResourceClaimTemplate`
| Comportamento | ResourceClaim | ResourceClaimTemplate |
| --- | --- | --- |
| Creazione | Lo crei manualmente prima che i Pod vi facciano riferimento | Kubernetes genera automaticamente un reclamo per Pod |
| Ciclo di vita | Persiste finché non lo elimini | Il modello persiste finché non lo elimini. Ogni elemento generato `ResourceClaim` è associato al Pod che ne ha attivato la creazione. |
| Condivisione dei dispositivi tra i Pod | Supportato. Più Pod possono fare riferimento alla stessa affermazione. | Non supportato. Ogni Pod riceve un reclamo separato. |
| Campo delle specifiche del Pod | `resourceClaimName` | `resourceClaimTemplateName` |
Per esempi di utilizzo di `ResourceClaim` oggetti per condividere dispositivi EFA tra Pod, consulta. [Condividi i dispositivi EFA tra più Pod](device-management-efa.md#efa-dra-share) Per esempi di utilizzo di `ResourceClaimTemplate` oggetti con allocazione basata sulla topologia, vedere. [Topology-aware EFA e GPU/Neuron allocazione dei dispositivi](device-management-efa.md#efa-dra-topology-aware)
## Argomenti
+ [Gestisci i dispositivi EFA su Amazon EKS](device-management-efa.md)
+ [Gestisci i dispositivi Neuron su Amazon EKS](device-management-neuron.md)
+ [Gestisci i dispositivi GPU NVIDIA su Amazon EKS](device-management-nvidia.md)