**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à.
# Controlla l’implementazione dei carichi di lavoro in Prenotazioni della capacità con la modalità automatica di EKS
Puoi controllare l’implementazione dei carichi di lavoro su [Prenotazioni della capacità](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html). La modalità automatica di EKS supporta le prenotazioni della capacità on demand EC2 (ODCR) e i blocchi di capacità EC2 per il machine learning.
**Suggerimento**
Per impostazione predefinita, EKS Auto Mode può essere avviato in open ODCRs tramite open-matching, ma non dà loro la priorità. Le istanze avviate tramite open-matching sono etichettate, non. `karpenter.sh/capacity-type: on-demand` `reserved` Per dare priorità all'utilizzo dell'ODCR e etichettare le istanze, configura nella definizione. `karpenter.sh/capacity-type: reserved` `capacityReservationSelectorTerms` NodeClass I Capacity Blocks for ML richiedono sempre `capacityReservationSelectorTerms` e non vengono utilizzati automaticamente.
## Prenotazioni di capacità su richiesta EC2 () ODCRs
Le prenotazioni della capacità on demand di EC2 (ODCR) permettono di prenotare la capacità di elaborazione per le istanze Amazon EC2 in una zona di disponibilità specifica per qualsiasi durata. Quando si utilizza modalità automatica di EKS, potresti voler controllare se i carichi di lavoro di Kubernetes vengono implementati su queste istanze riservate per massimizzare l’utilizzo della capacità pre-acquistata o per garantire che i carichi di lavoro critici abbiano accesso a risorse garantite.
Per impostazione predefinita, EKS Auto Mode si apre automaticamente. ODCRs Tuttavia, configurando `capacityReservationSelectorTerms` su a NodeClass, puoi controllare in modo esplicito l'utilizzo dei ODCRs tuoi carichi di lavoro. I nodi forniti utilizzando configure ODCRs avranno e avranno priorità rispetto a on-demand `karpenter.sh/capacity-type: reserved` e spot. Una volta abilitata questa funzionalità, EKS Auto Mode non utilizzerà più automaticamente open ODCRs: devono essere selezionati esplicitamente da un NodeClass, in modo da consentire un controllo preciso sull'utilizzo della prenotazione della capacità in tutto il cluster.
**avvertimento**
Se si esegue la configurazione `capacityReservationSelectorTerms` all' NodeClass interno di un cluster, EKS Auto Mode non utilizzerà più automaticamente open ODCRs per *nessuno* NodeClass dei componenti del cluster.
### Esempio NodeClass
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
spec:
# Optional: Selects upon on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
app: "my-app"
# Optional owning account ID filter
owner: "012345678901"
```
Questo esempio NodeClass illustra due approcci per la selezione ODCRs. Il primo metodo fa riferimento direttamente a una ODCR specifica tramite il relativo ID (`cr-56fac701cc1951b03`). Il secondo metodo utilizza la selezione basata su tag, mirando ODCRs con il tag. `Name: "targeted-odcr"` Facoltativamente, puoi anche filtrare in base all' AWS account proprietario della prenotazione, il che è particolarmente utile negli scenari tra più account o quando lavori con prenotazioni di capacità condivise.
## Blocchi di capacità EC2 per ML
I blocchi di capacità per ML prenotano istanze a calcolo accelerato basate su GPU in una data futura per supportare carichi di lavoro di machine learning (ML) di breve durata. Le istanze eseguite all'interno di un Capacity Block vengono automaticamente posizionate vicine tra loro all'interno di Amazon UltraClusters EC2, per reti a bassa latenza, su scala petabit e non bloccanti.
Per ulteriori informazioni sulle piattaforme e sui tipi di istanze supportati, consulta [Capacity Blocks for ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) nella Guida per l’utente di EC2.
Puoi creare una modalità automatica EKS NodeClass che utilizza un Capacity Block per ML, simile a un ODCR (descritto in precedenza).
Le seguenti definizioni di esempio creano tre risorse:
1. A NodeClass che fa riferimento alla tua prenotazione Capacity Block
1. A NodePool che utilizza NodeClass e applica una macchia
1. Una specifica per Pod che tollera il taint e richiede risorse GPU
### Esempio NodeClass
Questo NodeClass fa riferimento a uno specifico Capacity Block for ML tramite il relativo ID di prenotazione. Puoi ottenere questo ID dalla console EC2.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
# Specify your Capacity Block reservation ID
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
```
Per ulteriori informazioni, consulta [Creazione di una classe di nodi per Amazon EKS](create-node-class.md).
### Esempio NodePool
Questo NodePool fa riferimento `gpu` NodeClass e specifica una configurazione importante:
+ Utilizza **solo** la capacità riservata impostando `karpenter.sh/capacity-type: reserved`
+ Richiede famiglie di istanze GPU specifiche adatte ai carichi di lavoro ML
+ Applica un taint `nvidia.com/gpu` per garantire che solo i carichi di lavoro GPU siano pianificati su questi nodi
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: gpu
requirements:
- key: eks.amazonaws.com/instance-family
operator: In
values:
- g6
- p4d
- p4de
- p5
- p5e
- p5en
- p6
- p6-b200
- key: karpenter.sh/capacity-type
operator: In
values:
- reserved
# Enable other capacity types
# - on-demand
# - spot
taints:
- effect: NoSchedule
key: nvidia.com/gpu
```
Per ulteriori informazioni, consulta [Crea un pool di nodi per EKS Auto Mode](create-node-pool.md).
### Pod di esempio
Questo pod di esempio dimostra come configurare un carico di lavoro da eseguire sui nodi del blocco di capacità:
+ Utilizza un **NodeSelector** per indirizzare tipi di GPU specifici (in questo caso, H200) GPUs
+ Include una **tolleranza** per la macchia applicata dal `nvidia.com/gpu` NodePool
+ **Richiede esplicitamente le risorse GPU** che utilizzano il tipo di risorsa `nvidia.com/gpu`
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
# Select specific GPU type - uncomment as needed
# eks.amazonaws.com/instance-gpu-name: l4
# eks.amazonaws.com/instance-gpu-name: a100
eks.amazonaws.com/instance-gpu-name: h200
# eks.amazonaws.com/instance-gpu-name: b200
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
# Uncomment if needed
# memory: "30Gi"
# cpu: "3500m"
nvidia.com/gpu: 1
limits:
# Uncomment if needed
# memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
Per ulteriori informazioni, consulta [Pods](https://kubernetes.io/docs/concepts/workloads/pods/) nella documentazione Kubernetes.
### Risorse correlate
+ [Capacity Blocks for ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) nella Guida per l’utente di Amazon EC2
+ [Find and purchase Capacity Blocks](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html) nella Guida per l’utente di Amazon EC2
+ [Gestisci le risorse di calcolo per i AI/ML carichi di lavoro su Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html)
+ [GPU Resource Optimization and Cost Management](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management) nella Guida alle best practice di EKS