全部產品
Search

搜尋本產品

    Container Service for Kubernetes：節點自動調整FAQ

    文件中心

    Container Service for Kubernetes：節點自動調整FAQ

    更新時間：Dec 17, 2025

    本文介紹使用節點自動調整功能時可能遇到的常見問題及解決方案。

    索引

    分類

    二級分類

    跳轉連結

    節點自動調整的擴縮容行為

    已知限制

    擴容行為相關

    縮容行為相關

    拓展支援相關

    cluster-autoscaler組件是否支援CRD？

    自訂的擴縮容行為

    通過Pod控制擴縮容行為

    通過節點控制擴縮容行為

    cluster-autoscaler組件相關

    已知限制

    無法100%精確預估節點可用資源

    由於ECS底層系統會佔用部分資源，因此執行個體可用記憶體會小於執行個體規格定義（請參見購買執行個體後查看記憶體大小，為什麼和購買時的執行個體規格定義不一致？）。受此約束，cluster-autoscaler組件估算的節點可調度資源可能大於實際節點的可調度資源，無法100%精確預估。您在配置Pod Request時，需關注以下注意事項。

    • 配置Pod Request取值時，資源申請總量需小於執行個體規格定義（包括CPU、記憶體、磁碟等）。建議Request總量不超過節點資源的70%。

    • cluster-autoscaler組件在判斷節點的資源是否充足時僅會考慮Kubernetes Pod（Pending Pod和DaemonSet Pod）資源。如果節點上存在非DaemonSet的Static Pod，需預先為此類Pod預留資源。

    • 如果Pod資源申請佔用的確較大（例如超過節點資源70%時），請提前測試並確認Pod是否可調度到同執行個體規格的節點上，保證可行性。

    支援有限的調度策略

    cluster-autoscaler組件僅支援有限的調度策略來判斷不可調度Pod能否調度到開啟彈性的節點池，詳情請參見下文cluster-autoscaler組件使用哪些調度策略來判斷不可調度Pod能否調度到開啟了彈性的節點池？。

    僅支援基於resource類型的Resource Policy

    使用Resource Policy自訂彈性資源優先順序時，僅支援基於resource類型的策略，請參見自訂彈性資源優先順序調度。

    apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: nginx
  namespace: default
spec:
  selector:
    app: nginx 
  units:
  - resource: ecs
  - resource: eci

    配置多執行個體規格的節點池不支援擴容指定執行個體規格

    如果您的節點池同時配置了多個執行個體規格，擴容時無法指定擴容某個執行個體規格。cluster-autoscaler組件會以資源維度在各個執行個體規格中取最小值，作為資源計算的基準，詳情請參見下文如果一個伸縮組內配置了多資源類型的執行個體規格，Auto Scaling時如何計算這個伸縮組的資源呢？。

    依賴特定可用性區域啟動並執行Pod無法觸發多可用性區域的節點池擴容

    如果您的節點池配置了多可用性區域，且有Pod依賴特定可用性區域運行，例如Pod使用的PVC指定了位於特定可用性區域的某個儲存卷，或Pod帶有特定可用性區域的nodeSelector，那麼cluster-autoscaler組件可能無法彈出對應可用性區域的節點。更多cluster-autoscaler組件無法彈出節點的情境，請參見下文為什麼節點自動調整組件無法彈出節點？。

    儲存約束問題

    節點伸縮組件在決策時無法感知Pod對儲存資源的特定約束，例如指定使用特定可用性區域、特定磁碟類型（如ESSD）的PV等。

    如應用依賴此類儲存，請在啟用節點Auto Scaling前配置專用的節點池。通過為節點池預設好可用性區域、執行個體規格、磁碟類型等配置，確保新擴容的節點能滿足儲存掛載要求，以避免Pod因資源不匹配而調度或啟動失敗。

    此外，請確保 Pod 沒有引用處於 Terminating 狀態的 PVC， Pod 因 PVC Terminating會持續調度失敗。這種情況會誤導 Cluster Autoscaler 做出錯誤的擴容或縮容決策（例如驅逐該 Pod）。

    擴容行為相關

    cluster-autoscaler組件使用哪些調度策略來判斷不可調度Pod能否調度到開啟了彈性的節點池？

    使用的調度策略如下所示。

    • PodFitsResources

    • GeneralPredicates

    • PodToleratesNodeTaints

    • MaxGCEPDVolumeCount

    • NoDiskConflict

    • CheckNodeCondition

    • CheckNodeDiskPressure

    • CheckNodeMemoryPressure

    • CheckNodePIDPressure

    • CheckVolumeBinding

    • MaxAzureDiskVolumeCount

    • MaxEBSVolumeCount

    • ready

    • NoVolumeZoneConflict

    cluster-autoscaler組件可類比判斷的資源有哪些？

    cluster-autoscaler組件已經支援以下資源的類比和判斷：

    cpu
