協助改進此頁面
本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
若要為本使用者指南貢獻內容,請點選每個頁面右側面板中的在 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 中使用的執行個體標籤nodeAffinity,nodeSelector或在沒有硬式編碼執行個體類型的目標工作負載。標籤字首在兩者之間不同: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
|
容量類型:spot、 on-demand或 reserved。
|
|
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
|
容量類型:spot、 on-demand或 reserved。
|
|
topology.kubernetes.io/zone
|
us-east-1a
|
可用區域。
|
|
kubernetes.io/arch
|
amd64
|
CPU 架構。
|
排程預留容量的標籤
當 EKS Auto Mode 或 Karpenter 在保留中啟動節點時,它會新增下列標籤。在 nodeSelector、節點親和性或 NodePool 需求中使用它們來路由工作負載。
-
karpenter.sh/capacity-type:reserved、 on-demand或 spot。指出備份節點的容量。
-
karpenter.k8s.aws/capacity-reservation-id:啟動節點的特定保留 ID。
-
karpenter.k8s.aws/capacity-reservation-type:default適用於 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標籤從 更新reserved為 on-demand。執行個體會繼續做為標準隨需容量執行,而現有的 Pod 會繼續不間斷地執行。
如果已重新標記任何以嚴格 排程的 Pod,nodeSelector: karpenter.sh/capacity-type: reserved將不會排程到節點。若要讓工作負載在 ODCR 到期或取消後存活,請使用上述preferredDuringSchedulingIgnoredDuringExecution模式,而非 nodeSelector。
容量區塊
與 ODCRs 不同,容量區塊一律有結束時間,EC2 會在結束時間前 30 分鐘終止容量區塊執行個體 (UltraServer 執行個體類型為 60 分鐘)。在保留時段關閉之前,規劃訓練和推論任務以完成或儲存狀態。在區塊過期且不會重新排程其他位置Pending時,對特定capacity-reservation-id執行使用嚴格 nodeSelector 的 Pod。如果您需要工作負載在容量區塊到期期間移至其他容量,請將檢查點與上述的彈性親和性模式結合。
靜態容量 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
如果您使用 引導 Karpentereksctl,withSpotInterruptionQueue: 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"