Aidez à améliorer cette page

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Contrôle du déploiement des charges de travail dans les réserves de capacité avec le mode automatique EKS

Vous pouvez contrôler le déploiement des charges de travail dans des réserves de capacité. Le mode automatique EKS prend en charge les réserves de capacité à la demande (On-Demand Capacity Reservation, ODCR) EC2 ainsi que les blocs de capacité EC2 pour le ML.

Réservations de capacité à la demande EC2 () ODCRs

Les réserves de capacité à la demande (ODCR) EC2 permettent de réserver de la capacité de calcul pour vos instances Amazon EC2 dans une zone de disponibilité spécifique, pour toute durée souhaitée. Lorsque vous utilisez le mode automatique EKS, vous pouvez vouloir contrôler le déploiement de vos charges de travail Kubernetes sur ces instances réservées afin de maximiser l’utilisation de la capacité préachetée ou garantir l’accès des charges de travail critiques à des ressources dédiées.

Par défaut, le mode automatique EKS démarre automatiquement en mode ouvert ODCRs. Cependant, en configurant capacityReservationSelectorTerms sur un NodeClass, vous pouvez contrôler explicitement les charges de travail utilisées par ODCRs vos charges de travail. Les nœuds approvisionnés à l'aide de la configuration ODCRs auront karpenter.sh/capacity-type: reserved et seront priorisés par rapport à la demande et au spot. Une fois cette fonctionnalité activée, le mode automatique d'EKS n'utilisera plus automatiquement les options ouvertes. ODCRs Elles doivent être explicitement sélectionnées par un NodeClass, ce qui vous permet de contrôler précisément l'utilisation des réservations de capacité au sein de votre cluster.

Exemple 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"

Cet exemple NodeClass illustre deux approches de sélection ODCRs. La première méthode fait référence directement à une ODCR spécifique à l’aide de son ID (cr-56fac701cc1951b03). La seconde méthode utilise la sélection basée sur les balises, le ciblage à l' ODCRs aide de la baliseName: "targeted-odcr". Vous pouvez également éventuellement filtrer en fonction du AWS compte propriétaire de la réservation, ce qui est particulièrement utile dans les scénarios entre comptes ou lorsque vous travaillez avec des réservations à capacité partagée.

Blocs de capacité EC2 pour ML

Les blocs de capacité pour ML vous permettent de réserver à l’avance des instances de calcul accéléré basées sur GPU pour exécuter des charges de travail de machine learning (ML) de courte durée. Les instances qui s'exécutent au sein d'un bloc de capacité sont automatiquement placées à proximité les unes des autres dans Amazon EC2 UltraClusters, pour une mise en réseau non bloquante à faible latence, à l'échelle du pétabit.

Pour plus d’informations sur les plateformes et les types d’instances pris en charge, consultez Blocs de capacité ML dans le Guide de l’utilisateur EC2.

Vous pouvez créer un mode automatique EKS NodeClass qui utilise un bloc de capacité pour le ML, similaire à un ODCR (décrit précédemment).

Les exemples de définitions suivants créent trois ressources :

Exemple NodeClass

Cela NodeClass fait référence à un bloc de capacité spécifique pour ML par son ID de réservation. Vous pouvez obtenir cet ID dans la console EC2.

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: gpu
spec:
  # Specify your Capacity Block reservation ID
  capacityReservationSelectorTerms:
    - id: cr-56fac701cc1951b03

Pour de plus amples informations, veuillez consulter Création d’une classe de nœuds pour Amazon EKS.

Exemple NodePool

Cela NodePool fait référence à la configuration importante gpu NodeClass et précise :

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

Pour de plus amples informations, veuillez consulter Create a Node Pool for EKS Auto Mode.

Exemple de pod

Cet exemple de pod montre comment configurer une charge de travail afin qu’elle s’exécute sur vos nœuds de bloc de 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

Pour plus d'informations, consultez pods dans la documentation Kubernetes.

Ressources connexes