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 d'EKS prend en charge les réservations de On-Demand capacité EC2 (ODCR), les blocs de capacité EC2 pour le ML et les réservations de capacité interruptible (IODCR).

Réservations de On-Demand capacité EC2 (ODCR)

Les réservations de On-Demand capacité EC2 (ODCR) vous permettent de réserver de la capacité de calcul pour vos instances Amazon EC2 dans une zone de disponibilité spécifique pour une durée quelconque. 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 lance automatiquement les charges de travail dans les ODCR ouvertes. Cependant, en configurant capacityReservationSelectorTerms sur un NodeClass, vous pouvez contrôler explicitement les ODCR utilisés par vos charges de travail. Les nœuds provisionnés à l’aide d’ODCR configurées auront karpenter.sh/capacity-type: reserved et seront prioritaires par rapport aux instances à la demande et Spot. Une fois cette fonctionnalité activée, le mode automatique d'EKS n'utilisera plus automatiquement les ODCR ouverts. Ils doivent être explicitement sélectionnés 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 pour sélectionner les ODCR. 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 une sélection basée sur des balises, ciblant les ODCR portant la balise Name: "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.

Étiquettes de planification pour les réservations de capacité

Lorsque vous configurez capacityReservationSelectorTerms sur un NodeClass, les nœuds approvisionnés à partir de réservations de capacité sont étiquetés avec des étiquettes de planification supplémentaires. Vous pouvez utiliser ces étiquettes comme NodePool exigences ou comme contraintes de planification des pods (telles que l'affinité des nœuds) pour contrôler le placement de la charge de travail.

Ces étiquettes ne sont présentes que sur les nœuds dotés dekarpenter.sh/capacity-type: reserved.

Réservations de capacité interruptible (IODCR)

Les réservations de capacité interruptibles vous permettent de partager la capacité de réservation de On-Demand capacité inutilisée avec d'autres charges de travail au sein de votre organisation. En réaffectant la capacité inutilisée en ODCR interruptibles, les charges de travail adaptées aux opérations flexibles et tolérantes aux pannes, telles que le traitement par lots et l'analyse de données, peuvent bénéficier de la capacité temporairement disponible. Les propriétaires de réservations peuvent récupérer leur capacité à tout moment, tandis que les consommateurs d'ODCR interruptibles recevront un avis d'interruption avant la résiliation afin de permettre un arrêt ou un contrôle progressif avant la fermeture du nœud.

Vous sélectionnez les réservations de capacité interruptible de capacityReservationSelectorTerms la même manière que vous le feriez avec un ODCR standard : par identifiant ou par balises. Pour contrôler si les charges de travail sont planifiées en fonction de la capacité réservée interruptible ou non interruptible, utilisez l'étiquette de planification. eks.amazonaws.com/capacity-reservation-interruptible

Lorsque la capacité est récupérée, les instances en cours d'exécution reçoivent un avertissement d'interruption de 2 minutes par le biais EventBridge d'événements. Après la période de préavis, les instances en cours d'exécution avec la capacité récupérée entrent dans un état d'arrêt et sont résiliées. Le mode automatique d'EKS commence automatiquement à vider les nœuds lancés à partir de réservations de capacité interruptible lorsque l'avertissement d'interruption de 2 minutes est reçu, ce qui permet à vos charges de travail de s'arrêter correctement avant que le nœud ne soit récupéré.

Blocs de capacité EC2 pour ML

Les blocs de capacité pour le machine learning réservent des instances de calcul GPU-based accéléré à une date future afin de prendre en charge vos charges de travail d'apprentissage automatique (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 Création d’un pool de nœuds pour le mode automatique EKS.

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