memory
sigma/eni
ephemeral-storage
aliyun.com/gpu-mem （僅共用GPU）
nvidia.com/gpu

    如果需要其他資源類型，請參見開啟彈性的節點池如何配置自訂資源？。

    為什麼節點自動調整組件無法彈出節點？

    請檢查是否存在如下幾種情境：

    • 節點自動調整僅對設定了自動擴縮容的節點池生效，請確保節點自動調整功能已開啟，並且已設定節點池的擴縮容模式為自動。具體操作請參見啟用節點自動調整。

    • 配置伸縮組的執行個體類型無法滿足Pod的資源申請（Request）。ECS執行個體規格給出的資源大小是執行個體的售賣規格，實際運行時ACK需要佔用一定的節點資源來為系統組件和進程預留資源，從而保證OS核心和系統服務、Kubernetes守護進程的正常運行。這會導致節點的資源總數Capacity與可分配的資源數Allocatable之間存在差異。

      cluster-autoscaler組件在進行節點擴容決策時，其內建的資源預留策略在所有ACK叢集版本中均保持一致，採用1.28及以下版本的資源預留策略。

      如需應用1.28及以上版本的資源預留策略，推薦切換使用啟用節點即時彈性（1.28及以上版本內建了新資源預留演算法），或手動設定並維護節點池的自訂資源（在節點池中自行定義和維護資源預留值）。

    • 對可用性區域有約束的Pod，無法觸發配置了多可用性區域的節點池擴容。

    • 是否完整按照步驟執行了授權操作。授權操作是叢集維度，需要每個叢集操作一次。關於授權，請參見啟用節點自動調整的內容。

    • 開啟自動調整的節點池中出現如下異常情況。

      • 執行個體未加入到叢集且逾時。

      • 節點NotReady且逾時。

      為保證後續擴縮準確性，彈性組件以阻尼方式處理異常情況，在處理完異常情況節點前，不進行擴縮容。

    • 叢集中沒有節點，Auto Scaling組件cluster-autoscaler組件無法運行。建議您在建立節點池時至少配置2個節點，以確保叢集組件的正常運行。

      若您的使用情境為從0節點開始擴容或縮容到0節點，您可以使用節點即時彈性，請參見啟用節點即時彈性。

    如果一個伸縮組內配置了多資源類型的執行個體規格，Auto Scaling時如何計算這個伸縮組的資源呢？

    對於配置了多個執行個體規格的伸縮組，Auto Scaling組件以資源維度在各個執行個體規格中取最小值，作為資源計算的基準。

    例如，如果一個伸縮組內配置了兩種執行個體規格，一個是CPU 4核記憶體32 GB，另一個是CPU 8核記憶體16 GB。Auto Scaling組件認為這個伸縮組能保證的擴容出的CPU是4核記憶體16 GB的執行個體資源。因此如果狀態為Pending的Pod的requests資源超出4核或者16 GB，則不會進行擴容。

    如果您配置了多執行個體規格但需要考慮資源預留，請參見為什麼節點自動調整組件無法彈出節點？。

    Auto Scaling時，如何在多個開啟彈性的節點池之間進行選擇？

    在Pod處在無法調度時，會觸發Auto Scaling組件的類比調度邏輯，根據伸縮組配置的標籤、汙點以及執行個體規格等資訊進行判斷。當配置的伸縮組可以類比調度Pod的時候，就會被選擇進行節點彈出。當有多個開啟彈性的節點池同時滿足類比調度條件時，節點自動調整組件預設採用最少浪費（least-waste）原則，即根據類比彈出後節點上剩餘的資源最小為原則進行選擇。

    開啟彈性的節點池如何配置自訂資源？

    通過為開啟彈性的節點池配置如下固定首碼的ECS標籤（Tag），可以讓彈性組件識別到已開啟彈性的節點池中可供給的自訂資源，或者識別到指定的某些資源的精確值。

    k8s.io/cluster-autoscaler/node-template/resource/{資源名}:{資源大小}

    樣本：

    k8s.io/cluster-autoscaler/node-template/resource/hugepages-1Gi:2Gi

    為什麼為節點池設定自動擴縮容失敗？

    可能原因如下：

    • 節點池類型為預設節點池，不支援設定節點自動調整功能。

    • 節點池中已有通過手動添加的節點，您需要先移除手動添加的節點。建議您建立新的開啟自動擴縮容的節點池。

    • 節點池中有訂用帳戶的執行個體。節點自動調整功能不支援訂用帳戶付費類型的節點。

    縮容行為相關

    為什麼cluster-autoscaler組件無法縮容節點？

    請檢查是否存在如下幾種情境：

    • 節點Pod的資源申請（Request）閾值高於設定的縮容閾值。

    • 節點上運行kube-system命名空間的Pod。

    • 節點上的Pod包含強制的調度策略，導致其他節點無法運行此Pod。

    • 節點上的Pod擁有PodDisruptionBudget，且到達了PodDisruptionBudget的最小值。

    您可以在開源社區得到更多關於節點自動調整組件的常見問題與解答。

    如何啟用或禁用特定DaemonSet的驅逐？

    cluster-autoscaler組件會根據是否開啟 Daemonset Pod 排水配置決定是否驅逐DaemonSet Pods，這些配置是叢集維度，對叢集中的DaemonSet Pods通用。更多資訊，請參見步驟一：開啟節點自動調整功能。如果想要對某個DaemonSet Pod指定是否需要被驅逐，可以對這個DaemonSet Pod添加Annotation"cluster-autoscaler.kubernetes.io/enable-ds-eviction"："true"。

    類似的，DaemonSet Pod的Annotation中如果有"cluster-autoscaler.kubernetes.io/enable-ds-eviction"："false"，則會顯示禁止Cluster Autoscaler驅逐這個DaemonSet Pod。

    說明

    • 如果未開啟DaemonSet Pod排水，此Annotation僅對非空節點的DaemonSet Pod有效。如果想開啟空節點DaemonSet Pod，需要先開啟DaemonSet Pod排水。

    • 此Annotation需要在DaemonSet Pod上指定，而不是DaemonSet對象本身。

    • 此Annotation對不屬於任何DaemonSet的Pod沒有影響。

    • 預設情況下，Cluster Autoscaler對DaemonSet Pod的驅逐是非阻塞模式的，即不等待DaemonSet Pod驅逐完成後，就會執行後續流程。如需要Cluster Autoscaler等待指定DaemonSet Pod驅逐完成後再執行後續縮容流程，除以上啟用配置外，請為相應Pod添加Annotation"cluster-autoscaler.kubernetes.io/wait-until-evicted":"true"。

    什麼類型的Pod可以阻止cluster-autoscaler組件移除節點？

    當Pod不是由原生Kubernetes Controller建立的Pod（例如非Deployment、ReplicaSet、Job、StatefulSet等對象建立的Pod），或者當節點上的Pod不能被安全地終止或遷移時，cluster-autoscaler組件可能會阻止移除這個節點。詳細資料，請參見什麼類型的Pod可以阻止CA移除節點？。

    拓展支援相關

    cluster-autoscaler組件是否支援CRD？

    cluster-autoscaler組件目前僅支援Kubernetes標準對象，暫時不支援Kubernetes CRD。

    通過Pod控制擴縮容行為

    如何延遲cluster-autoscaler組件對不可調度Pod的擴容反應時間？

    可以通過Annotationcluster-autoscaler.kubernetes.io/pod-scale-up-delay為每個Pod設定延遲擴容時間。如果Kubernetes沒有在該延遲結束時調度它們，那麼CA可能會考慮對它們進行擴充。Annotation樣本："cluster-autoscaler.kubernetes.io/pod-scale-up-delay": "600s"。

    如何通過Pod Annotation影響cluster-autoscaler組件的節點縮容？

    您可以指定Pod阻止或不阻止節點被cluster-autoscaler組件縮容。

    • 阻止節點被縮容：為Pod添加Annotation"cluster-autoscaler.kubernetes.io/safe-to-evict": "false"。

    • 不阻止節點被縮容：為Pod添加Annotation "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" 。

    通過節點控制擴縮容行為

    如何指定節點不被cluster-autoscaler組件縮容？

    為目標節點配置Annotation "cluster-autoscaler.kubernetes.io/scale-down-disabled": "true"，使其不被cluster-autoscaler縮容。添加Annotation的命令樣本如下。

    kubectl annotate node <nodename> cluster-autoscaler.kubernetes.io/scale-down-disabled=true

    cluster-autoscaler組件相關

    如何升級cluster-autoscaler組件至最新版本？

    對於已開啟叢集自動Auto Scaling的叢集，可通過以下方式升級cluster-autoscaler組件。

    1. 登入Container Service管理主控台，在左側導覽列選擇叢集列表。

    2. 在叢集列表頁面，單擊目的地組群名稱，然後在左側導覽列，選擇節點管理 > 節點池。

    3. 單擊節點伸縮右側的編輯，然後在面板下方單擊確定，即可升級組件至最新版本。

    哪些操作會觸發cluster-autoscaler組件自動更新？

    為保證cluster-autoscaler組件配置的即時性、版本與叢集的相容性，以下操作會觸發cluster-autoscaler組件自動更新：

    • 更新自動調整配置。

    • 建立、刪除、更新開啟彈性節點池。

    • 成功升級叢集。

    ACK託管叢集已經完成了角色授權，但節點伸縮活動仍然無法正常運行？

    可能是叢集kube-system命名空間下保密字典內不存在addon.aliyuncsmanagedautoscalerrole.token而導致的。ACK預設通過WorkRole實現相關能力，請參見下方流程為手動叢集WorkerRole添加AliyunCSManagedAutoScalerRolePolicy的許可權。

    1. 在叢集列表頁面，單擊目的地組群名稱，然後在左側導覽列，選擇叢集資訊。

    2. 在叢集列表頁面，單擊目的地組群名稱，然後在左側導覽列，選擇節點管理 > 節點池。

    3. 在節點池頁面，單擊節點伸縮後方的去配置。

    4. 按照頁面提示，完成KubernetesWorkerRole角色授權和AliyunCSManagedAutoScalerRolePolicy系統策略的授權，入口如下所示。

      image

    5. 手動重啟kube-system命名空間下的Deployment cluster-autoscaler（節點自動調整）或ack-goatscaler（節點即時彈性），以便許可權立即生效。