協助改進此頁面

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

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

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

EKS Auto 模式的成本最佳化

EKS Auto Mode 透過整合、bin-packing 和正確調整大小，持續最佳化叢集的運算成本。不過，某些工作負載組態可能會阻止這些最佳化。本主題說明成本最佳化的運作方式、封鎖成本的方式，以及如何設定叢集以維持成本效益。

EKS Auto Mode 如何最佳化成本

EKS Auto Mode 透過下列機制降低運算成本：

這些最佳化會在不手動介入的情況下持續執行。不過，某些 Pod 註釋和 NodePool 組態可能會阻止合併生效。

內建節點集區和成本防護機制

內建general-purpose和system節點集區已強制執行數個成本保護預設值：

如果您只使用內建節點集區，您已受益於這些護欄。當您建立不會繼承這些限制的自訂 NodePools 時，本主題中有關排除執行個體系列和限制執行個體大小的指引最為相關。

不過，即使使用內建節點集區，下列各節仍適用於您：

哪些項目會封鎖合併

當 EKS Auto Mode 判斷中斷節點會違反工作負載的可用性需求時，會封鎖合併。下列組態可防止整合：

do-not-disrupt 註釋

karpenter.sh/do-not-disrupt 註釋會指示 EKS Auto Mode 只要註釋的 Pod 正在節點上執行，即可保留節點。這可防止節點合併、取代或終止，即使節點未充分利用也一樣。

metadata:
  annotations:
    karpenter.sh/do-not-disrupt: "true"

要考慮的替代方案：

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-runnersNodePool 在佈建的所有節點中總計不得超過 500 個 vCPUs 或 1000 GiB 的記憶體。超過此限制的 Pod 會保持 Pending 狀態，直到容量釋放為止。

排除執行個體系列以進行成本控制

根據預設，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模式，這些模式需要特定組態來維持成本效益。

高載工作負載的建議預設值

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

此組態：

節點生命週期和成本

EKS Auto Mode 會在節點偏離所需規格 （例如，在發行新的 Auto Mode AMI 之後） 或節點生命週期接近到期時，透過正常中斷取代節點。在正常取代期間：

對於具有大型或多個節點的叢集，此重疊可能會定期增加成本。若要將影響降至最低：

如需節點生命週期的詳細資訊，請參閱了解 Amazon EKS Auto Mode 受管執行個體。