容器進程調(diào)度時是該優(yōu)先考慮CPU資源還是內(nèi)存資源

問題是這樣的：有 A B 兩臺服務(wù)器，其中 A 服務(wù)器 cpu 快滿了，內(nèi)存很空閑。另外一臺 B 服務(wù)器 cpu 很空閑，但內(nèi)存快滿了?，F(xiàn)在 k8s 有一個新的任務(wù)要調(diào)度，請問應(yīng)該選擇哪臺服務(wù)器？這其實是現(xiàn)在非?；鸬?k8s 的經(jīng)典應(yīng)用場景。

有的同學(xué)看到這個問題后的第一個想法是應(yīng)該先評估一下新任務(wù)是計算密集型的業(yè)務(wù)還是 io 密集型的。然后再決定往哪個機器上調(diào)度。這么思考倒是也不能算錯，只不過是沒有抓到問題的關(guān)鍵點上。

這個問題的關(guān)鍵點是在于要思考一下調(diào)度到某個機器上可能會出現(xiàn)什么問題。

1. 調(diào)度到 CPU 比較滿的 A 服務(wù)器

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

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

2. 調(diào)度到內(nèi)存比較滿的 B 服務(wù)器

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

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

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

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

結(jié)論

所以對比來看，新任務(wù)在調(diào)度的時候應(yīng)該優(yōu)先選擇 A 服務(wù)器，因為它的空閑內(nèi)存比較多，不太可能出現(xiàn)進程被殺死的情況。雖然它的 CPU 比較滿，但所有的服務(wù)仍然可以運行。

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

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

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


審核編輯：劉清