全部產品
Search

搜尋本產品

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

    文件中心

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

    更新時間：Nov 13, 2024

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

    索引

    分類

    二級分類

    跳轉連結

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

    擴容行為相關

    縮容行為相關

    拓展支援

    cluster-autoscaler組件是否支援CRD？

    自訂的擴縮容行為

    通過Pod控制擴縮容行為

    通過節點控制擴縮容行為

    cluster-autoscaler組件相關

    擴容行為相關

    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需要佔用一定的節點資源來為kube組件和system進程預留資源，從而保證OS核心和系統服務、Kubernetes守護進程的正常運行。這會導致節點的資源總數Capacity與可分配的資源數Allocatable之間存在差異。詳細資料，請參見節點資源預留策略。

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

    • 是否完整按照步驟執行了授權操作。授權操作是叢集維度，需要每個叢集操作一次。關於授權，請參見前提條件的內容。

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

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

      • 節點NotReady且逾時。

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

    如果一個伸縮組內配置了多資源類型的執行個體規格，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）原則，即根據類比彈出後節點上剩餘的資源最小為原則進行選擇。

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

    受底層資源佔用計算精度約束，自動調整組件估算的節點可調度資源可能大於實際節點的可調度資源。關於底層資源佔用計算精度約束的更多資訊，請參見購買執行個體後查看記憶體大小，為什麼和購買時的執行個體規格定義不一致？。當Pod資源申請佔用較大時（超過節點資源70%），需要使用者使用彈性前Pod確認是否可調度到同執行個體規格的節點。

    彈性組件在判斷節點的資源是否滿足時，僅考慮Pending Pods和Daemonset Pods的資源，如果節點上有非Daemonset的Static Pods，請您預先為此類Pod預留資源。

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

    通過為開啟彈性的節點池配置如下固定首碼的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而導致的。如不存在，請選擇以下一種方式解決。

    • 提交工單申請支援人員。

    • 手動添加AliyunCSManagedAutoScalerRolePolicy許可權：ACK預設通過WorkRole實現相關能力，您可以請參見下方流程為叢集WorkerRole添加AliyunCSManagedAutoScalerRolePolicy的許可權。

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

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

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

        1.jpg

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

        image

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