本文介紹使用節點自動伸縮功能時可能遇到的常見問題及解決方案。
索引
分類 | 二級分類 | 跳轉鏈接 |
節點自動伸縮的擴縮容行為 | ||
縮容行為相關 | ||
拓展支持 | ||
自定義的擴縮容行為 | 通過Pod控制擴縮容行為 | |
通過節點控制擴縮容行為 | ||
cluster-autoscaler組件相關 |
擴容行為相關
cluster-autoscaler組件使用哪些調度策略來判斷不可調度Pod能否調度到開啟了彈性的節點池?
使用的調度策略如下所示。
如果您的業務場景中有自動伸縮需求的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之間存在差異。詳細信息,請參見節點資源預留策略。
在創建實例的過程中會因虛擬化、操作系統等占用部分資源。更多信息,請參見購買實例后查看內存大小,為什么和購買時的實例規格定義不一致?。
需要占用一定的節點資源來運行相關組件(例如kubelet、kube-proxy、Terway、Container Runtime等)。詳細信息,請參見節點資源預留策略。
默認節點會安裝系統組件,Pod的申請資源要小于實例的規格。
對可用區有約束的Pod,無法觸發配置了多可用區的節點池擴容。
是否完整按照步驟執行了授權操作。授權操作是集群維度的,需要每個集群操作一次。關于授權,請參見前提條件的內容。
開啟自動伸縮的節點池中出現如下異常情況。
實例未加入到集群且超時。
節點NotReady且超時。
為保證后續擴縮準確性,彈性組件以阻尼方式處理異常情況,在處理完異常情況節點前,不進行擴縮容。
如果一個伸縮組內配置了多資源類型的實例規格,彈性伸縮時如何計算這個伸縮組的資源呢?
對于配置了多個實例規格的伸縮組,彈性伸縮組件以資源維度在各個實例規格中取最小值,作為資源計算的基準。
例如,如果一個伸縮組內配置了兩種實例規格,一個是CPU 4核內存32 GB,另一個是CPU 8核內存16 GB。彈性伸縮組件認為這個伸縮組能保證的擴容出的CPU是4核內存16 GB的實例資源。因此如果狀態為pending的Pod的requests
資源超出4核或者16 GB,則不會進行擴容。
如果您配置了多實例規格但需要考慮資源預留,請參見為什么節點自動伸縮組件無法彈出節點?。
彈性伸縮時,如何在多個開啟彈性的節點池之間進行選擇?
在Pod處在無法調度時,會觸發彈性伸縮組件的模擬調度邏輯,根據伸縮組配置的標簽、污點以及實例規格等信息進行判斷。當配置的伸縮組可以模擬調度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組件至最新版本?
對于已開啟集群自動彈性伸縮的集群,可通過以下方式升級cluster-autoscaler組件。
登錄容器服務管理控制臺,在左側導航欄選擇集群。
在集群列表頁面,單擊目標集群名稱,然后在左側導航欄,選擇 。
單擊節點伸縮右側的編輯,然后在面板下方單擊確定,即可升級組件至最新版本。
哪些操作會觸發cluster-autoscaler組件自動更新?
為保證cluster-autoscaler組件配置的實時性、版本與集群的兼容性,以下操作會觸發cluster-autoscaler組件自動更新:
更新自動伸縮配置。
創建、刪除、更新開啟彈性節點池。
成功升級集群。
ACK托管集群已經完成了角色授權,但節點伸縮活動仍然無法正常運行?
可能是集群kube-system命名空間下保密字典內不存在addon.aliyuncsmanagedautoscalerrole.token
而導致的。如不存在,請選擇以下一種方式解決。
提交工單申請技術支持。
手動添加AliyunCSManagedAutoScalerRolePolicy權限:ACK默認通過WorkRole實現相關能力,您可以請參見下方流程為集群WorkerRole添加AliyunCSManagedAutoScalerRolePolicy的權限。
在集群列表頁面,單擊目標集群名稱,然后在左側導航欄,選擇集群信息。
在集群列表頁面,單擊目標集群名稱,然后在左側導航欄,選擇 。
在節點池頁面,單擊節點伸縮后方的去配置。
按照頁面提示,完成KubernetesWorkerRole角色授權和AliyunCSManagedAutoScalerRolePolicy系統策略的授權,入口如下所示。
手動重啟kube-system命名空間下的Deployment cluster-autoscaler(節點自動伸縮)或ack-goatscaler(節點即時彈性),以便權限立即生效。