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

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

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

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

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

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

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

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

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

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

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

結(jié)論

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

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

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

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


審核編輯：劉清