Controlla l’implementazione dei carichi di lavoro in Prenotazioni della capacità con la modalità automatica di EKS - Amazon EKS
EC2 Prenotazioni di capacità su richiesta () ODCRsEC2 Capacity Blocks per ML

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 capacità EC2 su richiesta (ODCRs) e i blocchi di EC2 capacità per il machine learning.

Suggerimento

Per impostazione predefinita, EKS Auto Mode si avvia automaticamente nei blocchi di capacità aperti ODCRs e ML. Quando viene utilizzata capacityReservationSelectorTerms nella NodeClass definizione, EKS Auto Mode non utilizzerà più automaticamente alcuna riserva di capacità aperta.

EC2 Prenotazioni di capacità su richiesta () ODCRs

EC2 Le prenotazioni di capacità su richiesta (ODCRs) ti consentono di riservare la capacità di calcolo per le tue EC2 istanze Amazon 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.

EC2 Capacity Blocks 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 EC2 UltraClusters, per una rete a bassa latenza, su scala petabit e non bloccante.

Per ulteriori informazioni sulle piattaforme e sui tipi di istanze supportati, consulta Capacity Blocks for ML nella Guida per l'utente. EC2

È possibile 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

  2. A NodePool che utilizza NodeClass e applica una macchia

  3. 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. È possibile ottenere questo ID dalla EC2 console.

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:

  • 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.

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

Risorse correlate