引言

在 K8s 集群運營程序中，常常會被節點 CPU 和記憶體的高使用率所困擾，既影響了節點上 Pod 的穩定運行，也會增加節點故障的幾率，為了應對集群節點高負載的問題，平衡各個節點之間的資源使用率，應該基于節點的實際資源利用率監控資訊，從以下兩個策略入手：

• 在 Pod 調度階段，應當優先將 Pod 調度到資源利用率低的節點上運行，不調度到資源利用率已經很高的節點上
• 在監控到節點資源率較高時，可以自動干預，遷移節點上的一些 Pod 到利用率低的節點上

為此，我們提供 動態調度器 + Descheduler 的方案來實作，目前在公有云 TKE 集群內【組件管理】- 【調度】分類下已經提供這兩個插件的安裝入口，文末還針對具體的客戶案例提供了最佳實踐的例子，

動態調度器

原生的 Kubernetes 調度器有一些很好的調度策略用來應對節點資源分配不均的問題，比如 BalancedResourceAllocation，但是存在一個問題是這樣的資源分配是靜態的，不能代表資源真實使用情況，節點的 CPU/記憶體利用率 經常處于不均衡的狀態，所以，需要有一種策略可以基于節點的實際資源利用率進行調度，動態調度器所做的就是這樣的作業，

技術原理

原生 K8s 調度器提供了 scheduler extender 機制來提供調度擴展的能力，相比修改原生 scheduler 代碼添加策略，或者實作一個自定義的調度器，使用 scheduler extender 的方式侵入性更少，實作更加靈活，所以我們選擇基于 scheduler extender 的方式來添加基于節點的實際資源利用率進行調度的策略，

scheduler extender 可以在原生調度器的預選和優選階段加入自定義的邏輯，提供和原生調度器內部策略同樣的效果，

架構

• node-annotator：負責拉取 Prometheus 中的監控資料，定期同步到 Node 的 annotation 里面，同時負責其他邏輯，如動態調度器調度有效性衡量指標，防止調度熱點等邏輯，
• dynamic-scheduler：負責 scheduler extender 的優選和預選介面邏輯實作，在預選階段過濾掉資源利用率高于閾值的節點，在優選階段優先選擇資源利用率低的節點進行調度，

實作細節

1. 動態調度器的策略在優選階段的權重如何配置？

原生調度器的調度策略在優選階段有一個權重配置，每個策略的評分乘以權重得到該策略的總得分，對權重越高的策略，符合條件的節點越容易調度上，默認所有策略配置權重為 1，為了提升動態調度器策略的效果，我們把動態調度器優選策略的權重設定為 2，

2. 動態調度器如何防止調度熱點？

在集群中，如果出現一個新增的節點，為了防止新增的節點調度上過多的節點，我們會通過監聽調度器調度成功事件，獲取調度結果，標記每個節點過去一段時間的調度 Pod 數,比如 1min、5min、30min 內的調度 Pod 數量，衡量節點的熱點值然后補償到節點的優選評分中，

產品能力

組件依賴

組件依賴較少，僅依賴基礎的節點監控組件 node-exporter 和 Prometheus，Prometheus 支持托管和自建兩種方式，使用托管方式可以一鍵安裝動態調度器，而使用自建 Prometheus 也提供了監控指標配置方法，

組件配置

調度策略目前可以基于 CPU 和記憶體兩種資源利用率，

預選階段

配置節點 5分鐘內 CPU 利用率、1小時內最大 CPU 利用率，5分鐘內平均記憶體利用率，1小時內最大記憶體利用率的閾值，超過了就會在預選階段過濾節點，

優選階段

動態調度器優選階段的評分根據截圖中 6個指標綜合評分得出，6個指標各自的權重表示優選時更側重于哪個指標的值，使用 1h 和 1d 內最大利用率的意義是要記錄節點 1h 和 1d 內的利用率峰值，因為有的業務 Pod 的峰值周期可能是按照小時或者天，避免調度新的 Pod 時導致在峰值時間節點的負載進一步升高，

產品效果

為了衡量動態調度器對增強 Pod 調度到低負載節點的提升效果，結合調度器的實際調度結果，獲取所有調度到的節點在調度時刻的的 CPU/記憶體利用率以后統計以下幾個指標：

