View a markdown version of this page

使用 EKS Auto Mode 和 Karpenter 管理 AI/ML 工作負載的運算 - Amazon EKS

協助改進此頁面

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

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

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

使用 EKS Auto Mode 和 Karpenter 管理 AI/ML 工作負載的運算

提示

註冊即將舉行的 Amazon EKS AI/ML 研討會。

本節說明如何使用 Amazon EKS Auto Mode 或自我管理 Karpenter 管理 AI 訓練和推論工作負載的加速運算 (AWS Trainium、NVIDIA GPUs)。

EKS Auto Mode 和 Karpenter 支援兩種佈建模式:動態佈建和靜態佈建。使用動態佈建時,EKS Auto Mode 和 Karpenter 會在叢集上排程工作負載時佈建和擴展加速運算執行個體。使用靜態佈建時,EKS Auto Mode 和 Karpenter 會佈建和維護固定數量的節點。動態和靜態佈建可用於相同叢集,以維持固定的基準容量集區,同時隨著工作負載需求進行擴展。

EKS Auto Mode 和 Karpenter 支援所有四個容量購買選項 (隨需、Spot、容量區塊和 ODCRs),並一律先佈建預留容量,接著是 Spot 或隨需。

EKS 自動模式與 Karpenter

這兩種方法共用 NodePool API,但在操作擁有權、資源 APIs、作業系統支援、Spot 中斷處理和組態彈性方面有所不同。

功能 EKS 自動模式 自我管理 Karpenter

最適合

偏好營運負荷最少的受管基礎設施團隊

偏好完全控制節點生命週期、AMIs、作業系統調校和修補的團隊。

操作模型

AWS 佈建和管理 Karpenter 控制器、GPU/Trainium 驅動程式、裝置外掛程式、作業系統修補和 Spot 中斷處理。

您可以在叢集中安裝和操作 Karpenter 控制器,以及自己的 GPU/Trainium 驅動程式、裝置外掛程式、AMI 生命週期、修補和 Spot 中斷處理。

運算選項

隨需、Spot、ODCRs、ML 的容量區塊

隨需、Spot、ODCRs、ML 的容量區塊

資源 APIs

NodePool (karpenter.sh/v1), NodeClass (eks.amazonaws.com/v1).

NodePool (karpenter.sh/v1), EC2NodeClass (karpenter.k8s.aws/v1).

節點作業系統

僅限 Bottlerocket。包含 NVIDIA GPU、 AWS Trainium 和 EFA 相依性。

AL2023、 Bottlerocket、Windows 或您自己的 AMI。

節點生命週期

安全性修補的 21 天最大節點生命週期。工作負載必須容忍節點輪換。

您可以透過 NodePool expireAfter和中斷預算定義節點生命週期。

Spot 中斷處理

原生。不需要 SQS 佇列或節點終止處理常式。

您設定和啟用 的責任。

快速容器提取

所有 G、P 和 Trn 系列執行個體中都包含 SOCI 平行提取

您設定和啟用 的責任。

EC2 置放群組

叢集、分割區、分散

叢集、分割區、分散

網路界面組態

不支援

類型 interface或 的每個界面組態 EFA-only

節點修復

根據預設,包含 EKS 節點監控代理程式

選擇性地啟用 EKS 節點監控代理程式自我管理

定價

除了基礎 EC2 執行個體成本外,還需支付 EKS Auto Mode 管理費

開放原始碼。您支付基礎 EC2 執行個體的費用。

常見的 AI/ML 已知標籤

EKS Auto Mode 和 Karpenter 會公開您可以在 NodePool requirements和 Pod 中使用的執行個體標籤nodeAffinitynodeSelector或在沒有硬式編碼執行個體類型的目標工作負載。標籤字首在兩者之間不同:EKS Auto Mode 使用 eks.amazonaws.com/,而自我管理的 Karpenter 使用 karpenter.k8s.aws/

下表顯示可在 NodePools 中使用的相關標籤。EKS Auto Mode 和 Karpenter 也會將 Karpenter 文件中列出的標籤套用至節點,做為佈建程序的一部分,可進一步用於工作負載目標。

EKS Auto Mode

如需完整清單,請參閱 EKS Auto Mode 支援的標籤

標籤 範例值 說明

