使用 EKS 自動模式控制工作負載部署至容量保留 - Amazon EKS

協助改進此頁面

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

使用 EKS 自動模式控制工作負載部署至容量保留

您可以控制工作負載部署至容量保留的方式。EKS 自動模式支援 EC2 隨需容量保留 (ODCR) 和適用於 ML 的 EC2 容量區塊。

提示

預設情況下,EKS 自動模式會自動在開放的 ODCR 與 ML 容量區塊中啟動資源。當在 NodeClass 定義中使用 capacityReservationSelectorTerms 時,EKS 自動模式將不再自動使用任何開放的容量保留。

EC2 隨需容量保留 (ODCR)

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

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 容量區塊

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

有關支援的平台和執行個體類型的詳細資訊,請參閱 EC2 使用者指南中的 ML 的容量區塊

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

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

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

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

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

範例 NodeClass

此 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 的節點類別

NodePool 範例

此 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 自動模式建立節點集區

範例 Pod

此範例 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