背景
kubernetes 的原生排程器只能透過資源請求來排程 pod，這很容易造成一系列負載不均的問題，
並且很多情況下業務方都是超額申請資源，因此在原生排程器時代我們針對業務的特性以及評估等級來設定 Requests/Limit 比例來提升資源利用效率。
在這種場景下依然存在很多問題：
- 節點負載不均：原生 Kubernetes Scheduler 根據 Requests 和節點可分配總量來排程 Pod，既不考慮實時負載，也不估計使用量，這種純靜態的排程導致節點資源利用率分配不均。
在流量波動性業務的場景下，在流量高峰時，部分節點利用率突破安全閾值，但是很多節點的利用率特別點，節點利用率相差特別大 - 業務週期性：在離線叢集分離，線上叢集底峰存在巨大資源浪費
本文主要討論如果解決問題一，線上叢集內部提升資源利用率
線上叢集 Cpu 離散係數0.45，整個叢集高峰時 Cpu 利用率僅25%左右；下圖 Cpu 使用率離散圖：
破局
基於上述情況，高峰時 Cpu 利用率僅25%肯定不是合理的情況，業界做的好的50%+。想要繼續提升利用率，必須解決節點負載不均問題：
- 感知節點真實負載：要解決節點負載不均問題，必須要上報節點當前真實的負載
- 基於負載的正向排程外掛：在預設排程器的基礎上增加基於負載的排程外掛，在正向排程是儘量保證節點間水位平均
- 基於負載的重排程元件：當業務不斷波動，節點可能會因為應用負載變化導致節點負載出現差別，需要重排程遷移 Pod 重新達到平均
實踐
關注的兩個開源專案：
Koordinator: https://koordinator.sh/
Crane: https://gocrane.io/
相對於 Koordinator 專門為混部而生的軟體，Crane以 Finops 為出發點，二者相比Koordinator更適合我們，在離線混部也是下一步計劃。
調研測試
上線之後：
遇到的問題
- 熱點節點問題：在業務高峰時，節點負載變高，會出現熱點節點，這個時候需要重排程元件介入，把 Pod 重新排程到其他節點上
需要前置打散熱點節點，這就需要對應用進行資源畫像，在排程中分散這種型別的應用，避免業務高峰熱點節點的產生
2. 在1中的情況下，擴容部分節點緩解叢集壓力時，新上的節點會迅速被熱點Pod佔滿，導致節點負載升高，再次觸發重排程
調整排程外掛中負載均衡打分外掛的權重，讓節點負載更均衡，避免熱點節點問題
3. 找到合適的節點規格，小規格節點，更容器出現熱點節點
在我們的業務場景下下，當前來看48c節點熱點節點出現機率小於32c