eks.amazonaws.com/instance-family

p5

類似屬性的執行個體類型,但資源數量不同。

eks.amazonaws.com/instance-category

p

執行個體類別,通常是產生編號之前的字母。

eks.amazonaws.com/instance-generation

5

類別內的執行個體類型產生號碼。

eks.amazonaws.com/instance-gpu-name

h100

執行個體上的 GPU 名稱。

eks.amazonaws.com/instance-gpu-manufacturer

nvidia

GPU 製造商的名稱。

eks.amazonaws.com/instance-gpu-count

8

執行個體上的 GPUs 數量。

eks.amazonaws.com/instance-gpu-memory

81920

每個 GPU 的記憶體 MB 數。

karpenter.sh/capacity-type

reserved

容量類型:spoton-demandreserved

topology.kubernetes.io/zone

us-east-1a

可用區域。

Self-managed Karpenter

如需完整清單,請參閱 Karpenter Well-Known 標籤

標籤 範例值 說明

karpenter.k8s.aws/instance-family

p5

類似屬性的執行個體類型,但資源數量不同。

karpenter.k8s.aws/instance-category

p

執行個體類別,通常是產生編號之前的字母。

karpenter.k8s.aws/instance-generation

5

類別內的執行個體類型產生號碼。

karpenter.k8s.aws/instance-gpu-name

h100

執行個體上的 GPU 名稱。

karpenter.k8s.aws/instance-gpu-manufacturer

nvidia

GPU 製造商的名稱。

karpenter.k8s.aws/instance-gpu-count

8

執行個體上的 GPUs 數量。

karpenter.sh/capacity-type

reserved

容量類型:spoton-demandreserved

topology.kubernetes.io/zone

us-east-1a

可用區域。

kubernetes.io/arch

amd64

CPU 架構。

排程預留容量的標籤

當 EKS Auto Mode 或 Karpenter 在保留中啟動節點時,它會新增下列標籤。在 nodeSelector、節點親和性或 NodePool 需求中使用它們來路由工作負載。

  • karpenter.sh/capacity-typereservedon-demandspot。指出備份節點的容量。

  • karpenter.k8s.aws/capacity-reservation-id:啟動節點的特定保留 ID。

  • karpenter.k8s.aws/capacity-reservation-typedefault適用於 ODCRs,capacity-block適用於容量區塊。

下列範例顯示常見的排程模式:

將 Pod 固定到一個特定的保留 (無備用):

spec: nodeSelector: karpenter.sh/capacity-type: reserved karpenter.k8s.aws/capacity-reservation-id: "cr-0123456789abcdef0"

僅限目標 ODCR 節點 (任何 ODCR,而非容量區塊):

spec: nodeSelector: karpenter.sh/capacity-type: reserved karpenter.k8s.aws/capacity-reservation-type: default

針對任何預留容量 (ODCR 或容量區塊):

spec: nodeSelector: karpenter.sh/capacity-type: reserved

偏好預留,但如果無法使用,請回到 Spot 或隨需:

spec: affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 preference: matchExpressions: - key: karpenter.sh/capacity-type operator: In values: ["reserved"]

保留過期行為

保留結束時ODCRs 和容量區塊的行為會有所不同。確保您的排程和檢查點策略符合您工作負載的保留類型。

ODCRs

在 ODCR 中啟動的執行個體無限期不在該 ODCR 中。ODCR 可能會過期、取消,或可從 ODCR 手動移除執行個體。如果發生上述任何情況,且 EKS Auto Mode / Karpenter 偵測到執行個體不再屬於 ODCR,則會將節點的karpenter.sh/capacity-type標籤從 更新reservedon-demand。執行個體會繼續做為標準隨需容量執行,而現有的 Pod 會繼續不間斷地執行。

注意

如果已重新標記任何以嚴格 排程的 Pod,nodeSelector: karpenter.sh/capacity-type: reserved將不會排程到節點。若要讓工作負載在 ODCR 到期或取消後存活,請使用上述preferredDuringSchedulingIgnoredDuringExecution模式,而非 nodeSelector

容量區塊

