**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 l'elaborazione per i AI/ML carichi di lavoro con EKS Auto Mode e Karpenter **Suggerimento** [Registrati](https://events.eksworkshop.com/workshops/genai/) ai prossimi AI/ML workshop Amazon EKS. Questa sezione spiega come gestire l'elaborazione accelerata (AWS Trainium, GPU NVIDIA) per i carichi di lavoro di addestramento e inferenza AI utilizzando Amazon EKS Auto Mode o Karpenter autogestito. EKS Auto Mode e Karpenter supportano due modalità di provisioning: provisioning dinamico e provisioning statico. Con il provisioning dinamico, EKS Auto Mode e Karpenter forniscono e scalano le istanze di calcolo accelerate man mano che i carichi di lavoro sono programmati sul cluster. Con il provisioning statico, EKS Auto Mode e Karpenter forniscono e gestiscono un numero fisso di nodi. È possibile utilizzare il provisioning dinamico e statico nello stesso cluster per mantenere un pool di capacità di base costante e al contempo scalare in base alle richieste del carico di lavoro. EKS Auto Mode e Karpenter supportano tutte e quattro le opzioni di acquisto della capacità (SpotOn-Demand, Capacity Blocks e ODCR) e forniscono sempre prima la capacità riservata, seguita da Spot o. On-Demand ## EKS Auto Mode contro Karpenter Entrambi gli approcci condividono l' NodePool API, ma differiscono per proprietà operativa, API delle risorse, supporto del sistema operativo, gestione delle interruzioni Spot e flessibilità di configurazione. | Funzionalità | Modalità automatica di EKS | Self-managed Karpenter | | --- | --- | --- | | Ideale per | Team che preferiscono un'infrastruttura gestita con un sovraccarico operativo minimo | Team che preferiscono il pieno controllo sul ciclo di vita dei nodi, sulle AMI, sull'ottimizzazione del sistema operativo e sull'applicazione delle patch. | | Modello operativo | AWS effettua il provisioning e gestisce il controller Karpenter, GPU/Trainium i driver, i plug-in dei dispositivi, l'applicazione delle patch al sistema operativo e la gestione delle interruzioni Spot. | Tu installi e gestisci il controller Karpenter nel tuo cluster e possiedi i GPU/Trainium driver, i plug-in dei dispositivi, il ciclo di vita delle AMI, l'applicazione delle patch e la gestione delle interruzioni Spot. | | Opzioni di calcolo | On-Demand, Spot, ODCR, Capacity Blocks per ML | On-Demand, Spot, ODCR, Capacity Blocks per ML | | API di risorse | `NodePool` (`karpenter.sh/v1`), `NodeClass` (`eks.amazonaws.com/v1`). | `NodePool` (`karpenter.sh/v1`), `EC2NodeClass` (`karpenter.k8s.aws/v1`). | | Sistema operativo Node | Solo Bottlerocket. Dipendenze NVIDIA GPU, AWS Trainium ed EFA incluse. | AL2023, Bottlerocket, Windows o la tua AMI. | | Durata del nodo | Durata massima del nodo di 21 giorni per l'applicazione delle patch di sicurezza. I carichi di lavoro devono tollerare la rotazione dei nodi. | Sei tu a definire il ciclo di vita del nodo e i budget relativi alle interruzioni NodePool `expireAfter`. | | Gestione delle interruzioni puntuali | Nativo. Non è richiesta alcuna coda SQS o Node Termination Handler. | È responsabilità dell'utente configurare e abilitare. | | Estrazione rapida dei contenitori | Il pull parallelo SOCI è incluso in tutte le istanze della famiglia G, P e Trn | È tua responsabilità configurare e abilitare. | | Gruppi di collocamento EC2 | Cluster, partizione, diffusione | Cluster, partizione, diffusione | | Configurazione dell'interfaccia di rete | Non supportata | Configurazione per interfaccia per tipo `interface` o `EFA-only` | | Riparazione dei nodi | Abilitato per impostazione predefinita, include l'agente di monitoraggio dei nodi EKS | Abilitato opzionalmente, agente di monitoraggio dei nodi EKS autogestito | | Prezzi | Tariffa di [gestione EKS Auto Mode in aggiunta al costo](https://aws.amazon.com/eks/pricing/) sottostante dell'istanza EC2. | Fonte aperta. Paghi per le istanze EC2 sottostanti. | ## Etichette comuni AI/ML e note EKS Auto Mode e Karpenter espongono le etichette delle istanze che è possibile utilizzare in NodePool `requirements` and Pod `nodeSelector` o `nodeAffinity` per indirizzare carichi di lavoro senza codificare i tipi di istanze. Il prefisso dell'etichetta è diverso tra i due: EKS Auto Mode utilizza mentre Karpenter autogestito utilizza. `eks.amazonaws.com/` `karpenter.k8s.aws/` Le tabelle seguenti mostrano le etichette pertinenti che possono essere utilizzate in. NodePools EKS Auto Mode e Karpenter applicano anche le etichette elencate nella [documentazione di Karpenter](https://karpenter.sh/docs/concepts/scheduling/#labels) ai nodi come parte del processo di provisioning che possono essere ulteriormente utilizzate per il targeting dei carichi di lavoro. ------ #### [ EKS Auto Mode ] [Per l'elenco completo, consulta le etichette supportate dalla modalità automatica EKS.](https://docs.aws.amazon.com/eks/latest/userguide/create-node-pool.html#auto-supported-labels) | Etichetta | Valore di esempio | Description | | --- | --- | --- | | `eks.amazonaws.com/instance-family` | `p5` | Tipi di istanze con proprietà simili ma quantità di risorse diverse. | | `eks.amazonaws.com/instance-category` | `p` | Categoria di istanza, in genere la lettera che precede il numero di generazione. | | `eks.amazonaws.com/instance-generation` | `5` | Numero di generazione del tipo di istanza all'interno di una categoria. | | `eks.amazonaws.com/instance-gpu-name` | `h100` | Nome della GPU sull'istanza. | | `eks.amazonaws.com/instance-gpu-manufacturer` | `nvidia` | Nome del produttore della GPU. | | `eks.amazonaws.com/instance-gpu-count` | `8` | Numero di GPU sull'istanza. | | `eks.amazonaws.com/instance-gpu-memory` | `81920` | Mebibyte di memoria per GPU. | | `karpenter.sh/capacity-type` | `reserved` | Tipo di capacità:`spot`, o. `on-demand` `reserved` | | `topology.kubernetes.io/zone` | `us-east-1a` | Zona di disponibilità. | ------ #### [ Self-managed Karpenter ] Per l'elenco completo, vedi [Karpenter Labels Well-Known ](https://karpenter.sh/docs/concepts/scheduling/#well-known-labels). | Etichetta | Valore di esempio | Description | | --- | --- | --- | | `karpenter.k8s.aws/instance-family` | `p5` | Tipi di istanze con proprietà simili ma quantità di risorse diverse. | | `karpenter.k8s.aws/instance-category` | `p` | Categoria di istanza, in genere la lettera che precede il numero di generazione. | | `karpenter.k8s.aws/instance-generation` | `5` | Numero di generazione del tipo di istanza all'interno di una categoria. | | `karpenter.k8s.aws/instance-gpu-name` | `h100` | Nome della GPU sull'istanza. | | `karpenter.k8s.aws/instance-gpu-manufacturer` | `nvidia` | Nome del produttore della GPU. | | `karpenter.k8s.aws/instance-gpu-count` | `8` | Numero di GPU sull'istanza. | | `karpenter.sh/capacity-type` | `reserved` | Tipo di capacità: `spot``on-demand`, o`reserved`. | | `topology.kubernetes.io/zone` | `us-east-1a` | Zona di disponibilità. | | `kubernetes.io/arch` | `amd64` | Architettura della CPU. | ------ ## Etichette di pianificazione per la capacità riservata Quando EKS Auto Mode o Karpenter avvia un nodo in una prenotazione, aggiunge le seguenti etichette. Utilizzale in`nodeSelector`, nell'affinità dei nodi o nei NodePool requisiti per indirizzare i carichi di lavoro. + `karpenter.sh/capacity-type`:`reserved`, o`on-demand`. `spot` Indica la capacità di backup del nodo. + `karpenter.k8s.aws/capacity-reservation-id`: l'ID di prenotazione specifico in cui è stato avviato il nodo. + `karpenter.k8s.aws/capacity-reservation-type`: `default` per ODCR, `capacity-block` per Capacity Blocks. Gli esempi seguenti mostrano modelli di pianificazione comuni: **Aggiungi un Pod a una prenotazione specifica (nessuna riserva):** ``` spec: nodeSelector: karpenter.sh/capacity-type: reserved karpenter.k8s.aws/capacity-reservation-id: "cr-0123456789abcdef0" ``` **Scegli come target solo i nodi ODCR (qualsiasi ODCR, non i Capacity Blocks):** ``` spec: nodeSelector: karpenter.sh/capacity-type: reserved karpenter.k8s.aws/capacity-reservation-type: default ``` **Scegli come target qualsiasi capacità riservata (ODCR o Capacity Block):** ``` spec: nodeSelector: karpenter.sh/capacity-type: reserved ``` **Preferisci riservato ma ricorri a Spot o On-Demand se non disponibile:** ``` spec: affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 preference: matchExpressions: - key: karpenter.sh/capacity-type operator: In values: ["reserved"] ``` ## Comportamento di scadenza della prenotazione Gli ODCR e i Capacity Blocks si comportano diversamente al termine della prenotazione. Assicurati che la tua strategia di pianificazione e checkpoint corrisponda al tipo di prenotazione che supporta il tuo carico di lavoro. **ODCR** Un'istanza lanciata in un ODCR non è presente in tale ODCR a tempo indeterminato. L'ODCR può scadere, essere annullato oppure l'istanza può essere rimossa manualmente dall'ODCR. Se si verifica una di queste situazioni e EKS Auto Mode/Karpenter rileva che l'istanza non appartiene più a un ODCR, aggiorna l'etichetta del nodo da a. `karpenter.sh/capacity-type` `reserved` `on-demand` L'istanza continua a funzionare con On-Demand capacità standard e i Pod esistenti continuano a funzionare senza interruzioni. **Nota** Qualsiasi Pod programmato con un strict non `nodeSelector: karpenter.sh/capacity-type: reserved` verrà programmato sul nodo se è stato rietichettato. Affinché i carichi di lavoro sopravvivano alla scadenza o alla cancellazione dell'ODCR, utilizza lo `preferredDuringSchedulingIgnoredDuringExecution` schema mostrato sopra anziché un. `nodeSelector` **Blocchi di capacità** A differenza degli ODCR, i Capacity Blocks hanno sempre un'ora di fine ed EC2 termina le istanze Capacity Block 30 minuti prima dell'ora di fine (60 minuti per i tipi di istanza). UltraServer Pianifica i lavori di formazione e inferenza per completare o salvare lo stato prima della chiusura della finestra di prenotazione. I pod che utilizzano un codice rigoroso `nodeSelector` per un determinato `capacity-reservation-id` periodo vengono attivati una `Pending` volta scaduto il blocco e non verranno riprogrammati altrove. Combina il checkpoint con il modello di affinità flessibile riportato sopra se hai bisogno che i carichi di lavoro passino ad altre capacità durante la scadenza del Capacity Block. + Puoi utilizzare le istanze riservate fino a 30 minuti prima dell'ora di fine del Capacity Block per la maggior parte dei tipi di istanze o 60 minuti prima dell'ora di fine per i tipi di istanze. UltraServer + EKS Auto Mode e Karpenter iniziano a svuotare preventivamente i nodi in un Capacity Block 10 minuti prima dell'inizio della chiusura di EC2, in modo che i carichi di lavoro abbiano il tempo di effettuare il checkpoint e spegnersi correttamente. ## Capacità statica NodePools EKS Auto Mode e Karpenter supportano la *capacità statica* NodePools, che mantiene un numero fisso di nodi indipendentemente dalla richiesta del carico di lavoro. I pool statici eliminano i ritardi dovuti all'avvio a freddo per l'inferenza sensibile alla latenza e consentono di riservare un ingombro minimo dell'infrastruttura per il cluster. La capacità statica viene configurata impostando il campo su. `replicas` NodePool **Considerazioni** + Una volta `replicas` impostato su un NodePool, non è possibile rimuoverlo. Un singolo NodePool non può passare dal provisioning statico a quello dinamico della capacità. + La capacità statica non NodePools viene presa in considerazione per il consolidamento. Impostato `limits.nodes` sopra `replicas` per consentire il ridimensionamento temporaneo durante la deriva o la scadenza dell'AMI. + Per una distribuzione prevedibile delle zone di disponibilità (AZ), crea una capacità statica NodePool per AZ anziché estenderla su più zone in un unico pool. ------ #### [ EKS Auto Mode ] L'esempio seguente mostra una capacità statica NodePool che utilizza la modalità automatica EKS predefinita NodeClass e crea una capacità statica NodePool con 4 nodi (`replicas`) che possono essere al massimo 6 nodi (). `limits.nodes` ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-static-inference spec: replicas: 4 template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6e"] - key: "topology.kubernetes.io/zone" operator: In values: ["us-east-1a"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule limits: nodes: 6 # Allow temporary headroom during node replacement ``` ------ #### [ Self-managed Karpenter ] Con Karpenter autogestito, la capacità statica è limitata dalla `StaticCapacity` funzione alpha (lanciata nella versione Karpenter v1.8), che deve essere abilitata nei valori Helm: ``` settings: featureGates: staticCapacity: true ``` Fa NodePool riferimento a un `EC2NodeClass` nome personalizzato `my-nodeclass` e crea uno statico NodePool con 4 nodi (`replicas`) che possono essere al massimo 6 nodi (). `limits.nodes` ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-static-inference spec: replicas: 4 template: spec: nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: my-nodeclass requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6e"] - key: "topology.kubernetes.io/zone" operator: In values: ["us-east-1a"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule limits: nodes: 6 # Allow temporary headroom during node replacement ``` ------ ## Blocchi di capacità per ML [I Capacity Blocks for ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) consentono di prenotare istanze P-family e Trainium per una finestra futura definita. Sono prepagate, quindi EKS Auto Mode e Karpenter le considerano gratuite e danno loro la priorità rispetto a Spot. On-Demand I Capacity Blocks for ML possono avere una durata di prenotazione di 1-14 giorni o un multiplo di 7 giorni, fino a 182 giorni (6 mesi). Per utilizzare Capacity Blocks for ML con EKS Auto Mode o Karpenter, `capacityReservationSelectorTerms` configuralo inserendo il tuo ID di prenotazione della capacità nel tuo. NodeClass Non è possibile utilizzare l'open booking matching con Capacity Blocks for ML. Un termine può specificare un ID, un set di tag o criteri di corrispondenza delle istanze in base ai quali effettuare una selezione. Quando specifica i tag, selezionerà tutte le prenotazioni di capacità accessibili dall'account con i tag corrispondenti. Questo può essere ulteriormente limitato specificando l'ID di un account proprietario. Per altri esempi, consulta la documentazione di [Karpenter](https://karpenter.sh/docs/concepts/nodeclasses/#speccapacityreservationselectorterms). ------ #### [ EKS Auto Mode ] Creane una `NodeClass` che faccia riferimento alla tua prenotazione Capacity Block, quindi creane una NodePool che la utilizzi. Con `consolidateAfter: Never` set, Karpenter non tenterà di sostituire, unire o terminare i nodi per ridurre i costi o imballare i carichi di lavoro in modo più efficiente. Questa opzione è consigliata per i Capacity Blocks perché la capacità è già prepagata. ``` apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: capacity-block-gpu spec: capacityReservationSelectorTerms: - id: "cr-0123456789abcdef0" # Your Capacity Block reservation ID # Alternative: select by tags # - tags: # role: "production-inference" # owner: "012345678901" --- apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-capacity-block spec: disruption: consolidationPolicy: WhenEmpty consolidateAfter: Never template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: capacity-block-gpu requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["reserved"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["p5", "p5e", "p5en", "p4d"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule ``` ------ #### [ Self-managed Karpenter ] Creane uno `EC2NodeClass` che includa selettori AMI, sottorete e gruppi di sicurezza oltre a`capacityReservationSelectorTerms`, quindi creane uno NodePool che lo utilizzi. Con `consolidateAfter: Never` set, Karpenter non tenterà di sostituire, unire o terminare i nodi per ridurre i costi o imballare i carichi di lavoro in modo più efficiente. Questa opzione è consigliata per i Capacity Blocks perché la capacità è già prepagata. ``` apiVersion: karpenter.k8s.aws/v1 kind: EC2NodeClass metadata: name: capacity-block-gpu spec: amiSelectorTerms: - alias: al2023@latest subnetSelectorTerms: - tags: karpenter.sh/discovery: ml-cluster securityGroupSelectorTerms: - tags: karpenter.sh/discovery: ml-cluster capacityReservationSelectorTerms: - id: "cr-0123456789abcdef0" # Your Capacity Block reservation ID # Alternative: select by tags # - tags: # role: "production-inference" # owner: "012345678901" --- apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-capacity-block spec: disruption: consolidationPolicy: WhenEmpty consolidateAfter: Never template: spec: nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: capacity-block-gpu requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["reserved"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["p5", "p5e", "p5en", "p4d"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule ``` ------ ## On-Demand Prenotazioni di capacità (ODCR) Gli ODCR garantiscono la capacità in una zona di disponibilità (AZ) specifica senza un impegno a lungo termine. Ti verranno addebitate le On-Demand tariffe standard indipendentemente dal fatto che la capacità venga utilizzata o meno. Gli ODCR supportano tutte le famiglie di GPU NVIDIA, incluse le G-family istanze non supportate da Capacity Blocks for ML. Gli ODCR sono prepagati, quindi EKS Auto Mode e Karpenter li modellano come gratuiti e danno loro la priorità rispetto a Spot e Spot. On-Demand Gli ODCR si comportano in modo diverso rispetto a Capacity Blocks for ML al termine della prenotazione. Quando un ODCR scade o viene annullato, l'istanza continua a funzionare come standard. On-Demand Per informazioni dettagliate, vedi [Comportamento di scadenza della prenotazione](#eks-aiml-node-pools-expiration). Per utilizzare gli ODCR con EKS Auto Mode o Karpenter, `capacityReservationSelectorTerms` configurali inserendo i termini di prenotazione della capacità nel tuo. NodeClass Un termine può specificare un ID, un set di tag o criteri di corrispondenza a istanze in base ai quali effettuare la selezione. Quando specifica i tag, selezionerà tutte le prenotazioni di capacità accessibili dall'account con i tag corrispondenti. Quando specifica i criteri di corrispondenza delle istanze, seleziona le prenotazioni in base al loro comportamento di corrispondenza: open (corrisponde a tutte le istanze compatibili) o targetizzata (corrisponde solo alle istanze con target esplicito). Questo può essere ulteriormente limitato specificando l'ID dell'account proprietario. Per altri esempi, consulta la documentazione di [Karpenter](https://karpenter.sh/docs/concepts/nodeclasses/#speccapacityreservationselectorterms). ------ #### [ EKS Auto Mode ] Crea un `NodeClass` with `capacityReservationSelectorTerms` e un NodePool che dia priorità `reserved` con fallback. `on-demand` Aggiungi `topology.kubernetes.io/zone` alla AZ dell'ODCR: ``` apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: odcr-gpu-production spec: capacityReservationSelectorTerms: - id: "cr-0987654321fedcba0" # Alternative: select by tags # - tags: # Purpose: "production-inference" # owner: "012345678901" --- apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-reserved-production spec: disruption: consolidationPolicy: WhenEmpty consolidateAfter: Never template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: odcr-gpu-production requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["reserved", "on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["p5", "g6e"] - key: "topology.kubernetes.io/zone" operator: In values: ["us-east-1a"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule ``` ------ #### [ Self-managed Karpenter ] Crea un selettore `EC2NodeClass` con AMI, sottorete e gruppo di sicurezza oltre a`capacityReservationSelectorTerms`, quindi crea: NodePool ``` apiVersion: karpenter.k8s.aws/v1 kind: EC2NodeClass metadata: name: odcr-gpu-production spec: amiSelectorTerms: - alias: al2023@latest subnetSelectorTerms: - tags: karpenter.sh/discovery: ml-cluster securityGroupSelectorTerms: - tags: karpenter.sh/discovery: ml-cluster capacityReservationSelectorTerms: - id: "cr-0987654321fedcba0" --- apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-reserved-production spec: disruption: consolidationPolicy: WhenEmpty consolidateAfter: Never template: spec: nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: odcr-gpu-production requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["reserved", "on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["p5", "g6e"] - key: "topology.kubernetes.io/zone" operator: In values: ["us-east-1a"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule ``` ------ ## On-Demand On-Demand è il tipo di capacità predefinito e può essere utilizzato con il provisioning statico o dinamico in EKS Auto Mode e Karpenter. Puoi richiedere On-Demand istanze in modo esplicito impostando il tuo. `karpenter.sh/capacity-type: on-demand` NodePool EKS Auto Mode e Karpenter selezionano l'istanza con il prezzo più basso che soddisfa le richieste di risorse del Pod. Utilizzala On-Demand per lo sviluppo, la prototipazione, la scalabilità inferenziale imprevedibile e qualsiasi carico di lavoro che richieda una disponibilità immediata senza rischi di interruzione. ------ #### [ EKS Auto Mode ] ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-ondemand spec: template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6", "g6e", "g7e"] - key: "karpenter.k8s.aws/instance-gpu-manufacturer" operator: In values: ["nvidia"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule ``` ------ #### [ Self-managed Karpenter ] ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-ondemand spec: template: spec: nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6", "g6e", "g7e"] - key: "karpenter.k8s.aws/instance-gpu-manufacturer" operator: In values: ["nvidia"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule ``` ------ ## Spot Spot offre risparmi fino al 90% rispetto all'utilizzo di capacità EC2 di riserva. On-Demand AWS può recuperare le istanze Spot con un avviso di interruzione di 2 minuti. Massimizza la disponibilità elencando più famiglie di istanze su. NodePool Associa i carichi di lavoro Spot a un checkpoint `PodDisruptionBudget` e a uno storage durevole (Amazon S3 o Amazon EFS) a intervalli regolari in modo che i Pod possano salvare lo stato durante la finestra di drenaggio. Spot è la soluzione ideale per carichi di lavoro di formazione e inferenza riutilizzabili e tolleranti ai guasti, in cui le interruzioni occasionali sono accettabili in cambio di significativi risparmi sui costi. I candidati più comuni includono: + **Ottimizzazione e scansione degli iperparametri**: molte prove brevi e parallele che possono essere riprovate se interrotte. + **Formazione distribuita con checkpointing**: processi di lunga durata che salvano periodicamente lo stato su S3 o FSx e possono riprendere dall'ultimo checkpoint dopo la perdita del nodo. + **Inferenza in batch e offline**: processi di assegnazione di punteggi su larga scala rispetto a set di dati in cui la latenza end-to-end viene misurata in ore, non in secondi. + **Preelaborazione dei dati e pipeline di ingegneria delle funzionalità**: trasformazioni parallele su set di dati di grandi dimensioni. + **Valutazione e benchmarking dei modelli**: lavori ripetibili che producono risultati idempotenti. + **Sviluppo, prototipazione e notebook**: sperimentazione interattiva in cui gli utenti possono tollerare riavvii occasionali. Evita Spot per inferenze in tempo reale sensibili alla latenza, endpoint di SLA-bound produzione e carichi di lavoro che non prevedono checkpoint o non tollerano riavvii. Puoi richiedere in modo esplicito istanze Spot impostando il tuo. `karpenter.sh/capacity-type: spot` NodePool ------ #### [ EKS Auto Mode ] EKS Auto Mode gestisce le interruzioni Spot in modo nativo. Non è richiesta alcuna coda SQS o Node Termination Handler. ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-spot spec: disruption: budgets: - nodes: 10% consolidationPolicy: WhenEmpty consolidateAfter: 1h template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["spot"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6", "g6e", "g7e"] - key: "karpenter.k8s.aws/instance-gpu-manufacturer" operator: In values: ["nvidia"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule limits: resources: nvidia.com/gpu: "64" ``` ------ #### [ Self-managed Karpenter ] Self-managed [Karpenter richiede di abilitare la gestione nativa delle interruzioni sul controller Karpenter (non su NodePool) configurando una coda di interruzione: una coda SQS che riceve gli eventi di interruzione Spot e Rebalance Recommendation di EC2.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/rebalance-recommendations.html) È possibile configurarla una sola volta al momento dell'installazione. Se installi Karpenter direttamente con Helm, imposta `settings.interruptionQueue` il tuo: `values.yaml` ``` # karpenter values.yaml (Helm) settings: clusterName: my-cluster interruptionQueue: my-queue # Name of the SQS queue receiving Spot events ``` Se avviate Karpenter con`eksctl`, `withSpotInterruptionQueue: true` impostatelo nel file di configurazione del cluster. `eksctl`crea la coda e le EventBridge regole SQS e configura il controller Karpenter per utilizzarle. ``` # eksctl ClusterConfig karpenter: version: "${KARPENTER_VERSION}" withSpotInterruptionQueue: true ``` Una volta che il controller è configurato per utilizzare la coda, non è necessaria alcuna configurazione aggiuntiva per le singole risorse. NodePool La gestione delle interruzioni si applica a livello di cluster. ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-spot spec: disruption: budgets: - nodes: 10% consolidationPolicy: WhenEmpty consolidateAfter: 1h template: spec: nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["spot"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6", "g6e", "g7e"] - key: "karpenter.k8s.aws/instance-gpu-manufacturer" operator: In values: ["nvidia"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule limits: resources: nvidia.com/gpu: "64" ``` ------