Contribuisci a migliorare questa pagina

Per contribuire a questa guida per l’utente, seleziona il link Edit this page on GitHub che si trova nel riquadro destro di ogni pagina.

Controlla l’implementazione dei carichi di lavoro in Prenotazioni della capacità con EKS Auto Mode

Puoi controllare l’implementazione dei carichi di lavoro su Prenotazioni della capacità. EKS Auto Mode supporta le prenotazioni della capacità on demand EC2 (ODCR) e i blocchi di capacità EC2 per il machine learning.

Prenotazioni della capacità on demand di EC2 (ODCR)

Le prenotazioni della capacità on demand di EC2 (ODCR) permettono di prenotare la capacità di elaborazione per le istanze Amazon EC2 in una zona di disponibilità specifica per qualsiasi durata. Quando si utilizza EKS Auto Mode, 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 avvia automaticamente in ODCR aperti. Tuttavia, configurando capacityReservationSelectorTerms su una NodeClass, puoi controllare in modo esplicito quali ODCR vengono utilizzate dai 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: devono essere selezionati esplicitamente da un NodeClass, offrendoti un controllo preciso sull’utilizzo della prenotazione della capacità nel cluster.

NodeClass di esempio

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"

Questa NodeClass di esempio illustra due approcci per la selezione delle 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 possibile filtrare in base all’account AWS che possiede la prenotazione, il che è particolarmente utile negli scenari tra account o quando si lavora con prenotazioni della capacità condivise.

Blocchi di capacità EC2 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 in un blocco di capacità vengono automaticamente posizionate vicine tra loro all’interno degli UltraClusters Amazon EC2 per garantire capacità di rete senza blocchi nell’ordine dei petabit a latenza minima.

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 NodeClass in EKS Auto Mode che utilizza un blocco di capacità per ML, in modo simile a un ODCR (descritto in precedenza).

Le seguenti definizioni di esempio creano tre risorse:

NodeClass di esempio

Questa NodeClass fa riferimento a uno specifico blocco di capacità per 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.

NodePool di esempio

Questo NodePool fa riferimento alla NodeClass gpu 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 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à:

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