與 ODCRs 不同,容量區塊一律有結束時間,EC2 會在結束時間前 30 分鐘終止容量區塊執行個體 (UltraServer 執行個體類型為 60 分鐘)。在保留時段關閉之前,規劃訓練和推論任務以完成或儲存狀態。在區塊過期且不會重新排程其他位置Pending時,對特定capacity-reservation-id執行使用嚴格 nodeSelector 的 Pod。如果您需要工作負載在容量區塊到期期間移至其他容量,請將檢查點與上述的彈性親和性模式結合。

  • 您可以使用預留執行個體,直到大多數執行個體類型的容量區塊結束時間前 30 分鐘,或 UltraServer 執行個體類型的結束時間前 60 分鐘為止。

  • EKS Auto Mode 和 Karpenter 會在 EC2 開始終止前 10 分鐘先開始耗盡容量區塊中的節點,讓工作負載有時間進行檢查點並正常關閉。

靜態容量 NodePools

EKS Auto Mode 和 Karpenter 支援靜態容量 NodePools 都會維持固定數量的節點。靜態集區可減少冷啟動延遲敏感推論的延遲,並可讓您為叢集預留最低基礎設施使用量。

透過在 NodePool 上設定 replicas 欄位來設定靜態容量。

考量

  • 在 NodePool 上replicas設定 後,您就無法將其移除。單一 NodePool 無法在靜態和動態容量佈建之間切換。

  • 靜態容量 NodePools 不會考慮合併。limits.nodes 上述設定replicas以允許在 AMI 偏離或過期期間暫時擴展。

  • 針對可預測的可用區域 (AZ) 分佈,請為每個可用區域建立一個靜態容量 NodePool,而不是在單一集區中跨越多個區域。

EKS Auto Mode

以下範例顯示使用預設 EKS Auto Mode NodeClass 的靜態容量 NodePool,並建立具有 4 個節點 (replicas) 的靜態 NodePool,最多可達 6 個節點 ()limits.nodes

apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-static-inference spec: replicas: 4 template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6e"] - key: "topology.kubernetes.io/zone" operator: In values: ["us-east-1a"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule limits: nodes: 6 # Allow temporary headroom during node replacement
Self-managed Karpenter

使用自我管理的 Karpenter 時,靜態容量由 alpha StaticCapacity功能 (在 Karpenter 1.8 版中啟動) 鎖定,必須在 Helm 值中啟用:

settings: featureGates: staticCapacity: true

NodePool 參考EC2NodeClass名為 的自訂my-nodeclass,並建立具有 4 個節點 (replicas) 的靜態 NodePool,最多可達 6 個節點 ()limits.nodes

apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-static-inference spec: replicas: 4 template: spec: nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: my-nodeclass requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6e"] - key: "topology.kubernetes.io/zone" operator: In values: ["us-east-1a"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule limits: nodes: 6 # Allow temporary headroom during node replacement

ML 的容量區塊

ML 的容量區塊可讓您為定義的未來時段保留 P 系列和 Trainium 執行個體。它們是預付的,因此 EKS Auto Mode 和 Karpenter 會將它們建模為免費,並優先於隨需和 Spot。ML 的容量區塊的保留期間可以是 1-14 天或 7 天的倍數,最長可達 182 天 (6 個月)。

若要搭配 EKS Auto Mode 或 Karpenter 使用 ML 的容量區塊,請在 NodeClass 中使用capacityReservationSelectorTerms容量保留 ID 來設定 。您無法將開放保留比對與 ML 的容量區塊搭配使用。術語可以指定 ID、一組標籤或執行個體比對條件以供選取。指定標籤時,它會選取所有可從具有相符標籤的帳戶存取的容量保留。這可以透過指定擁有者帳戶 ID 進一步限制。

如需更多範例,請參閱 Karpenter 文件

EKS Auto Mode

建立參考容量區塊保留NodeClass的 ,然後建立使用它的 NodePool。

consolidateAfter: Never 設定後,Karpenter 不會嘗試取代、合併或終止節點,以更有效地降低成本或封裝工作負載。這建議用於容量區塊,因為容量已預付。

apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: capacity-block-gpu spec: capacityReservationSelectorTerms: - id: "cr-0123456789abcdef0" # Your Capacity Block reservation ID # Alternative: select by tags # - tags: # role: "production-inference" # owner: "012345678901" --- apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-capacity-block spec: disruption: consolidationPolicy: WhenEmpty consolidateAfter: Never template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: capacity-block-gpu requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["reserved"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["p5", "p5e", "p5en", "p4d"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule
Self-managed Karpenter