• cpu_utilization_total_avg ：所有調度到的節點 CPU 利用率平均值，
• memory_utilization_total_avg ：所有調度到的節點記憶體利用率平均值，
• effective_dynamic_schedule_count ：有效調度次數，當調度到節點的 CPU 利用率小于當前所有節點 CPU 利用率的中位數，我們認為這是一次有效調度，effective_dynamic_schedule_count 加 0.5分，對記憶體也是同理，
• total_schedule_count ：所有調度次數，每次新的調度累加1，
• effective_schedule_ratio ：有效調度比率，即 effective_dynamic_schedule_count/total_schedule_count
  下面是在同一集群中不開啟動態調度和開啟動態調度各自運行一周的指標變化，可以看到對于集群調度的增強效果，

Descheduler

現有的集群調度場景都是一次性調度，即一錘子買賣，后續出現節點 CPU 和記憶體利用率過高，也無法自動調整 Pod 的分布，除非觸發節點的 eviction manager 后驅逐，或者人工干預，這樣在節點 CPU/記憶體利用率高時，影響了節點上所有 Pod 的穩定性，而且負載低的節點資源還被浪費，

針對此場景，借鑒 K8s 社區 Descheduler 重調度的設計思想，給出基于各節點 CPU/記憶體實際利用率進行驅逐的策略，

架構

Descheduler 從 apiserver 中獲取 Node 和 Pod 資訊，從 Prometheus 中獲取 Node 和 Pod 監控資訊，然后經過Descheduler 的驅逐策略，驅逐 CPU/記憶體使用率高的節點上的 Pod ，同時我們加強了 Descheduler 驅逐 Pod 時的排序規則和檢查規則，確保驅逐 Pod 時服務不會出現故障，驅逐后的 Pod 經過動態調度器的調度會被調度到低水位的節點上，實作降低高水位節點故障率，提升整體資源利用率的目的，

產品能力

產品依賴

依賴基礎的節點監控組件 node-exporter 和Prometheus，Prometheus 支持托管和自建兩種方式，使用托管方式可以一鍵安裝 Descheduler，使用自建 Prometheus 也提供了監控指標配置方法，

組件配置

Descheduler 根據用戶配置的利用率閾值，超過閾值水位后開始驅逐 Pod ，使節點負載盡量降低到目標利用率水位以下，

產品效果

通過 K8s 事件

通過 K8s 事件可以看到 Pod 被重調度的資訊，所以可以開啟集群事件持久化功能來查看 Pod 驅逐歷史，

節點負載變化

在類似如下節點 CPU 使用率監控視圖內，可以看到在開始驅逐之后，節點的 CPU 利用率下降，

最佳實踐

集群狀態

拿一個客戶的集群為例，由于客戶的業務大多是記憶體消耗型的，所以更容易出現記憶體利用率很高的節點，各個節點的記憶體利用率也很不平均，未使用動態調度器之前的各個節點監控是這樣的：

動態調度器配置

配置預選和優選階段的引數如下：

在預選階段過濾掉 5分鐘內平均記憶體利用率超過 60%或者 1h內最大記憶體利用率超過 70%的節點，即 Pod 不會調度到這些這些節點上，

在優選階段將 5分鐘平均記憶體利用率權重配置為 0.8，1h 和1d 內最大記憶體利用率權重配置為 0.2、0.2，而將 CPU 的指標權重都配置為 0.1，這樣優選時更優先選擇調度到記憶體利用率低的節點上，

Descheduler配置

配置 Descheduler 的引數如下，當節點記憶體利用率超過 80%這個閾值的時候，Descheduler 開始對節點上的 Pod 進行驅逐，盡量使節點記憶體利用率降低到目標值 60% 為止，

集群優化后狀態

通過以上的配置，運行一段時間后，集群內各節點的記憶體利用率資料如下，可以看到集群節點的記憶體利用率分布已經趨向于均衡：

【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！

標籤：其他

上一篇：一文讀懂 TKE 及 Kubernetes 訪問權限控制

下一篇：KubeSphere and Friends 2020 落幕 與開源社區伙伴零距離、全方位解讀云原生