問題是這樣的：有 A B 兩臺服務器，其中 A 服務器 cpu 快滿了，內存很空閑。另外一臺 B 服務器 cpu 很空閑，但內存快滿了。現在 k8s 有一個新的任務要調度，請問應該選擇哪臺服務器？這其實是現在非常火的 k8s 的經典應用場景。

有的同學看到這個問題后的第一個想法是應該先評估一下新任務是計算密集型的業務還是 io 密集型的。然后再決定往哪個機器上調度。這么思考倒是也不能算錯，只不過是沒有抓到問題的關鍵點上。

這個問題的關鍵點是在于要思考一下調度到某個機器上可能會出現什么問題。

1. 調度到 CPU 比較滿的 A 服務器

假設我們調度到 CPU 比較滿的 A 機器上會出現什么狀況呢？因為 CPU 資源是分時來調度的，每個進程都會得到一些時間片進行執行。所以 A 機器上不管 CPU 有多忙，再加一個的進程來運行話其實影響無非就是所有的進程都運行的更慢了一些。再換個說法，就是 CPU 資源是可以超賣的，是屬于可壓縮資源。

這里提一下，部分讀者反饋說自己的云虛機在 CPU 飆升到 100% 的時候，云廠商為了保護主機，直接宕機。這種情況在各大公司的 IDC 機房內不太可能出現，所以這種情況咱們暫時不考慮。

2. 調度到內存比較滿的 B 服務器

再假設我們調度到內存比較滿的 B 機器上會出現什么狀況呢？不知道你有沒有遭遇過線上進程被 oom kill 掉的場景。這種情況下就是當機器物理內存不是很充足的時候，如果申請的內存過大，操作系統就可能會挑選在運行的一些進程將其殺掉。

這里稍微展開說一下，操作系統選擇要殺掉的進程也不一定是內存消耗最多的服務。而是會綜合內存消耗和進程的 oom_score_adj（可配置） 值來進行選擇。在一些在離線混部的服務器上，往往會將在線服務進程的被殺的優先級調的低一些，離線服務進程的被殺優先級調高。這樣充分保障在線服務的穩定運行。

先不考慮在離線混部的情況，假設都是在線服務，那么無論哪一個服務的進程被 Linux 給 oom kill掉影響都是非常大的。還得重新調度，而且還有可能影響服務的穩定性，以及接口的正確返回。

這里有的同學可能會說，Linux 上不是支持將內存 swap 到磁盤上嗎？但其實在線上服務器中，由于磁盤的性能比內存低太多了，所以大部分的線上服務器都不會開啟 swap 這個特性。因為服務的內存一旦被 swap 到內存，即使是能運行，性能也會有急劇的下降。所以一般不怎么會開啟。

結論

所以對比來看，新任務在調度的時候應該優先選擇 A 服務器，因為它的空閑內存比較多，不太可能出現進程被殺死的情況。雖然它的 CPU 比較滿，但所有的服務仍然可以運行。

在實際中，k8s 的 API Server接受客戶端提交Pod對象創建請求后的操作過程中，有一個重要的步驟就是由調度器程序kube-scheduler從當前集群中選擇一個可用的最佳節點來接收并運行它。

當然實際中 k8s 的調度策略不是這么簡單的，系統默認的 kube-scheduler 調度器外還有直接指定Node主機名、節點親和性、Pod親和性、nodeSelector 等等調度策略。

就單拿系統默認的 kube-scheduler 調度器來說的話，還會綜合考慮單獨和整體的資源請求、硬件/軟件/策略限制、親和以及反親和要求、數據局域性、負載間的干擾等等這些因素對可調度節點打分，然后選出其中得分最高的 Node 來運行 Pod。


審核編輯：劉清