**協助改進此頁面** 

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的**在 GitHub 上編輯此頁面**連結。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 使用 EKS 自動模式控制工作負載部署至容量保留
<a name="auto-odcr"></a>

您可以控制工作負載部署至[容量保留](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html)的方式。EKS 自動模式支援 EC2 隨需容量保留 (ODCR) 和適用於 ML 的 EC2 容量區塊。

**提示**  
根據預設，EKS Auto Mode 可以透過開放比對在開放 ODCRs 中啟動，但不會排定它們的優先順序。透過開放比對啟動的執行個體會標記為 `karpenter.sh/capacity-type: on-demand`，而不是 `reserved`。若要排定 ODCR 用量的優先順序，並讓執行個體標記為 `karpenter.sh/capacity-type: reserved`，請在 NodeClass 定義`capacityReservationSelectorTerms`中設定 。ML 的容量區塊一律需要`capacityReservationSelectorTerms`且不會自動使用。

## EC2 隨需容量保留 (ODCR)
<a name="_ec2_on_demand_capacity_reservations_odcrs"></a>

EC2 隨需容量保留 (ODCR) 可讓您在特定可用區域中，為 Amazon EC2 執行個體保留任何期限的運算容量。使用 EKS 自動模式時，您可能希望控制您的 Kubernetes 工作負載是否部署到這些保留執行個體上，以最大化預購容量的利用率，或確保關鍵工作負載能夠存取保證的資源。

預設情況下，EKS 自動模式會自動啟動到開放的 ODCR 中。但是，透過在 NodeClass 上設定 `capacityReservationSelectorTerms`，您可以明確控制您的工作負載使用哪些 ODCR。透過已設定 ODCR 佈建的節點會帶有 `karpenter.sh/capacity-type: reserved` 標籤，且其優先順序高於隨需與 Spot 執行個體。啟用此功能後，EKS 自動模式將不再自動使用開放的 ODCR，必須透過 NodeClass 明確選取這些 ODCR，讓您能精確控制叢集中容量保留的使用情況。

**警告**  
若您在叢集中的某個 NodeClass 上設定 `capacityReservationSelectorTerms`，則 EKS 自動模式將不再為叢集中*任何* NodeClass 自動使用開放的 ODCR。

### 範例 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"
```

此範例 NodeClass 示範了兩種選取 ODCR 的方式。第一種方式透過 ODCR 的 ID (`cr-56fac701cc1951b03`) 直接參考特定 ODCR。第二種方式使用基於標籤的選取邏輯，目標為帶有 `Name: "targeted-odcr"` 標籤的 ODCR。您也可以選擇性地依擁有保留 AWS 的帳戶進行篩選，這在跨帳戶案例或處理共用容量保留時特別有用。

## ML 的 EC2 容量區塊
<a name="_ec2_capacity_blocks_for_ml"></a>

ML 的容量區塊可讓您為日後預留基於 GPU 的加速運算執行個體，以支援短時間的機器學習 (ML) 工作負載。容量區塊內執行的執行個體會在 Amazon EC2 UltraCluster 內自動放置於鄰近位置，以實現低延遲、Pb 級的非阻塞式聯網。

有關支援的平台和執行個體類型的詳細資訊，請參閱 EC2 使用者指南中的 [ML 的容量區塊](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)。

您可以建立使用 ML 的容量區塊的 EKS 自動模式 NodeClass，類似於 ODCR (先前說明)。

以下範例定義會建立了三個資源：

1. 一個引用您的容量區塊保留的 NodeClass

1. 一個使用該 NodeClass 並套用污點的 NodePool

1. 一個容忍該污點並請求 GPU 資源的 Pod 規格

### 範例 NodeClass
<a name="_example_nodeclass_2"></a>

此 NodeClass 透過其保留 ID 引用特定 ML 的容量區塊。您可從 EC2 主控台取得此 ID。

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

如需詳細資訊，請參閱[建立 Amazon EKS 的節點類別](create-node-class.md)。

### NodePool 範例
<a name="_example_nodepool"></a>

此 NodePool 引用了 `gpu` NodeClass 並指定了重要組態：
+ 它透過設定 `karpenter.sh/capacity-type: reserved` **僅**使用預留容量 
+ 它請求適合 ML 工作負載的特定 GPU 執行個體系列
+ 它會套用 `nvidia.com/gpu` 污點，確保僅 GPU 工作負載會排程至這些節點

```
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
```

如需詳細資訊，請參閱[為 EKS 自動模式建立節點集區](create-node-pool.md)。

### 範例 Pod
<a name="_example_pod"></a>

此範例 Pod 示範了如何設定要在容量區塊節點上執行的工作負載：
+ 它使用 **nodeSelector**，以特定 GPU 類型為目標 (此處為 H200 GPU)
+ 它包含對 NodePool 所套用 `nvidia.com/gpu` 污點的**容差**
+ 它使用 `nvidia.com/gpu` 資源類型明確**請求 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
```

如需詳細資訊，請參閱 Kubernetes 文件中的 [Pod](https://kubernetes.io/docs/concepts/workloads/pods/)。

### 相關資源
<a name="_related_resources"></a>
+  《Amazon EC2 使用者指南》中的 [ML 的容量區塊](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)
+  《Amazon EC2 使用者指南》中的[尋找和購買容量區塊](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html)
+  [管理 Amazon EKS 上 AI/ML 工作負載的運算資源](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html) 
+  《EKS 最佳實務指南》中的 [GPU 資源最佳化和成本管理](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management)