[TOC] # scheduler調度步驟 kube-scheduler 給一個 Pod 做調度選擇時包含兩個步驟： 1. 過濾 2. 打分 過濾階段會將所有滿足 Pod 調度需求的節點選出來。 例如，PodFitsResources 過濾函數會檢查候選節點的可用資源能否滿足 Pod 的資源請求。 在過濾之后，得出一個節點列表，里面包含了所有可調度節點；通常情況下， 這個節點列表包含不止一個節點。如果這個列表是空的，代表這個 Pod 不可調度。 在打分階段，調度器會為 Pod 從所有可調度節點中選取一個最合適的節點。 根據當前啟用的打分規則，調度器會給每一個可調度節點進行打分。 最后，kube-scheduler 會將 Pod 調度到得分最高的節點上。 如果存在多個得分最高的節點，kube-scheduler 會從中隨機選取一個。 # 常見問題 ## 調度不均衡 通常反饋都是內存不均衡。比如集群有三個節點，一臺是128G內存，兩臺是64G內存。預想的是三臺使用內存百分比差不多。實際上兩臺64G內存差不多跑滿了，另一臺128G內存才跑了50%左右。 為什么會出現這種問題呢？ > 我們先了解下調度的其中一個打分。k8s調度認為內存使用情況是 `節點總共調度的request值(kubectl describe node k8s-node01)` 最下面有打印（示例如下） >  **由此可見**：調度的時候不是按照主機實際使用內存情況，而是根據 該節點request總值來評估使用率。 **總結和建議**：pod設置一定要設置 request 值，且設置的時候與實際跑的內存相符。設置request值與實際跑的內存差距太大會出現如上情況。 ## 監控主機內存接近滿載不驅逐 k8s是有自己一套主機內存判斷機制是否到達驅逐臨界定。[官網提供k8s檢測腳本](https://kubernetes.io/zh-cn/examples/admin/resource/memory-available.sh) / [【備份】本地下載官方k8s檢測腳本](./memory-available.sh) 判斷是否超過驅逐臨界點。超過該臨界點則開始驅逐pod。臨界點是 `--eviction-hard` 參數配置。查看配置的情況 `ps -ef | grep [k]ubelet | grep 'eviction-hard=memory.available'` **由此可見**：可能與監控主機內存有出入，需參考上面提供腳本測試是否到達驅逐標準。 >[info] **總結**：通過 `free -h` 不是判斷驅逐條件，所有還是使用上面腳本為準哈。 # 參考文章 節點壓力驅逐：https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/