除了 之外,建立EC2NodeClass包含 AMI、子網路和安全群組選取器的 capacityReservationSelectorTerms,然後建立使用它的 NodePool。

consolidateAfter: Never 設定後,Karpenter 不會嘗試取代、合併或終止節點,以更有效地降低成本或封裝工作負載。這建議用於容量區塊,因為容量已預付。

apiVersion: karpenter.k8s.aws/v1 kind: EC2NodeClass metadata: name: capacity-block-gpu spec: amiSelectorTerms: - alias: al2023@latest subnetSelectorTerms: - tags: karpenter.sh/discovery: ml-cluster securityGroupSelectorTerms: - tags: karpenter.sh/discovery: ml-cluster capacityReservationSelectorTerms: - id: "cr-0123456789abcdef0" # Your Capacity Block reservation ID # Alternative: select by tags # - tags: # role: "production-inference" # owner: "012345678901" --- apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-capacity-block spec: disruption: consolidationPolicy: WhenEmpty consolidateAfter: Never template: spec: nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: capacity-block-gpu requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["reserved"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["p5", "p5e", "p5en", "p4d"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule

隨需容量保留 ODCRs)

ODCRs可保證特定可用區域 (AZ) 中的容量,無需長期承諾。無論容量是否使用,您都會按標準隨需費率計費。ODCRs支援所有 NVIDIA GPU 系列,包括 ML 的容量區塊不支援的 G 系列執行個體。ODCRs是預付的,因此 EKS Auto Mode 和 Karpenter 會將它們建模為免費,並優先於隨需和 Spot。

保留結束時ODCRs 的行為與 ML 的容量區塊不同。當 ODCR 過期或取消時,執行個體會繼續做為標準隨需執行。如需詳細資訊,請參閱 保留過期行為

若要搭配 EKS Auto Mode 或 Karpenter 使用 ODCRs,請在 NodeClass 中capacityReservationSelectorTerms以容量保留條件設定 。術語可以指定 ID、一組標籤或執行個體比對條件以供選取。指定標籤時,它會選取所有可從具有相符標籤的帳戶存取的容量保留。指定執行個體比對條件時,它會依相符行為選取保留:開啟 (符合所有相容的執行個體) 或目標 (僅符合明確的目標執行個體)。這可以透過指定擁有者帳戶 ID 進一步限制。

如需更多範例,請參閱 Karpenter 文件

EKS Auto Mode

NodeClass 使用 capacityReservationSelectorTerms 和以on-demand備用reserved為優先順序的 NodePool 建立 。釘topology.kubernetes.io/zone選至 ODCR 的 AZ:

apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: odcr-gpu-production spec: capacityReservationSelectorTerms: - id: "cr-0987654321fedcba0" # Alternative: select by tags # - tags: # Purpose: "production-inference" # owner: "012345678901" --- apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-reserved-production spec: disruption: consolidationPolicy: WhenEmpty consolidateAfter: Never template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: odcr-gpu-production requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["reserved", "on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["p5", "g6e"] - key: "topology.kubernetes.io/zone" operator: In values: ["us-east-1a"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule
Self-managed Karpenter

除了 之外,EC2NodeClass使用 AMI、子網路和安全群組選取器建立 capacityReservationSelectorTerms,然後建立 NodePool:

