EKS Auto Mode e Karpenter Etichette note comuni AI/ML Etichette di pianificazione per la capacità riservata Comportamento alla scadenza della prenotazione Capacità statica NodePools Blocchi di capacità per ML On-Demand Prenotazioni di capacità (ODCR)On-Demand Spot

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 l'elaborazione per i AI/ML carichi di lavoro con EKS Auto Mode e Karpenter

Suggerimento

AI/ML Registrati per i prossimi workshop Amazon EKS.

Questa sezione spiega come gestire l'elaborazione accelerata (AWS Trainium, GPU NVIDIA) per l'addestramento e i carichi di lavoro di 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 eseguono il provisioning e la scalabilità delle istanze di calcolo accelerate man mano che i carichi di lavoro vengono pianificati sul cluster. Con il provisioning statico, EKS Auto Mode e Karpenter forniscono e mantengono un numero fisso di nodi. Il provisioning dinamico e statico può essere utilizzato nello stesso cluster per mantenere un pool di capacità di base costante e scalare in base alle esigenze 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 e Karpenter

Entrambi gli approcci condividono l' NodePool API, ma si differenziano 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 del ciclo di vita dei nodi, delle AMI, dell'ottimizzazione del sistema operativo e dell'applicazione delle patch.
Modello operativo	AWS fornisce e gestisce il controller Karpenter, GPU/Trainium i driver, i plug-in dei dispositivi, le patch del sistema operativo e la gestione delle interruzioni Spot.	L'utente installa e utilizza il controller Karpenter nel cluster e dispone di GPU/Trainium driver, plug-in di dispositivo, ciclo di vita dell'AMI, applicazione di patch e gestione delle interruzioni Spot.
Opzioni di calcolo	On-Demand, Spot, ODCRS, Capacity Blocks for ML	On-Demand, Spot, ODCRs, blocchi di capacità per ML
API per le 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 dei nodi e i budget per le NodePool `expireAfter` interruzioni.
Gestione istantanea delle interruzioni	Nativo. Non è richiesta alcuna coda SQS o Node Termination Handler.	La tua responsabilità di configurare e abilitare.
Estrazione rapida dei contenitori	Pull parallelo SOCI incluso in tutte le istanze delle famiglie G, P e Trn	La tua responsabilità di configurare e abilitare.
Gruppi di collocamento EC2	Cluster, partizione, diffusione	Cluster, partizione, diffusione
Configurazione dell'interfaccia di rete	Per configurazione dell'interfaccia per tipo `interface` o `EFA-only`	Per configurazione di interfaccia per tipo `interface` o `EFA-only`
Riparazione dei nodi	Abilitato per impostazione predefinita, è incluso l'agente di monitoraggio dei nodi EKS	Opzionalmente abilitato, agente di monitoraggio dei nodi EKS autogestito
Prezzi	Tariffa di gestione EKS Auto Mode in aggiunta al costo dell'istanza EC2 sottostante.	Open source. Paghi per le istanze EC2 sottostanti.

Etichette note comuni AI/ML

EKS Auto Mode e Karpenter espongono le etichette delle istanze che è possibile utilizzare in Pod nodeSelector o nodeAffinity per indirizzare NodePool requirements i carichi di lavoro senza l'hardcoding dei tipi di istanza. 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 inoltre le etichette elencate nella documentazione di Karpenter ai nodi come parte del processo di provisioning che può essere ulteriormente utilizzato per il targeting dei carichi di lavoro.

EKS Auto Mode

Per l'elenco completo, vedi Etichette supportate da EKS Auto Mode. 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, consulta Karpenter Labels Well-Known .

Etichetta	Valore di esempio	Description
`karpenter.k8s.aws/instance-family`	`p5`	Tipi di istanza 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 avviano un nodo in una prenotazione, aggiungono le seguenti etichette. Usali innodeSelector, affinità dei nodi o NodePool requisiti per indirizzare i carichi di lavoro.

karpenter.sh/capacity-type:reserved,on-demand, o. spot Indica la capacità di supporto 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 gli ODCR, capacity-block per i blocchi di capacità.

Gli esempi seguenti mostrano i modelli di pianificazione più comuni:

Aggiungi un Pod a una prenotazione specifica (senza riserva):


spec:
  nodeSelector:
    karpenter.sh/capacity-type: reserved
    karpenter.k8s.aws/capacity-reservation-id: "cr-0123456789abcdef0"

Solo nodi ODCR di destinazione (qualsiasi ODCR, non blocchi di capacità):


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 torna 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 alla scadenza della prenotazione

Gli ODCR e i Capacity Block si comportano diversamente al termine della prenotazione. Assicurati che la tua strategia di pianificazione e checkpoint corrisponda al tipo di prenotazione che sostiene il tuo carico di lavoro.

ODCR

Un'istanza avviata in un ODCR non rimane 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 una restrizione non nodeSelector: karpenter.sh/capacity-type: reserved verrà programmato sul nodo se è stato rietichettato. Affinché i carichi di lavoro sopravvivano alla scadenza o all'annullamento dell'ODCR, utilizza lo preferredDuringSchedulingIgnoredDuringExecution schema mostrato sopra anziché un. nodeSelector

Blocchi di capacità

