**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à.
# Esegui carichi di lavoro di esempio nei cluster della modalità automatica di EKS
Questo capitolo fornisce esempi di come implementare diversi tipi di carichi di lavoro nei cluster Amazon EKS in esecuzione in Auto Mode. Gli esempi illustrano i principali schemi di carico di lavoro, tra cui applicazioni di esempio, applicazioni web con bilanciamento del carico, carichi di lavoro stateful che utilizzano l’archiviazione persistente, e carichi di lavoro con requisiti di posizionamento dei nodi specifici. Ogni esempio include manifesti completi e istruzioni di step-by-step distribuzione che è possibile utilizzare come modelli per le proprie applicazioni.
Prima di procedere con gli esempi, assicurati di avere un cluster EKS in esecuzione in modalità automatica e di aver installato la AWS CLI e kubectl. Per ulteriori informazioni, consulta [Configurazione per l’utilizzo di Amazon EKS](setting-up.md). Gli esempi presuppongono una conoscenza base dei concetti di Kubernetes e dei comandi kubectl.
Puoi utilizzare questi esempi basati su casi d’uso per eseguire carichi di lavoro in cluster della modalità automatica di EKS.
[Implementazione di un esempio di carico di lavoro di decompressione in un cluster con modalità automatica di Amazon EKS](automode-workload.md)
Mostra come implementare un carico di lavoro di esempio in un cluster della modalità automatica di EKS utilizzando i comandi `kubectl`.
[Implementa un carico di lavoro del bilanciatore del carico esemplificativo in EKS Auto Mode](auto-elb-example.md)
Mostra come implementare una versione containerizzata del gioco 2048 su Amazon EKS.
[Implementazione di un carico di lavoro stateful esemplificativo in modalità automatica EKS](sample-storage-workload.md)
Mostra come implementare un’applicazione stateful di esempio in un cluster della modalità automatica di EKS.
[Implementare un carico di lavoro accelerato](auto-accelerated.md)
Mostra come distribuire carichi di lavoro con accelerazione hardware nei nodi gestiti da EKS Auto Mode.
[Controllare se un carico di lavoro viene implementato sui nodi di EKS Auto Mode](associate-workload.md)
Mostra come utilizzare un’annotazione per controllare se un carico di lavoro viene implementato nei nodi gestiti dalla modalità automatica di EKS.
# Implementazione di un esempio di carico di lavoro di decompressione in un cluster con modalità automatica di Amazon EKS
In questo tutorial imparerai come implementare un carico di lavoro di esempio su un cluster con modalità automatica EKS e osservare come esegue automaticamente il provisioning delle risorse di calcolo necessarie. Utilizzerai `kubectl` i comandi per osservare il comportamento del cluster e vedere in prima persona come la modalità automatica semplifica le operazioni di Kubernetes su. AWS Al termine di questo tutorial, capirai come la modalità automatica EKS risponde alle distribuzioni dei carichi di lavoro gestendo automaticamente le risorse di calcolo sottostanti, senza richiedere la configurazione manuale dei gruppi di nodi.
## Prerequisiti
+ Un cluster della modalità automatica di Amazon EKS. Annota il nome e la regione del cluster. AWS
+ Un principale IAM, come ad esempio un utente o un ruolo, con autorizzazioni sufficienti per gestire le risorse di rete, di elaborazione ed EKS.
+ Per ulteriori informazioni, consulta [Creating roles and attaching policies in the IAM User Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) nella Guida per l’utente IAM.
+ `aws` CLI installata e configurata con un’identità IAM.
+ `kubectl` CLI installata e connessa al cluster.
+ Per ulteriori informazioni, consulta [Configurazione per l’utilizzo di Amazon EKS](setting-up.md).
## Passaggio 1: rivedere le risorse di elaborazione esistenti (facoltativo)
Innanzitutto, usa `kubectl` per elencare i pool di nodi sul cluster.
```
kubectl get nodepools
```
Output di esempio:
```
general-purpose
```
In questo tutorial, implementeremo un carico di lavoro configurato per usare il pool di nodi `general-purpose`. Questo pool di nodi è integrato nella modalità automatica EKS e include impostazioni predefinite ragionevoli per carichi di lavoro generici, come microservizi e applicazioni web. Puoi creare un pool di nodi personalizzato. Per ulteriori informazioni, consulta [Crea un pool di nodi per EKS Auto Mode](create-node-pool.md).
Poi, utilizza `kubectl` per elencare i nodi collegati al tuo cluster.
```
kubectl get nodes
```
Se hai appena creato un cluster con modalità automatica EKS, non avrai nodi.
In questo tutorial implementerai un carico di lavoro di esempio. Se non ci sono nodi o il carico di lavoro non può essere gestito dai nodi esistenti, la modalità automatica EKS provvederà a fornire un nuovo nodo.
## Passaggio 2: implementare un’applicazione di esempio sul cluster
Esamina la seguente implementazione di Kubernetes e salvala come `inflate.yaml`
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate
spec:
replicas: 1
selector:
matchLabels:
app: inflate
template:
metadata:
labels:
app: inflate
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
containers:
- name: inflate
image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
resources:
requests:
cpu: 1
securityContext:
allowPrivilegeEscalation: false
```
Il selettore `eks.amazonaws.com/compute-type: auto` richiede che il carico di lavoro sia implementato su un nodo della modalità automatica di Amazon EKS.
Applica l’implementazione al cluster.
```
kubectl apply -f inflate.yaml
```
## Passaggio 3: vedere gli eventi di Kubernetes
Utilizza il seguente comando per vedere gli eventi di Kubernetes, inclusa la creazione di un nuovo nodo. Usa `ctrl+c` per interrompere la visione degli eventi.
```
kubectl get events -w --sort-by '.lastTimestamp'
```
Utilizza `kubectl` per elencare nuovamente i nodi collegati al tuo cluster. Prendi nota del nodo appena creato.
```
kubectl get nodes
```
## Passaggio 4: Visualizza i nodi e le istanze nella console AWS
È possibile visualizzare i nodi EKS Auto Mode nella console EKS e le EC2 istanze associate nella EC2 console.
EC2 Le istanze distribuite da EKS Auto Mode sono limitate. Non puoi eseguire comandi arbitrari sui nodi della modalità automatica EKS.
## Passaggio 5: eliminare l’implementazione
Per eliminare un’implementazione, usa `kubectl`
```
kubectl delete -f inflate.yaml
```
Se non ci sono altri carichi di lavoro implementati nel cluster, il nodo creato dalla modalità automatica EKS sarà vuoto.
Nella configurazione predefinita, la modalità automatica EKS rileva i nodi che rimangono vuoti per trenta secondi e li termina.
Utilizza `kubectl` o la EC2 console per confermare che l'istanza associata è stata eliminata.
# Implementa un carico di lavoro del bilanciatore del carico esemplificativo in EKS Auto Mode
Questa guida mostra come implementare una versione containerizzata del gioco 2048 su Amazon EKS, completa di bilanciamento del carico e accessibilità a Internet.
## Prerequisiti
+ Un cluster EKS Auto Mode
+ `kubectl` configurato per interagire con il cluster
+ Autorizzazioni IAM appropriate per la creazione di risorse ALB
## Fase 1: Creazione del namespace
Innanzitutto, crea un namespace dedicato per l’applicazione di gioco 2048.
Creare un file denominato `01-namespace.yaml`:
```
apiVersion: v1
kind: Namespace
metadata:
name: game-2048
```
Applica la configurazione del namespace:
```
kubectl apply -f 01-namespace.yaml
```
## Fase 2: Implementazione dell’applicazione
L’applicazione esegue più repliche del container del gioco 2048.
Creare un file denominato `02-deployment.yaml`:
```
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: game-2048
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 5
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
resources:
requests:
cpu: "0.5"
```
**Nota**
Se ricevi un errore durante il caricamento dell’immagine `public.ecr.aws/l6m2t8p7/docker-2048:latest`, conferma che il ruolo IAM del nodo dispone delle autorizzazioni sufficienti per estrarre immagini da ECR. Per ulteriori informazioni, consulta [Ruolo IAM del nodo](auto-learn-iam.md#auto-learn-node-iam-role). Inoltre, l’immagine `docker-2048` nell’esempio è un’immagine `x86_64` e non sarà eseguita su altre architetture.
**Componenti chiave:**
+ Implementa 5 repliche dell’applicazione
+ Utilizza un’immagine ECR pubblica
+ Richiede 0,5 core CPU per pod
+ Espone la porta 80 per il traffico HTTP
Applica l’implementazione:
```
kubectl apply -f 02-deployment.yaml
```
## Fase 3: Creazione del servizio
Il servizio espone l’implementazione alla rete di cluster.
Creare un file denominato `03-service.yaml`:
```
apiVersion: v1
kind: Service
metadata:
namespace: game-2048
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
selector:
app.kubernetes.io/name: app-2048
```
**Componenti chiave:**
+ Crea un servizio NodePort
+ Mappa la porta 80 alla porta 80 del container
+ Utilizza il selettore di etichette per trovare i pod
Applica il servizio:
```
kubectl apply -f 03-service.yaml
```
## Fase 4: Configurazione del bilanciamento del carico
Configurerai un ingresso per esporre l’applicazione a Internet.
Innanzitutto, crea la `IngressClass`. Creare un file denominato `04-ingressclass.yaml`:
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
labels:
app.kubernetes.io/name: LoadBalancerController
name: alb
spec:
controller: eks.amazonaws.com/alb
```
**Nota**
EKS Auto Mode richiede i tag di sottorete per identificare le sottoreti pubbliche e private.
Se hai creato il cluster con `eksctl`, disponi già di questi tag.
Informazioni su come [Assegnazione di tag alle sottoreti per la modalità automatica EKS](tag-subnets-auto.md).
Poi, crea la risorsa Ingress. Creare un file denominato `05-ingress.yaml`:
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: game-2048
name: ingress-2048
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-2048
port:
number: 80
```
**Componenti chiave:**
+ Crea un ALB connesso a Internet
+ Utilizza il tipo di destinazione IP per l’instradamento diretto al pod
+ Instrada tutto il traffico (/) al servizio di gioco
Applica le configurazioni di ingresso:
```
kubectl apply -f 04-ingressclass.yaml
kubectl apply -f 05-ingress.yaml
```
## Fase 5: Verifica dell’implementazione
1. Controlla che tutti i pod siano in esecuzione:
```
kubectl get pods -n game-2048
```
1. Verifica che il servizio sia stato creato:
```
kubectl get svc -n game-2048
```
1. Ottieni l’endpoint di ALB:
```
kubectl get ingress -n game-2048
```
Il campo ADDRESS nell’output di ingresso mostrerà l’endpoint di ALB. Attendi 2-3 minuti affinché l’ALB effettui il provisioning e registri tutti gli obiettivi.
## Fase 6: Accesso al gioco
Apri il browser web e accedi all’URL dell’endpoint di ALB della fase precedente. Dovresti vedere l’interfaccia di gioco 2048.
## Fase 7: Eliminazione
Per rimuovere tutte le risorse create in questo tutorial:
```
kubectl delete namespace game-2048
```
Questo eliminerà tutte le risorse nel namespace, incluse le risorse di implementazione, di servizio e di ingresso.
## Cosa succede dietro le quinte
1. L’implementazione crea 5 pod che eseguono il gioco 2048
1. Il servizio fornisce un accesso stabile alla rete a questi pod
1. EKS Auto Mode:
+ Crea un Application Load Balancer in AWS
+ Configura i gruppi di destinazione per i pod
+ Imposta le regole di instradamento per indirizzare il traffico al servizio
## Risoluzione dei problemi
Se il gioco non si carica:
+ Assicurati che tutti i pod siano in esecuzione: `kubectl get pods -n game-2048`
+ Verifica lo stato di ingresso: `kubectl describe ingress -n game-2048`
+ Verifica i controlli dell’integrità di ALB: Verificare lo stato del gruppo di destinazione nella Console AWS
# Implementazione di un carico di lavoro stateful esemplificativo in modalità automatica EKS
Questo tutorial ti guiderà nella distribuzione di un’applicazione stateful esemplificativa nel tuo cluster di modalità automatica EKS. L’applicazione scrive marche temporali su un volume persistente, dimostrando le funzionalità automatiche di provisioning e persistenza dei volumi EBS di modalità automatica EKS.
## Prerequisiti
+ Un cluster in modalità automatica EKS
+ AWS CLI configurata con le autorizzazioni appropriate
+ Installazione e configurazione di `kubectl`.
+ Per ulteriori informazioni, consulta [Configurazione per l’utilizzo di Amazon EKS](setting-up.md).
## Passaggio 1: configurazione dell’ambiente
1. Imposta le variabili di ambiente:
```
export CLUSTER_NAME=my-auto-cluster
export AWS_REGION="us-west-2"
```
1. Aggiorna kubeconfig:
```
aws eks update-kubeconfig --name "${CLUSTER_NAME}"
```
## Passaggio 2: creazione della classe di archiviazione
`StorageClass` definisce in che modo la modalità automatica EKS fornirà i volumi EBS.
Modalità automatica EKS non crea un `StorageClass` per te. Devi creare una `StorageClass` che faccia riferimento a `ebs.csi.eks.amazonaws.com` per utilizzare la funzionalità di archiviazione di modalità automatica EKS.
1. Creare un file denominato `storage-class.yaml`:
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
1. Applica: `StorageClass`
```
kubectl apply -f storage-class.yaml
```
**componenti chiave**
+ `provisioner: ebs.csi.eks.amazonaws.com`: utilizza modalità automatica EKS
+ `volumeBindingMode: WaitForFirstConsumer`: ritarda la creazione del volume fino a quando un pod non ne ha bisogno
+ `type: gp3`: specifica il tipo di volume EBS
+ `encrypted: "true"`: EBS utilizzerà la chiave `aws/ebs` predefinita per crittografare i volumi creati con questa classe. Questo passaggio è facoltativo, ma è consigliato.
+ `storageclass.kubernetes.io/is-default-class: "true"`: Kubernetes userà questa classe di archiviazione per impostazione predefinita, a meno che non sia specificata una classe di volume diversa su una dichiarazione di volume persistente. Fai attenzione quando imposti questo valore se stai migrando da un altro controller di archiviazione (facoltativo).
## Passaggio 3: creazione della dichiarazione di volume persistente
Il PVC richiede l’archiviazione da `StorageClass`.
1. Creare un file denominato `pvc.yaml`:
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: auto-ebs-claim
spec:
accessModes:
- ReadWriteOnce
storageClassName: auto-ebs-sc
resources:
requests:
storage: 8Gi
```
1. Applica il PVC:
```
kubectl apply -f pvc.yaml
```
**Componenti chiave:**
+ `accessModes: ReadWriteOnce`: il volume può essere montato da un nodo alla volta
+ `storage: 8Gi`: richiede un volume da 8 GiB
+ `storageClassName: auto-ebs-sc`: riferimenti su `StorageClass` abbiamo creato
## Passaggio 4: implementare un’applicazione
L’implementazione esegue un container che scrive marche temporali nel volume persistente.
1. Creare un file denominato `deployment.yaml`:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate-stateful
spec:
replicas: 1
selector:
matchLabels:
app: inflate-stateful
template:
metadata:
labels:
app: inflate-stateful
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
containers:
- name: bash
image: public.ecr.aws/docker/library/bash:4.4
command: ["/usr/local/bin/bash"]
args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 60; done"]
resources:
requests:
cpu: "1"
volumeMounts:
- name: persistent-storage
mountPath: /data
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: auto-ebs-claim
```
1. Applica l’implementazione:
```
kubectl apply -f deployment.yaml
```
**Componenti chiave:**
+ Semplice container bash che scrive una marca temporale su un file
+ Monta il PVC su `/data`
+ Richiede 1 core CPU
+ Utilizza il selettore di nodi per i nodi gestiti da EKS
## Passaggio 5: verificare la configurazione
1. Verifica che il pod sia in esecuzione:
```
kubectl get pods -l app=inflate-stateful
```
1. Verifica che il PVC sia legato:
```
kubectl get pvc auto-ebs-claim
```
1. Controlla il volume EBS:
```
# Get the PV name
PV_NAME=$(kubectl get pvc auto-ebs-claim -o jsonpath='{.spec.volumeName}')
# Describe the EBS volume
aws ec2 describe-volumes \
--filters Name=tag:CSIVolumeName,Values=${PV_NAME}
```
1. Verifica che i dati siano scritti:
```
kubectl exec "$(kubectl get pods -l app=inflate-stateful \
-o=jsonpath='{.items[0].metadata.name}')" -- \
cat /data/out.txt
```
## Passaggio 6: pulizia
Eseguire il comando riportato di seguito per rimuovere tutte le risorse create in questo tutorial:
```
# Delete all resources in one command
kubectl delete deployment/inflate-stateful pvc/auto-ebs-claim storageclass/auto-ebs-sc
```
## Cosa succede dietro le quinte
1. Il PVC richiede l’archiviazione da `StorageClass`
1. Quando è il pod è pianificato:
1. La modalità automatica EKS fornisce un volume EBS
1. Crea PersistentVolume
1. Collega il volume al nodo
1. Il pod monta il volume e inizia a scrivere le marche temporali
## Controller di snapshot
La modalità automatica EKS è compatibile con lo Snapshotter di CSI Kubernetes, noto anche come controller di snapshot. Tuttavia, la modalità automatica EKS non include il controller di snapshot. L’utente è responsabile dell’installazione e della configurazione del controller di snapshot. Per ulteriori informazioni, consulta [Abilitare la funzionalità snapshot per i volumi CSI](csi-snapshot-controller.md).
Leggi quanto segue `VolumeSnapshotClass` che fa riferimento alla capacità di archiviazione della modalità automatica EKS.
```
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: auto-ebs-vsclass
driver: ebs.csi.eks.amazonaws.com
deletionPolicy: Delete
```
[Scopri di più su Snapshotter di CSI Kubernetes.](https://github.com/kubernetes-csi/external-snapshotter/blob/master/README.md#usage)
# Implementare un carico di lavoro accelerato
Questo tutorial dimostra come la modalità automatica di Amazon EKS semplifica l'avvio di carichi di lavoro con accelerazione hardware. La modalità automatica di Amazon EKS semplifica le operazioni oltre il cluster stesso automatizzando i componenti chiave dell’infrastruttura che forniscono funzionalità di elaborazione, rete, bilanciamento del carico, storage e accesso e gestione delle identità pronte all’uso.
La modalità Auto di Amazon EKS include i driver e i plug-in di dispositivo necessari per determinati tipi di istanze, come i driver NVIDIA e AWS Neuron. Non è necessario installare o aggiornare questi componenti.
modalità automatica di EKS gestisce automaticamente i driver per questi acceleratori:
+ [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/)
+ [AWS Inferenza](https://aws.amazon.com/ai/machine-learning/inferentia/)
+ [Istanze EC2 accelerate NVIDIA GPUs su Amazon](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html)
**Nota**
La modalità automatica di EKS include il plug-in di dispositivo NVIDIA per Kubernetes. Questo plug-in viene eseguito automaticamente e non è visibile come daemon impostato nel cluster.
Supporto di reti avanzate:
+ [Elastic Fabric Adapter (EFA)](https://aws.amazon.com/hpc/efa/)
La modalità automatica di Amazon EKS elimina la difficoltà della gestione dei driver dell’acceleratore e dei plug-in di dispositivo.
Puoi anche trarre vantaggio dai risparmi sui costi ridimensionando il cluster fino a zero. Puoi configurare modalità automatica di EKS per terminare le istanze quando non è in esecuzione alcun carico di lavoro. Ciò è utile per i carichi di lavoro di inferenza basati su batch.
Di seguito viene fornito un esempio di come avviare carichi di lavoro accelerati con la modalità automatica di Amazon EKS.
## Prerequisiti
+ Un cluster Kubernetes con la modalità automatica di Amazon EKS configurata.
+ Una classe del nodo `default` EKS creata quando i pool di nodi gestiti da `general-purpose` o `system` sono abilitati.
## Fase 1: Implementare un carico di lavoro GPU
In questo esempio, creerai un file NodePool per carichi di lavoro basati su NVIDIA che richiede 45 GB di memoria GPU. Con la modalità automatica di EKS, utilizzi i vincoli di pianificazione di Kubernetes per definire i requisiti delle istanze.
Per distribuire la modalità automatica di Amazon EKS `NodePool` e l'esempio`workload`, esamina quanto segue NodePool e la definizione di Pod e salva con nome `nodepool-gpu.yaml` e `pod.yaml` nome:
**nodepool-gpu.yaml**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
taints:
- key: nvidia.com/gpu
effect: NoSchedule
terminationGracePeriod: 24h0m0s
```
**pod.yaml**
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
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:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
Il selettore `eks.amazonaws.com/compute-type: auto` richiede che il carico di lavoro sia implementato su un nodo della modalità automatica di Amazon EKS. NodePool Inoltre, imposta una caratteristica che consente di programmare solo pod con tolleranze per GPUs Nvidia.
Applica il carico di lavoro NodePool and al tuo cluster.
```
kubectl apply -f nodepool-gpu.yaml
kubectl apply -f pod.yaml
```
Verrà visualizzato l’output seguente:
```
nodepool.karpenter.sh/gpu configured created
pod/nvidia-smi created
```
Attendi qualche secondo e controlla i nodi del cluster. Ora dovresti vedere un nuovo nodo fornito nel cluster della modalità automatica di Amazon EKS:
```
> kubectl get nodes
NAME TYPE CAPACITY ZONE NODE READY AGE
gpu-dnknr g6e.2xlarge on-demand us-west-2b i-02315c7d7643cdee6 True 76s
```
## Fase 2: Convalida
Puoi vedere che la modalità automatica di Amazon EKS ha lanciato un `g6e.2xlarge` anziché un `g6.2xlarge` in quanto il carico di lavoro richiedeva un’istanza con l40s `GPU`, in base ai seguenti vincoli di pianificazione di Kubernetes:
```
...
nodeSelector:
eks.amazonaws.com/instance-gpu-name: l40s
...
requests:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
```
Ora, analizzare i log dei container, eseguendo il seguente comando:
```
kubectl logs nvidia-smi
```
Output di esempio:
```
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.230.02 Driver Version: 535.230.02 CUDA Version: 12.2 |
|-----------------------------------------+----------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+======================+======================|
| 0 NVIDIA L40S On | 00000000:30:00.0 Off | 0 |
| N/A 27C P8 23W / 350W | 0MiB / 46068MiB | 0% Default |
| | | N/A |
+-----------------------------------------+----------------------+----------------------+
+---------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=======================================================================================|
| No running processes found |
+---------------------------------------------------------------------------------------+
```
Puoi vedere che il container ha rilevato che è in esecuzione su un’istanza con una GPU `NVIDIA` e che non hai dovuto installare alcun driver di dispositivo, poiché questa è gestita dalla modalità automatica di Amazon EKS.
## Fase 3: Pulizia
Per rimuovere tutti gli oggetti creati, usa `kubectl` per eliminare la distribuzione di esempio e NodePool quindi il nodo viene terminato:
```
kubectl delete -f nodepool-gpu.yaml
kubectl delete -f pod.yaml
```
## Esempio NodePools di riferimento
### Crea un NVIDIA NodePool
Quanto segue NodePool definisce:
+ Solo istanze di avvio della famiglia `g6e` e `g6`
+ Consolidare i nodi quando sono vuoti per 1 ora
+ Il valore di 1 ora per `consolodateAfter` supporta carichi di lavoro con picchi e riduce il tasso di abbandono dei nodi. Puoi eseguire l’ottimizzazione di `consolidateAfter` in base ai requisiti del carico di lavoro.
**Esempio NodePool con famiglia di istanze GPU e consolidamento**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
terminationGracePeriod: 24h0m0s
```
Invece di impostare il `eks.amazonaws.com/instance-gpu-name`, puoi utilizzare `eks.amazonaws.com/instance-family` per specificare la famiglia di istanze. Per altre etichette note che influenzano la revisione della pianificazione, consultare [Etichette supportate da EKS Auto Mode](create-node-pool.md#auto-supported-labels).
Se hai requisiti di storage specifici, puoi ottimizzare lo storage `iops` temporaneo dei nodi `size` e `throughput` crearne uno personalizzato a cui fare riferimento nel. [NodeClass](create-node-class.md) NodePool [Scopri di più sulle opzioni configurabili. NodeClass ](create-node-class.md)
**Esempio di configurazione di archiviazione per NodeClass**
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
ephemeralStorage:
iops: 3000
size: 80Gi
throughput: 125
```
### Definisci AWS Trainium e AWS Inferentia NodePool
Di seguito NodePool è riportato un `eks.amazonaws.com/instance-category` set che indica solo le istanze di avvio delle famiglie Inferentia e Trainium:
```
- key: "eks.amazonaws.com/instance-category"
operator: In
values:
- inf
- trn
```