apiVersion: karpenter.k8s.aws/v1 kind: EC2NodeClass metadata: name: odcr-gpu-production spec: amiSelectorTerms: - alias: al2023@latest subnetSelectorTerms: - tags: karpenter.sh/discovery: ml-cluster securityGroupSelectorTerms: - tags: karpenter.sh/discovery: ml-cluster capacityReservationSelectorTerms: - id: "cr-0987654321fedcba0" --- apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-reserved-production spec: disruption: consolidationPolicy: WhenEmpty consolidateAfter: Never template: spec: nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: odcr-gpu-production requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["reserved", "on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["p5", "g6e"] - key: "topology.kubernetes.io/zone" operator: In values: ["us-east-1a"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule

On-Demand

隨需是預設容量類型,可與 EKS Auto Mode 和 Karpenter 中的靜態或動態佈建搭配使用。您可以在 NodePool karpenter.sh/capacity-type: on-demand中設定 ,明確請求隨需執行個體。EKS Auto Mode 和 Karpenter 選取滿足 Pod 資源請求的最低價執行個體。使用隨需進行開發、原型設計、不可預測的推論擴展,以及任何需要立即可用性且沒有中斷風險的工作負載。

EKS Auto Mode
apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-ondemand spec: template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6", "g6e", "g7e"] - key: "karpenter.k8s.aws/instance-gpu-manufacturer" operator: In values: ["nvidia"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule
Self-managed Karpenter
apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-ondemand spec: template: spec: nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6", "g6e", "g7e"] - key: "karpenter.k8s.aws/instance-gpu-manufacturer" operator: In values: ["nvidia"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule

Spot

Spot 使用備用 EC2 容量,相較於隨需節省高達 90% 的費用。 AWS 可以透過 2 分鐘的中斷通知回收 Spot 執行個體。透過列出 NodePool 上的多個執行個體系列,將可用性最大化。將具有 PodDisruptionBudget和 檢查點的 Spot 工作負載定期與耐用的儲存體 (Amazon S3 或 Amazon EFS) 配對,以便 Pod 在耗盡時段期間儲存狀態。

Spot 非常適合容錯、可重複使用的訓練和推論工作負載,其中偶爾中斷是可以接受的,以換取顯著的成本節省。

常見的候選項目包括:

  • 超參數調校和掃描:許多簡短的平行試驗可在中斷時重試。

  • 具有檢查點的分散式訓練:長時間執行的任務會定期將狀態儲存到 S3 或 FSx,並在節點遺失後從最後一個檢查點恢復。

  • 批次和離線推論:針對以小時為單位而非秒為單位測量end-to-end延遲的資料集進行大規模評分任務。

  • 資料預先處理和特徵工程管道:大型資料集的平行轉換。

  • 模型評估和基準測試:產生等冪性結果的可重複任務。

  • 開發、原型設計和筆記本:互動式實驗,使用者可以容忍偶爾重新啟動。

避免 Spot 用於對延遲敏感的即時推論、SLA 繫結的生產端點,以及不檢查點或無法容忍重新啟動的工作負載。

您可以在 NodePool karpenter.sh/capacity-type: spot中設定 以明確請求 Spot 執行個體。

EKS Auto Mode

EKS Auto 模式會以原生方式處理 Spot 中斷。不需要 SQS 佇列或節點終止處理常式。

apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-spot spec: disruption: budgets: - nodes: 10% consolidationPolicy: WhenEmpty consolidateAfter: 1h template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["spot"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6", "g6e", "g7e"] - key: "karpenter.k8s.aws/instance-gpu-manufacturer" operator: In values: ["nvidia"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule limits: resources: nvidia.com/gpu: "64"
Self-managed Karpenter

自我管理的 Karpenter 要求您透過設定中斷佇列,在 Karpenter 控制器 (而非 NodePool) 上啟用原生中斷處理:接收 EC2 Spot 中斷和重新平衡建議事件的 SQS 佇列。您可以在安裝時設定一次。

如果您直接使用 Helm 安裝 Karpenter,請在 settings.interruptionQueue中設定 values.yaml

# karpenter values.yaml (Helm) settings: clusterName: my-cluster interruptionQueue: my-queue # Name of the SQS queue receiving Spot events

如果您使用 引導 KarpentereksctlwithSpotInterruptionQueue: true請在叢集組態檔案中設定 。 eksctl會建立 SQS 佇列和 EventBridge 規則,並將 Karpenter 控制器設定為使用它們。

# eksctl ClusterConfig karpenter: version: "${KARPENTER_VERSION}" withSpotInterruptionQueue: true

一旦控制器設定為使用您的佇列,個別 NodePool 資源就不需要額外的組態。中斷處理會套用至整個叢集。

apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-spot spec: disruption: budgets: - nodes: 10% consolidationPolicy: WhenEmpty consolidateAfter: 1h template: spec: nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["spot"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6", "g6e", "g7e"] - key: "karpenter.k8s.aws/instance-gpu-manufacturer" operator: In values: ["nvidia"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule limits: resources: nvidia.com/gpu: "64"