**協助改進此頁面** 本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的**在 GitHub 上編輯此頁面**連結。 本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # EKS Auto 模式的成本最佳化 EKS Auto Mode 透過整合、bin-packing 和正確調整大小，持續最佳化叢集的運算成本。不過，某些工作負載組態可能會阻止這些最佳化。本主題說明成本最佳化的運作方式、封鎖成本的方式，以及如何設定叢集以維持成本效益。 ## EKS Auto Mode 如何最佳化成本 EKS Auto Mode 透過下列機制降低運算成本： + **Bin-packing** – 將 Pod 排程到節點時，EKS Auto Mode 會選取與彙總資源請求密切相符的執行個體類型，將未使用的容量降至最低。 + **合併** — EKS Auto Mode 會定期評估執行中的節點，並在工作負載可在較低或成本較低的執行個體上執行時取代或移除它們。 + **適當調整大小** — 隨著工作負載縮減，EKS Auto Mode 會將 Pod 合併到較小的節點，並終止未充分利用的執行個體。 這些最佳化會在不手動介入的情況下持續執行。不過，某些 Pod 註釋和 NodePool 組態可能會阻止合併生效。 ## 內建節點集區和成本防護機制 內建`general-purpose`和`system`節點集區已強制執行數個成本保護預設值： + **僅限 C、M 和 R 的執行個體系列** — 不允許加速 (P、G、Inf、Trn) 或特殊執行個體類型。 + **僅限隨需容量** — 無 Spot 執行個體，可避免中斷驅動流失，但也表示沒有 Spot 節省。 + **第 5 代或更新版本** — 不包括較舊、低成本效益的執行個體產生。 如果您只使用內建節點集區，您已受益於這些護欄。當您建立不會繼承這些限制的**自訂 NodePools** 時，本主題中有關[排除執行個體系列](#_exclude_instance_families_for_cost_control)和[限制執行個體大小](#_constrain_instance_sizes)的指引最為相關。 不過，即使使用內建節點集區，下列各節仍適用於您： + [哪些項目會封鎖合併](#_what_blocks_consolidation) — `do-not-disrupt`註釋和限制性 PDBs區塊合併，無論節點佈建哪個 NodePool。 + [使用 NodePool 限制作為成本上限](#_use_nodepool_limits_as_a_cost_ceiling) — 內建節點集區未`limits`設定資源。如果您的工作負載可以大幅擴展，請考慮建立具有限制的自訂 NodePool，而不是依賴無限制的內建集區。 + [節點生命週期和成本](#_node_lifecycle_and_cost) — 節點取代重疊適用於所有節點，包括由內建集區佈建的節點。 | 護欄 | 內建節點集區 | 自訂 NodePools | | --- | --- | --- | | 加速執行個體排除 | 強制執行 | 您必須設定 | | 執行個體大小限制 | 未設定 | 您必須設定 | | 資源 `limits`(CPU/記憶體上限） | 未設定 | 您必須設定 | | 僅限隨需 | 強制執行 | 您可以選擇 (Spot/On-Demand) | | 合併保護 (`do-not-disrupt`/PDB) | 您的責任 | 您的責任 | ## 哪些項目會封鎖合併 當 EKS Auto Mode 判斷中斷節點會違反工作負載的可用性需求時，會封鎖合併。下列組態可防止整合： ### `do-not-disrupt` 註釋 `karpenter.sh/do-not-disrupt` 註釋會指示 EKS Auto Mode 只要註釋的 Pod 正在節點上執行，即可保留節點。這可防止節點合併、取代或終止，即使節點未充分利用也一樣。 ``` metadata: annotations: karpenter.sh/do-not-disrupt: "true" ``` **重要** **成本隱含**：當 Pod 攜帶`do-not-disrupt`註釋時，其執行的節點無需合併。這表示： 無論實際使用率為何，節點都會繼續以目前的執行個體大小執行。 即使工作負載的需求降低，該節點上的 vCPU 和記憶體用量也可以保持升高。 如果多個節點的多個 Pod 具有此註釋，則整個叢集的整合會大幅降低，進而持續提高成本。 `do-not-disrupt` 註釋是一種可用性機制。它不會考慮成本。僅用於執行中中斷導致資料遺失或重大重做的工作負載，例如長時間執行的批次任務或狀態程序，無需檢查點。 **要考慮的替代方案**： + **Pod 中斷預算 (PDBs)** — 使用 PDBs控制中斷率，而不是完全封鎖中斷率。PDBs進行合併，同時確保最少數量的複本保持可用。 + **較短的工作負載：**對於 CI/CD 執行器和建置代理程式，允許中斷，並依賴 CI 系統的內建重試邏輯，而不是使用 `do-not-disrupt`。 + **時間限制註釋** — `do-not-disrupt`僅適用於關鍵操作的持續時間，然後在操作完成時以程式設計方式將其移除。 ### Pod 中斷預算 (PDBs) 設定`maxUnavailable: 0`或`minAvailable`等於目前複本計數的 PDBs 可有效封鎖受影響 Pod 的所有合併。檢閱您的 PDBs以確保它們一次允許至少一個 Pod 中斷。 ## 使用 NodePool 限制作為成本上限 NodePool 在 NodePool 可佈建的運算資源總數上`limits`設定硬性上限。達到限制時，EKS Auto Mode 會停止啟動該 NodePool 的新節點。即使 Pod 處於待定狀態，也會發生這種情況。 使用 `limits`作為成本防護機制，特別是對於提供非生產、測試或高載工作負載的 NodePools，這些工作負載不適合無限制擴展。 ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: ci-runners spec: template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "eks.amazonaws.com/instance-category" operator: In values: ["c", "m"] limits: cpu: "500" memory: 1000Gi ``` 在此範例中，`ci-runners`NodePool 在佈建的所有節點中總計不得超過 500 個 vCPUs 或 1000 GiB 的記憶體。超過此限制的 Pod 會保持 `Pending` 狀態，直到容量釋放為止。 **提示** `limits` 根據預期的爆量大小上限加上節點替換緩衝區來設定 。定期檢閱您的 NodePool 使用率，並在工作負載模式變更時調整限制。 ## 排除執行個體系列以進行成本控制 根據預設，EKS Auto Mode 會從廣泛的執行個體類型中選取，以最大化排程彈性。對於不需要專用硬體的工作負載，請限制執行個體系列，以防止啟動昂貴的執行個體類型。 ### 排除加速執行個體 如果您的工作負載未請求 GPU 或加速器資源，請從 NodePool 中排除加速執行個體系列。這可防止在容量限制期間選取加速執行個體的情況。 ``` spec: template: spec: requirements: - key: "eks.amazonaws.com/instance-category" operator: In values: ["c", "m", "r"] ``` 透過僅指定運算最佳化、一般用途和記憶體最佳化類別，您可以從選取範圍中排除加速 (P、G、Inf、Trn) 和其他特殊執行個體系列。 ### 執行個體選擇如何與容量限制條件互動 EKS Auto Mode 會在正常執行個體選取期間，將加速和奇特執行個體類型取消優先順序。不過，當持續啟動失敗時，EKS Auto Mode 會從任何剩餘的可用執行個體類型啟動，以排定工作負載可用性的優先順序。例如，當 EC2 服務配額暫時用盡所有偏好的執行個體類型時，就會發生這種情況。 為了防止這種備用行為， 會明確將您的 NodePool 需求限制為僅工作負載所需的執行個體類別。當偏好的類型無法使用，且 NodePool 組態不允許其他類型時，Pod 會保持 `Pending` 狀態，而不是排程在昂貴的執行個體上。 ### 限制執行個體大小 除了限制執行個體系列之外，您還可以限制 NodePool 內的執行個體大小上限。限制執行個體大小會限制無法合併的任何單一節點的成本暴露。例如，即使`do-not-disrupt`節點的工作負載很小，註釋封鎖的節點也無法縮小。 使用 `eks.amazonaws.com/instance-cpu`標籤來限制 NodePool 需求中的執行個體大小上限： ``` requirements: - key: "eks.amazonaws.com/instance-cpu" operator: Lte values: ["32"] ``` 此組態可防止 EKS Auto 模式在此 NodePool 中啟動大於 32 個 vCPUs執行個體。 若要識別現有叢集中的最佳化機會，請檢閱您最大的執行中執行個體。如果持續封鎖大型節點，則閒置容量的每個節點成本會按比例提高。 ## 高載工作負載的建議模式 CI/CD 管道、批次任務和暫時性執行器會建立爆burst-and-idle模式，這些模式需要特定組態來維持成本效益。 ### 高載工作負載的建議預設值 | Configuration | 建議 | | --- | --- | | `do-not-disrupt` | 請勿將 用於 CI/CD 執行器。請改用 CI 系統的重試和佇列機制。 | | NodePool `limits` | 根據預期的並行上限加上節點取代重疊緩衝區，設定 CPU/記憶體上限。 | | 執行個體類別 | 限制為 `c`和 `m` 系列。排除非 GPU 工作負載的加速執行個體系列 (P、G、Inf、Trn)。 | | 執行個體大小 | 考慮限制為中等大小 （例如 4–32 vCPUs)，以限制從合併封鎖的任何單一節點的成本暴露。 | | 合併時間 | 使用`consolidateAfter`預設設定。避免設定長時間延遲，以在執行器完成後保持高載容量上線。 | | 容量類型 | 針對容錯執行器使用 Spot 執行個體。針對在執行期間保留狀態的建置代理程式，結合隨需。 | ### 範例：CI Runner NodePool ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: ci-runners spec: template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "eks.amazonaws.com/instance-category" operator: In values: ["c", "m"] - key: "eks.amazonaws.com/instance-cpu" operator: Lte values: ["32"] - key: "karpenter.sh/capacity-type" operator: In values: ["spot", "on-demand"] limits: cpu: "500" memory: 1000Gi disruption: consolidationPolicy: WhenEmptyOrUnderutilized consolidateAfter: 30s ``` 此組態： + 限制經濟實惠的執行個體系列 + 將總 NodePool 容量限制在 500 個 vCPUs + 允許積極整合 （移除 Pod 後 30 秒） + 允許 Spot 和隨需容量 ## 節點生命週期和成本 EKS Auto Mode 會在節點偏離所需規格 （例如，在發行新的 Auto Mode AMI 之後） 或節點生命週期接近到期時，透過正常中斷取代節點。在正常取代期間： + 新的替換節點已啟動並準備就緒。 + Pod 從舊節點耗盡，遵守 Pod 中斷預算。 + 在短時間內，舊節點和替換節點都會同時執行。 對於具有大型或多個節點的叢集，此重疊可能會定期增加成本。若要將影響降至最低： + **檢閱中斷預算** — 確保您的中斷預算允許及時耗盡。限制性預算會延長新舊節點執行的重疊期間。 + **適當大小的執行個體** — 較小的執行個體可減少重疊時段的絕對成本。 + **縮短節點生命週期上限** — 較短的到期值 （例如 7 天） 會建立更頻繁但較小的替換事件。這樣可以更平均地分散成本，而不是集中成本。 如需節點生命週期的詳細資訊，請參閱[了解 Amazon EKS Auto Mode 受管執行個體](automode-learn-instances.md)。