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à. La modalità automatica EKS supporta le prenotazioni di On-Demand capacità EC2 (ODCR), i blocchi di capacità EC2 per il machine learning e le prenotazioni di capacità interrompibili (IODCR).

Prenotazioni di On-Demand capacità EC2 (ODCR)

Le prenotazioni di On-Demand capacità EC2 (ODCR) ti consentono di riservare la capacità di elaborazione per le tue 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, modalità automatica di EKS si avvia automaticamente in ODCR aperti. Tuttavia, configurando capacityReservationSelectorTerms su a, puoi controllare in modo esplicito quali ODCR NodeClass vengono utilizzati dai tuoi carichi di lavoro. I nodi forniti utilizzando ODCR configurate avranno karpenter.sh/capacity-type: reserved e avranno priorità rispetto a quelli on-demand e spot. Una volta abilitata questa funzionalità, EKS Auto Mode non utilizzerà più automaticamente gli ODCR aperti, ma devono essere selezionati esplicitamente da un, in modo da consentirvi un controllo preciso sull'utilizzo della prenotazione della NodeClass capacità in tutto il 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 degli ODCR. 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, usando come target le ODCR 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 account o quando lavori con prenotazioni di capacità condivise.

Etichette di pianificazione per le prenotazioni di capacità

Quando si configura capacityReservationSelectorTerms su a NodeClass, i nodi forniti dalle prenotazioni di capacità vengono etichettati con etichette di pianificazione aggiuntive. È possibile utilizzare queste etichette come NodePool requisiti o vincoli di pianificazione dei pod (come l'affinità dei nodi) per controllare il posizionamento del carico di lavoro.

Queste etichette sono presenti solo sui nodi con. karpenter.sh/capacity-type: reserved

Prenotazioni di capacità interrompibili (IODCR)

Le prenotazioni di capacità interrompibile consentono di condividere la capacità di prenotazione della On-Demand capacità non utilizzata con altri carichi di lavoro all'interno dell'organizzazione. Riutilizzando la capacità inutilizzata come ODCR interrompibili, i carichi di lavoro adatti a operazioni flessibili e con tolleranza ai guasti, come l'elaborazione in batch e l'analisi dei dati, possono trarre vantaggio dalla capacità temporaneamente disponibile. I titolari delle prenotazioni possono recuperare la propria capacità in qualsiasi momento, mentre i consumatori di ODCR interrompibili riceveranno un avviso di interruzione prima della chiusura per consentire lo spegnimento o il checkpoint senza intoppi prima della chiusura del nodo.

Le prenotazioni di capacità interrompibile vengono selezionate utilizzando lo stesso metodo utilizzato per un ODCR standard: per ID o per tag. capacityReservationSelectorTerms Per controllare se i carichi di lavoro sono pianificati sulla capacità riservata interrompibile o non interrompibile, utilizza l'etichetta di pianificazione. eks.amazonaws.com/capacity-reservation-interruptible

Quando la capacità viene recuperata, le istanze in esecuzione ricevono un avviso di interruzione di 2 minuti tramite eventi. EventBridge Dopo il periodo di preavviso, le istanze in esecuzione nella capacità recuperata entrano in uno stato di spegnimento e vengono terminate. La modalità automatica EKS inizierà automaticamente a svuotare i nodi avviati dalle prenotazioni di capacità interrompibile quando viene ricevuto l'avviso di interruzione di 2 minuti, consentendo ai carichi di lavoro di terminare senza problemi prima che il nodo venga ripristinato.

Blocchi di capacità EC2 per ML

I Capacity Blocks for ML riservano istanze di elaborazione GPU-based accelerate in date future per supportare i 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 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:

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.

Esempio NodePool

Questo NodePool fa riferimento gpu NodeClass e specifica una configurazione importante:

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 la modalità automatica di EKS.

Pod di esempio

Questo pod di esempio dimostra come configurare un carico di lavoro da eseguire sui nodi del blocco di capacità:

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 nella documentazione Kubernetes.

Risorse correlate