ack-koordinator組件提供負載熱點打散重調度能力,可以感知叢集內節點負載的變化,自動最佳化超過負載水位安全閾值的節點,防止出現負載極端不均衡的情況。本文介紹如何使用負載熱點打散重調度及其進階配置參數。
使用限制
僅支援ACK叢集Pro版。具體操作,請參見建立ACK託管叢集。
使用負載熱點打散重調度,需滿足以下版本要求。
組件
版本要求
ACK調度器版本
v1.22.15-ack-4.0及以上,v1.24.6-ack-4.0及以上
ack-koordinator(ack-slo-manager)
v1.1.1-ack.1及以上
Helm版本
v3.0及以上
費用說明
ack-koordinator組件本身的安裝和使用是免費的,不過需要注意的是,在以下情境中可能產生額外的費用:
負載熱點打散重調度介紹
以下介紹負載熱點打散重調度相關的概念。
負載感知調度
調度器支援負載感知調度,能夠在調度時選擇負載較低的節點運行新的Pod。節點的利用率會隨著時間、叢集環境變化、工作負載的流量或請求等動態變化,繼而導致叢集內節點間原本負載平衡的情況被打破,甚至有可能出現極端負載不均衡的情況,影響到工作負載運行時品質。ack-koordinator組件提供重調度能力,防止負載出現極端不均衡的情況。通過將負載感知調度和熱點打散重調度結合使用,可以獲得叢集良好的負載平衡效果。關於負載感知調度,請參見使用負載感知調度。
koord-descheduler模組工作原理
ack-koordinator組件提供koord-descheduler模組,其中LowNodeLoad外掛程式負責感知負載水位並完成熱點打散重調度工作。與Kubernetes原生的Descheduler的外掛程式LowNodeUtilization不同,LowNodeLoad是根據節點真實利用率決策重調度,而LowNodeUtilization是根據資源分派率決策重調度。
模組執行過程
koord-descheduler模組周期性運行,每個周期內的執行過程分為以下三個階段。
資料收集:擷取叢集內的節點和工作負載資訊,以及相關的資源使用率資料。
策略外掛程式執行。
下文以LowNodeLoad為例。
篩選負載熱點節點。關於節點分類,請參見下文LowNodeLoad負載水位參數說明。
遍曆熱點節點,從中篩選可以遷移的Pod,並進行排序。關於Pod打分排序,請參見下文Pod打分策略。
遍曆每個待遷移的Pod,檢查其是否滿足遷移條件,綜合考慮叢集容量、資源使用率水位、副本數比例等約束。詳細資料,請參見下文負載熱點打散重調度策略說明。
若滿足條件則將Pod歸類為待遷移副本,若不滿足則繼續遍曆其他Pod和熱點節點。
容器驅逐遷移:針對待遷移的Pod發起Evict驅逐操作。關於Evict驅逐,請參見Evict驅逐。
LowNodeLoad負載水位參數說明
LowNodeLoad外掛程式有兩個重要的參數:
highThresholds:負載的熱點水位,超過該閾值的節點上的Pod將參與重調度。建議您同時開啟調度器的負載感知調度能力,請參見策略說明。關於兩者如何搭配使用,請參見負載感知調度和熱點打散重調度如何搭配使用?。
lowThresholds:負載的空閑水位,低於該閾值的節點上的Pod不會被重調度。
以下圖為例,將lowThresholds設定為45%,將highThresholds設定為70%,那麼節點的分類標準如下。同理,如果lowThresholds和highThresholds的值發生變更,節點的分類標準也會相應發生變化。
資源使用率資料預設每分鐘更新一次,粒度為最近5分鐘的平均值。
空閑節點(Idle Node):資源使用率低於45%的節點。
正常節點(Normal Node):資源使用率高於等於45%且低於等於70%的節點。此節點的負載水位區間是期望達到的合理區間範圍。
熱點節點(Hotspot Node):資源使用率高於70%的節點。熱點節點將驅逐一部分Pod,降低負載水位,使其不超過70%。
負載熱點打散重調度策略說明
策略名稱稱 | 說明 |
熱點檢查重試次數策略 | 為了確保熱點識別的準確性,避免部分毛刺監控資料觸發應用頻繁遷移,koord-descheduler支援為熱點檢查配置重試次數。只有節點連續多次觸發閾值時才會識別為熱點節點。 |
節點排序策略 | 在識別到的熱點節點中,koord-descheduler會按資源用量從高到低的順序,依次對節點發起重調度。其中,節點排序過程中會依次比較記憶體資源用量和CPU資源用量,優先選取資源用量更高的節點。 |
Pod打分策略 | 對於每個熱點節點,koord-descheduler會對其中的Pod逐個打分排序,依次發起驅逐操作,將其遷移到空閑節點上。比較順序如下:
說明 若您對Pod的驅逐順序有要求,建議您考慮對Pod配置不同的優先順序或QoS。 |
篩選策略 | koord-descheduler模組支援為Pod和Node配置多種篩選參數,方便您在使用過程中進行灰階控制。
|
前置檢查策略 | koord-descheduler模組支援在Pod遷移前提供前置檢查能力,確保每個Pod的遷移過程盡量安全。
|
遷移流量控制策略 | 為了滿足Pod在遷移過程中應用的高可用要求,koord-descheduler模組還提供多種類型的限制能力,支援配置節點維度、命名空間維度以及工作負載維度下處於遷移狀態Pod的最大數量。此外,它還提供基於時間視窗的流控機制,保證同一Workload下Pod的遷移不會過於頻繁。koord-descheduler同樣相容K8s社區的幹擾預算機制PDB(Pod Disruption Budgets),支援配置更精細的管理原則來保障工作負載的高可用。關於幹擾預算機制,請參見幹擾預算機制。 |
可觀測性策略 | 您可以通過Event觀測重調度的遷移過程,並在詳細資料中查看遷移的具體原因和目前狀態。範例如下。
|
步驟一:安裝或修改組件ack-koordinator並開啟重調度
未安裝ack-koordinator組件
安裝ack-koordinator組件,並在安裝組件 ack-koordinator(ack-slo-manager)頁面選中ack-koordinator開啟重調度模組。安裝ack-koordinator組件,請參見安裝ack-koordinator組件。
已安裝ack-koordinator組件
修改ack-koordinator組件,並在ack-koordinator參數配置頁面選中ack-koordinator開啟重調度模組。修改ack-koordinator組件,請參見修改ack-koordinator組件。
步驟二:開啟負載熱點打散重調度外掛程式
使用如下YAML檔案,建立koord-descheduler-config.yaml。
koord-descheduler-config.yaml是ConfigMap格式的對象,用於啟用重調度外掛程式LowNodeLoad。
執行如下命令,將配置更新到叢集。
kubectl apply -f koord-descheduler-config.yaml
執行如下命令,重啟重調度器模組koord-descheduler。
重啟重調度器模組koord-descheduler後,koord-descheduler會使用修改後的最新配置。
kubectl -n kube-system scale deploy ack-koord-descheduler --replicas 0 deployment.apps/ack-koord-descheduler scaled kubectl -n kube-system scale deploy ack-koord-descheduler --replicas 1 deployment.apps/ack-koord-descheduler scaled
步驟三(可選):開啟調度器負載平衡外掛程式
開啟調度器負載平衡外掛程式,以獲得叢集良好的負載平衡效果。具體操作步驟,請參見步驟一:開啟負載感知調度。
步驟四:驗證重調度能力
下文以擁有3台104核 396 GB節點的叢集為例進行說明。
使用如下YAML檔案,建立stress-demo.yaml。
執行如下命令,建立壓測Pod。
kubectl create -f stress-demo.yaml deployment.apps/stress-demo created
執行如下命令,觀察Pod的狀態,直到它開始運行。
kubectl get pod -o wide
預期輸出:
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES stress-demo-588f9646cf-s**** 1/1 Running 0 82s 10.XX.XX.53 cn-beijing.10.XX.XX.53 <none> <none>
可以看到,Pod
stress-demo-588f9646cf-s****
調度在節點cn-beijing.10.XX.XX.53
上。提升節點
cn-beijing.10.XX.XX.53
的負載水位,然後執行如下命令,檢查每個Node節點的負載。kubectl top node
預期輸出:
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% cn-beijing.10.XX.XX.215 17611m 17% 24358Mi 6% cn-beijing.10.XX.XX.53 63472m 63% 11969Mi 3%
可以看到,節點
cn-beijing.10.XX.XX.53
的負載較高,為63%,已經超過配置的熱點水位50%。節點cn-beijing.10.XX.XX.215
負載較低,為17%,低於配置的空閑水位20%。開啟重調度。具體操作,請參見步驟二:開啟負載熱點打散重調度外掛程式。
執行如下命令,觀察Pod變化。
等待重調度器檢查熱點節點,並執行驅逐遷移操作。
說明判定為熱點節點的預設條件為連續5次檢查節點均超過熱點水位,即10分鐘。
kubectl get pod -w
預期輸出:
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES stress-demo-588f9646cf-s**** 1/1 Terminating 0 59s 10.XX.XX.53 cn-beijing.10.XX.XX.53 <none> <none> stress-demo-588f9646cf-7**** 1/1 ContainerCreating 0 10s 10.XX.XX.215 cn-beijing.10.XX.XX.215 <none> <none>
執行如下命令,觀察Event。
kubectl get event | grep stress-demo-588f9646cf-s****
預期輸出:
2m14s Normal Evicting podmigrationjob/00fe88bd-8d4c-428d-b2a8-d15bcdeb**** Pod "default/stress-demo-588f9646cf-s****" evicted from node "cn-beijing.10.XX.XX.53" by the reason "node is overutilized, cpu usage(68.53%)>threshold(50.00%)" 101s Normal EvictComplete podmigrationjob/00fe88bd-8d4c-428d-b2a8-d15bcdeb**** Pod "default/stress-demo-588f9646cf-s****" has been evicted 2m14s Normal Descheduled pod/stress-demo-588f9646cf-s**** Pod evicted from node "cn-beijing.10.XX.XX.53" by the reason "node is overutilized, cpu usage(68.53%)>threshold(50.00%)" 2m14s Normal Killing pod/stress-demo-588f9646cf-s**** Stopping container stress
預期輸出為遷移記錄,可以看出結果符合預期。熱點節點上的Pod被重調度到其他節點。
進階配置參數
koord-descheduler模組進階配置參數介紹
koord-descheduler的所有參數配置以ConfigMap形式提供,以下展示了負載熱點打散重調度的進階配置參數格式。
koord-descheduler系統配置
參數 | 類型 | 取值 | 說明 | 樣本值 |
dryRun | boolean |
| 唯讀模式開關,開啟後將不會發起Pod遷移。 | false |
deschedulingInterval | time.Duration | >0s | 重調度執行循環。 | 120s |
驅逐遷移控制配置
參數 | 類型 | 取值 | 說明 | 樣本值 |
maxMigratingPerNode | int64 | ≥0(預設值為2) | 每個節點處於遷移狀態的Pod的最大數量。0表示不限制。 | 2 |
maxMigratingPerNamespace | int64 | ≥0(預設不限制) | 每個命名空間處於遷移狀態的Pod的最大數量。0表示不限制。 | 1 |
maxMigratingPerWorkload | intOrString | ≥0(預設值為10%) | 每個工作負載(例如Deployment)中處於遷移狀態的Pod的最大數量或百分比。0表示不限制。 若工作負載只有單副本,則不參與重調度。 | 1或10% |
maxUnavailablePerWorkload | intOrString | ≥0(預設值為10%),且小於工作負載對應的副本總數 | 每個工作負載(例如Deployment)最大不可用副本數或百分比。0表示不限制。 | 1或10% |
evictLocalStoragePods | boolean |
| 是否允許配置了HostPath或EmptyDir的Pod參與重調度。出於安全考慮,預設不開啟。 | false |
objectLimiters.workload | 結構體,資料格式為:
|
| 工作層級Pod遷移的流量控制。
|
表示5分鐘內單個工作負載最多遷移1個副本。 |
LowNodeLoad外掛程式配置
參數 | 類型 | 取值 | 說明 | 樣本值 |
highThresholds | map[string]float64 說明 支援CPU和記憶體兩個維度,值的單位為百分比。 | [0,100] | 表示負載的熱點水位,超過該閾值的節點上的Pod將參與重調度。 說明 可以和調度器的負載感知調度能力搭配使用,將節點篩選參數loadAwareThreshold配置為相同的值,調度器會拒絕將Pod調度到該熱點節點上,詳情請參見策略說明。 |
|
lowThresholds | map[string]float64 說明 支援CPU和記憶體兩個維度,值的單位為百分比。 | [0,100] | 表示負載的空閑水位。低於該閾值的節點上的Pod不會被重調度。 |
|
anomalyCondition.consecutiveAbnormalities | int64 | >0(預設值為5) | 熱點檢查重試次數。連續多個執行循環檢查後,均超過highThresholds的節點,才會被判定為熱點節點。熱點節點發生驅逐後會重新計數。 | 5 |
evictableNamespaces |
| 叢集內的命名空間 | 可以參與重調度的Namespace,不填表示所有Pod全部可參與。 支援配置include和exclude策略。兩種策略需二選一。
|
|
nodeSelector | metav1.LabelSelector | 關於LabelSelector的格式,請參見Labels and Selectors | 通過LabelSelector選擇目標節點。 | 分為兩種方式,一種是指定單個節點池時的配置方式,一個是指定多個節點池時的配置方式。
|
podSelectors | 由PodSelector組成的List,支援配置多組Pod。PodSelector的資料格式為:
| 關於LabelSelector的格式,請參見Labels and Selectors | 通過LabelSelector選擇開啟重調度的Pod。 |
|
常見問題
節點利用率閾值已經達到閾值,但是節點上Pod沒有被驅逐怎麼辦?
出現這種情況時,一般可能是有以下幾種原因,請參考對應的解決方案進行調整。
原因分類 | 原因描述 | 解決方案 |
組件配置未生效 | 開啟範圍未指定 | 重調度器配置中包含Pod和節點的開啟範圍配置,請檢查對應的命名空間和節點是否開啟。 |
重調度器配置修改後未重啟 | 重調度器配置修改後,需要對其進行重啟才會生效。關於重啟重調度器,請參見步驟二:開啟負載熱點打散重調度外掛程式。 | |
節點狀態不滿足條件 | 節點的平均利用率長時間低於閾值 | 重調度器會持續對利用率監控一段時間,並對監控資料做平滑均值處理,因此只有節點持續超過閾值才會觸發重調度,預設為10分鐘左右。而 |
叢集內剩餘的容量不足 | 在對Pod驅逐前,重調度器會對叢集內其他節點進行檢查,確保容量充足才會進行遷移。例如選擇了一個規格為8 Core 16 G的Pod準備驅逐,而叢集所有節點的空閑容量均低於該值,出於安全考慮重調度器則不會對其遷移。請考慮增加節點,確保叢集容量充足。 | |
工作負載屬性約束限制 | 工作負載為單副本 | 為了保證單副本應用的高可用,這類Pod預設不參與重調度。如果您評估此類單副本應用後,希望該Pod參與重調度,請給Pod或者工作負載(如Deployment或StatefulSet)的TemplateSpec中追加Annotation 說明 該Annotation配置僅支援v1.2.0-ack1.3及更早版本。 |
Pod指定了HostPath或EmptyDir | 出於安全考慮,這類指定了HostPath或EmptyDir的Pod預設不參與重調度。如果需要對其進行遷移,可以參考evictLocalStoragePods配置允許其參與重調度。詳細資料,請參見驅逐遷移控制配置。 | |
不可用或遷移中的副本數量過多 | 當工作負載(如Deployment或StatefulSet)的不可用或遷移中的副本數超過了限制配置(maxUnavailablePerWorkload或maxMigrationPerWorkload)。例如 maxUnavailablePerWorkload和maxMigrationPerWorkload設定為20%,Deployment的期望副本數設定為10,當前正好有2個Pod正在被驅逐或者正在發布,重調度器就不會對其發起驅逐。請等待Pod驅逐或發布完成,或將以上兩個配置調大。 | |
副本數量約束配置錯誤 | 當工作負載的副本總數小於等於最大遷移數量配置maxMigrationPerWorkload或最大不可用數量配置maxUnavailablePerWorkload時,出於安全考慮重調度器將不會對其進行重調度。請將以上兩個配置調小或修改為百分比模式。 |
重調度器頻繁重啟是什麼原因?
重調度器的配置ConfigMap格式錯誤或不存在,請參考進階配置參數檢查ConfigMap檔案內容和格式並進行修改,修改後重啟重調度器。重啟重調度器,請參見步驟二:開啟負載熱點打散重調度外掛程式。
負載感知調度和熱點打散重調度如何搭配使用?
開啟熱點打散重調度後,負載熱點上的Pod將會被驅逐。對於上層控制器(例如Deployment)建立的Pod,調度器會根據其配置選擇合適的節點進行調度。為了獲得更好的負載平衡效果,建議您同時為調度器開啟負載感知調度能力,請參見使用負載感知調度。
配置時,建議您將負載感知調度中的節點篩選功能參數loadAwareThreshold配置為與熱點打散重調度器的highThresholds參數相同的值,具體請參見策略說明。當節點的負載超過highThresholds時,重調度器將驅逐該節點上的Pod,而調度器則通過loadAwareThreshold拒絕新的Pod被調度到該熱點節點上。否則,經驅逐的Pod可能重新被調度到原來的節點,尤其是在Pod指定了節點調度範圍,但對應的節點數量較少且利用率較為接近時。
重調度參考的利用率演算法是什嗎?
重調度器會持續對利用率監控一段時間,並對監控資料做平滑均值處理,因此只有節點持續超過閾值才會觸發重調度,預設為10分鐘左右。此外對於記憶體資源維度,重調度器參考的記憶體用量排除了page cache,因為這部分資源是可以被作業系統回收的,而通過kubectl top node
返回的利用率是包含page cache的,您可以通過使用阿里雲Prometheus監控查看真實的記憶體用量資訊。