A differenza degli ODCR, i Capacity Block hanno sempre un'ora di fine e 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 una restrizione nodeSelector per un determinato periodo vengono eliminati una capacity-reservation-id Pending volta scaduto il blocco e non verranno riprogrammati altrove. Combina il checkpoint con il modello di affinità flessibile sopra riportato se hai bisogno che i carichi di lavoro passino ad altra 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 UltraServer istanza.
EKS Auto Mode e Karpenter iniziano preventivamente a svuotare 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 un 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 le inferenze sensibili alla latenza e consentono di riservare un ingombro minimo all'infrastruttura del cluster.

La capacità statica viene configurata impostando il campo su. replicas NodePool

Considerazioni

Una volta replicas impostata su a NodePool, non è possibile rimuoverla. Non è NodePool possibile passare dalla fornitura di capacità statica a quella dinamica e viceversa.
La capacità statica non NodePools viene considerata per il consolidamento. Impostata 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), create 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 ne crea una statica NodePool con 4 nodi (replicas) che può contenere 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 funzionalità 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 consentono di P-family riservare istanze di Trainium per una finestra futura definita. Sono prepagate, quindi EKS Auto Mode e Karpenter le modellano come gratuite e danno loro priorità rispetto a Spot. On-Demand I Capacity Blocks for ML possono avere una durata di prenotazione di 1-14 giorni o multipli di 7 giorni, fino a 182 giorni (6 mesi).

Per utilizzare Capacity Blocks for ML con EKS Auto Mode o Karpenter, configuralo inserendo l'ID capacityReservationSelectorTerms di prenotazione della capacità nel tuo. NodeClass Non è possibile utilizzare la corrispondenza delle prenotazioni aperte con Capacity Blocks for ML. Un termine può specificare un ID, un set di tag o criteri di corrispondenza delle istanze tra cui effettuare la selezione. Quando si specificano i tag, selezionerà tutte le prenotazioni di capacità accessibili dall'account con i tag corrispondenti. Questo può essere ulteriormente limitato specificando l'ID dell'account del proprietario.

Per altri esempi, consulta la documentazione di Karpenter.

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 impacchettare 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 anche selettori di AMI, subnet e gruppi di sicurezzacapacityReservationSelectorTerms, 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 comprimere 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 specifica zona di disponibilità (AZ) senza un impegno a lungo termine. La fatturazione prevede 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 priorità rispetto a Spot. On-Demand

Gli ODCR si comportano diversamente dai 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 alla scadenza della prenotazione.

Per utilizzare gli ODCR con EKS Auto Mode o Karpenter, configura capacityReservationSelectorTerms i termini di prenotazione della capacità nel tuo. NodeClass Un termine può specificare un ID, un set di tag o criteri di corrispondenza delle istanze tra cui effettuare la selezione. Quando si specificano 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: aperto (corrisponde a tutte le istanze compatibili) o targetizzato (corrisponde solo alle istanze mirate esplicitamente). Questo può essere ulteriormente limitato specificando l'ID dell'account del proprietario.

Per altri esempi, consulta la documentazione di Karpenter.

EKS Auto Mode

Crea un NodeClass con capacityReservationSelectorTerms e un NodePool che dia priorità reserved con fallback. on-demand Aggiungi topology.kubernetes.io/zone all'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, subnet e gruppo di sicurezza oltre acapacityReservationSelectorTerms, 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 esplicitamente le On-Demand istanze 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. Utilizzalo On-Demand per lo sviluppo, la prototipazione, il ridimensionamento imprevedibile delle inferenze e qualsiasi carico di lavoro che richieda una disponibilità immediata senza rischi di interruzione.

Spot

Spot offre un risparmio fino al 90% rispetto all'utilizzo di capacità EC2 di riserva. On-Demand AWS può recuperare le istanze Spot con un preavviso 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 and allo storage durevole (Amazon S3 o Amazon EFS) a intervalli regolari in modo che i Pods possano salvare lo stato durante la finestra di esaurimento.

Spot è la soluzione ideale per carichi di lavoro di formazione e inferenza riprendibili e tolleranti ai guasti, in cui un'interruzione occasionale è accettabile in cambio di significativi risparmi sui costi.

I candidati più comuni includono:

Ottimizzazione e scansione degli iperparametri: molte brevi prove parallele che possono essere ritentate se interrotte.
Formazione distribuita con checkpoint: processi di lunga durata che salvano periodicamente lo stato in S3 o FSx e possono riprendere dall'ultimo checkpoint dopo la perdita del nodo.
Inferenza batch e offline: 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.
Pipeline di preelaborazione dei dati e 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 superano il checkpoint o non possono tollerare i riavvii.

Puoi richiedere esplicitamente le istanze Spot impostando il tuo. karpenter.sh/capacity-type: spot NodePool

EKS Auto Mode

La modalità automatica EKS 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 sul NodePool) configurando una coda di interruzione: una coda SQS che riceve gli eventi EC2 Spot interruption e Rebalance Recommendation. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/rebalance-recommendations.html Questa operazione viene configurata una volta al momento dell'installazione.

Se installi Karpenter direttamente con Helm, impostasettings.interruptionQueue: values.yaml


# karpenter values.yaml (Helm)
settings:
  clusterName: my-cluster
  interruptionQueue: my-queue   # Name of the SQS queue receiving Spot events

Se avvii Karpenter coneksctl, withSpotInterruptionQueue: true impostalo nel file di configurazione del cluster. eksctlcrea 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 è impostato per utilizzare la coda, non è necessaria alcuna configurazione aggiuntiva sulle singole risorse. NodePool La gestione delle interruzioni si applica a tutto il 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"

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Gestione della capacità

Gruppi di nodi gestiti e nodi autogestiti