溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要講解了“K8s動態調度器怎么配置”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“K8s動態調度器怎么配置”吧！
在 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，為了提升動態調度器策略的效果，我們把動態調度器優選策略的權重設置為 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 下面是在同一集群中不開啟動態調度和開啟動態調度各自運行一周的指標變化，可以看到對于集群調度的增強效果。
| 指標 | 未開啟動態調度 | 開啟動態調度 |
|---|---|---|
| cpu_utilization_total_avg | 0.30 | 0.17 |
| memory_utilization_total_avg | 0.28 | 0.23 |
| effective_dynamic_schedule_count | 2160 | 3620 |
| total_schedule_count | 7860 | 7470 |
| effective_schedule_ratio | 0.273 | 0.486 |
現有的集群調度場景都是一次性調度，即一錘子買賣。后續出現節點 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 事件可以看到 Pod 被重調度的信息，所以可以開啟集群事件持久化功能來查看 Pod 驅逐歷史。
在類似如下節點 CPU 使用率監控視圖內，可以看到在開始驅逐之后，節點的 CPU 利用率下降。
拿一個客戶的集群為例，由于客戶的業務大多是內存消耗型的，所以更容易出現內存利用率很高的節點，各個節點的內存利用率也很不平均，未使用動態調度器之前的各個節點監控是這樣的： 
配置預選和優選階段的參數如下：
在預選階段過濾掉 5分鐘內平均內存利用率超過 60%或者 1h內最大內存利用率超過 70%的節點，即 Pod 不會調度到這些這些節點上。
在優選階段將 5分鐘平均內存利用率權重配置為 0.8，1h 和1d 內最大內存利用率權重配置為 0.2、0.2，而將 CPU 的指標權重都配置為 0.1。這樣優選時更優先選擇調度到內存利用率低的節點上。
配置 Descheduler 的參數如下，當節點內存利用率超過 80%這個閾值的時候，Descheduler 開始對節點上的 Pod 進行驅逐，盡量使節點內存利用率降低到目標值 60% 為止。
通過以上的配置，運行一段時間后，集群內各節點的內存利用率數據如下，可以看到集群節點的內存利用率分布已經趨向于均衡：
感謝各位的閱讀，以上就是“K8s動態調度器怎么配置”的內容了，經過本文的學習后，相信大家對K8s動態調度器怎么配置這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
