Ayude a mejorar esta página

Para contribuir a esta guía del usuario, elija el enlace Edit this page on GitHub que se encuentra en el panel derecho de cada página.

Control de la implementación de las cargas de trabajo en las reservas de capacidad con el modo automático de EKS

Puede controlar la implementación de las cargas de trabajo en las reservas de capacidad. El modo automático de EKS admite reservas de capacidad bajo demanda (ODCR) de EC2 y bloques de capacidad de EC2 para ML.

Reservas de capacidad bajo demanda (ODCR) de EC2

Las reservas de capacidad bajo demanda (ODCR) de EC2 le permiten reservar capacidad de computación para sus instancias de Amazon EC2 en una zona de disponibilidad específica por cualquier período. Cuando utilice el modo automático de EKS, le recomendamos controlar si sus cargas de trabajo de Kubernetes se implementan en estas instancias reservadas para maximizar la utilización de la capacidad previamente adquirida o para garantizar que las cargas de trabajo críticas tengan acceso a los recursos garantizados.

De forma predeterminada, el modo automático de EKS se inicia automáticamente en las ODCR abiertas. Sin embargo, cuando configura capacityReservationSelectorTerms en una NodeClass, puede controlar de forma explícita cuáles ODCR utilizan sus cargas de trabajo. Los nodos aprovisionados mediante ODCR configuradas tendrán karpenter.sh/capacity-type: reserved y se priorizarán frente a los nodos bajo demanda y nodos de spot. Una vez habilitada esta característica, el modo automático de EKS ya no utilizará automáticamente las ODCR abiertas; deben seleccionarse explícitamente mediante una NodeClass, lo que le permite controlar con precisión el uso de las reservas de capacidad en todo el clúster.

Ejemplo de 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"

Este ejemplo de NodeClass muestra dos enfoques para seleccionar las ODCR. El primer método hace referencia directamente a una ODCR específica mediante su ID (cr-56fac701cc1951b03). El segundo método utiliza la selección basada en etiquetas y se dirige a las ODCR con la etiqueta Name: "targeted-odcr". También puede filtrar opcionalmente por la cuenta de AWS propietaria de la reserva, lo cual es particularmente útil en escenarios de varias cuentas o cuando se trabaja con reservas de capacidad compartida.

Bloques de capacidad de EC2 para ML

Los bloques de capacidad para ML reservan instancias de computación acelerada basadas en GPU en una fecha futura para admitir cargas de trabajo de machine learning (ML) de corta duración. Las instancias que se ejecutan en un bloque de capacidad se colocan automáticamente cerca dentro de Amazon EC2 UltraClusters para conseguir redes que no generen bloqueos, de escala de petabits y de baja latencia.

Para obtener más información acerca de las plataformas y los tipos de instancias compatibles, consulte Bloques de capacidad para ML en la Guía del usuario de EC2.

Puede crear una NodeClass del modo automático EKS que utilice un bloque de capacidad para ML, similar a una ODCR (descrita anteriormente).

Los siguientes ejemplos de definiciones crean tres recursos:

Ejemplo de NodeClass

Esta NodeClass hace referencia a un bloque de capacidad específico para ML mediante su ID de reserva. Puede obtener este ID en la consola de EC2.

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

Para obtener más información, consulte Cómo crear una clase de nodos para Amazon EKS.

NodePool de muestra

Este NodePool hace referencia a la NodeClass gpu y especifica una configuración 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

Para obtener más información, consulte Creación de un grupo de nodos para el modo automático de EKS.

Pod de ejemplo

Este pod de ejemplo muestra cómo configurar una carga de trabajo para que se ejecute en los nodos del bloque de capacidad:

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

Para obtener más información, consulte Pods en la documentación de Kubernetes.

Activos relacionados