

 **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
<a name="auto-odcr"></a>

Puede controlar la implementación de las cargas de trabajo en las [reservas de capacidad](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html). El modo automático de EKS admite reservas de capacidad bajo demanda (ODCR) de EC2 y bloques de capacidad de EC2 para ML.

**sugerencia**  
De forma predeterminada, el modo automático de EKS se puede iniciar en los ODCR abiertos mediante la coincidencia abierta, pero no los prioriza. Las instancias lanzadas mediante una coincidencia abierta se etiquetan con `karpenter.sh/capacity-type: on-demand`, no con `reserved`. Para priorizar el uso de ODCR y etiquetar las instancias con `karpenter.sh/capacity-type: reserved`, configure `capacityReservationSelectorTerms` en la definición de NodeClass. Los bloques de capacidad para ML siempre requieren `capacityReservationSelectorTerms` y no se utilizan automáticamente.

## Reservas de capacidad bajo demanda (ODCR) de EC2
<a name="_ec2_on_demand_capacity_reservations_odcrs"></a>

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.

**aviso**  
Si configura `capacityReservationSelectorTerms` en una NodeClass de un clúster, el modo automático de EKS ya no utilizará automáticamente las ODCR abiertas para *ninguna* NodeClass del clúster.

### Ejemplo de NodeClass
<a name="_example_nodeclass"></a>

```
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
<a name="_ec2_capacity_blocks_for_ml"></a>

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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) 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:

1. Una NodeClass que hace referencia a la reserva del bloque de capacidad

1. Un NodePool que usa la NodeClass y aplica una taint

1. Una especificación de pod que tolera la taint y solicita recursos de la GPU

### Ejemplo de NodeClass
<a name="_example_nodeclass_2"></a>

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](create-node-class.md).

### NodePool de muestra
<a name="_example_nodepool"></a>

Este NodePool hace referencia a la NodeClass `gpu` y especifica una configuración importante:
+ **Solo** usa la capacidad reservada mediante la configuración `karpenter.sh/capacity-type: reserved`. 
+ Solicita familias de instancias de GPU específicas adecuadas para las cargas de trabajo de ML.
+ Aplica una taint `nvidia.com/gpu` para garantizar que solo las cargas de trabajo de GPU estén programadas en estos nodos

```
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](create-node-pool.md).

### Pod de ejemplo
<a name="_example_pod"></a>

Este pod de ejemplo muestra cómo configurar una carga de trabajo para que se ejecute en los nodos del bloque de capacidad:
+ Utiliza un **nodeSelector** para usar como destino tipos de GPU específicos (en este caso, GPU H200).
+ Incluye una **tolerancia** a la taint `nvidia.com/gpu` aplicada por el NodePool.
+ **Solicita explícitamente los recursos de la GPU** mediante el tipo de recurso `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
```

Para obtener más información, consulte [Pods](https://kubernetes.io/docs/concepts/workloads/pods/) en la documentación de Kubernetes.

### Activos relacionados
<a name="_related_resources"></a>
+  [Bloques de capacidad para ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) en la Guía del usuario de Amazon EC2
+  [Búsqueda y compra de bloques de capacidad](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html) en la Guía del usuario de Amazon EC2
+  [Administración de los recursos computacionales para las cargas de trabajo de IA/ML en Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html) 
+  [Optimización de recursos de GPU y administración de costos](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management) en la Guía de prácticas recomendadas de EKS