在性能方面，優(yōu)先選擇Pod能綁定在單NUMA node內(nèi)的節(jié)點。如果找不到該節(jié)點，可以優(yōu)先選擇在同一個NUMA Socket內(nèi)的NUMA node

在負(fù)載均衡方面，優(yōu)先選擇空閑資源更多的NUMA node。

容器CPUSet管理

Kubernetes的精細(xì)化調(diào)度做出一些拓?fù)涓兄?，而實際落到節(jié)點上，為了更好地實現(xiàn)資源分配，我們設(shè)計了一個資源分配系統(tǒng)。

首先，節(jié)點Kubelet會監(jiān)聽到Pod并準(zhǔn)備啟動Pod。

隨后，節(jié)點Kubelet調(diào)用容器運行時接口啟動容器。

與此同時，節(jié)點Cassini-Worker通過List Kubelet的10250端口獲得節(jié)點上的所有Pod，再從Pod Annotations中獲取調(diào)度器的拓?fù)湔{(diào)度結(jié)果。

節(jié)點Cassini-Worker調(diào)用容器運行時接口來更改容器的綁核結(jié)果。

關(guān)于容器多級資源QoS分配策略，在CPUSet的策略上，可以劃分為四種：

Exclusive：它可以獨占CPU內(nèi)核心，其他Pod不可使用，一般是高利用率的容器會采取該策略；

None：不做CPU綁核的策略，可以使用節(jié)點的Default CPU共享池；

NUMA：讓CPUSet固定到NUMA node上的共享池內(nèi)；

Immovable：將CPU內(nèi)核心固定，讓其他Pod也可共享。

在CPU內(nèi)核心選擇策略上：

首先，按照調(diào)度結(jié)果獲取NUMA node上需分配的核心數(shù)；

隨后，從共享池中選擇可分配的CPU內(nèi)核心；

同時，還希望一個Pod盡量不使用在同一個物理核上的邏輯核。

在離線混部場景下的實踐

由于離線混部場景中，離線會受到在線的影響，算力是波動的。因此，在離線混部場景下，還會做一些差異化重調(diào)度：

當(dāng)在線負(fù)載上升時，離線的算力會被壓制。因此，離線的Pod需要及時驅(qū)逐，以便剛好滿足節(jié)點離線算力的要求；

通過改造Descheduler組件，建立通用的可配置的平臺通用驅(qū)逐框架，支持Metrics驅(qū)逐，以及支持動態(tài)調(diào)整/配置驅(qū)逐策略；

建立算力平臺通用Metrics；

支持業(yè)務(wù)自定義Metrics驅(qū)逐。

在不同混部場景下，容器CPUSet策略也是不同的。

離線CVM混部的場景中，一臺物理機的各個NUMA node上都生產(chǎn)了許多在線的CVM，當(dāng)在線利用率很低時，需要更好地利用資源。

此時需要采取Exclusive策略：

離線CVM通過內(nèi)核VMF調(diào)度器獲取低優(yōu)的CPU時間片；

離線Pod通過獨占CPU內(nèi)核心的方式，保證互不干擾；

內(nèi)核VMF調(diào)度器保證離線Pod在忙時，可實現(xiàn)核心漂移，充分利用CPU資源。

在容器混部的場景中，在線Pod和離線Pod同時部署在同一臺物理機上。

此時需要采取NUMA策略：

離線Pod通過限制Cgroups，獲取低優(yōu)的CPU時間片；

離線Pod綁定整個NUMA node，防止某幾個CPU內(nèi)核心被壓制；

離線Pod共享整個NUMA node，充分利用CPU資源。

總結(jié)

本文圍繞Kubernetes的資源拓?fù)涓兄{(diào)度的主題展開。從CPU體系結(jié)構(gòu)和吵鬧的鄰居問題切人，隨后闡述了原生Kubernetes的不足和混部場景下的算力感知的局限，最后從采集節(jié)點拓?fù)滟Y源、擴展Kubernetes調(diào)度器、多級資源QoS分配策略幾個方面給出了相應(yīng)的解決方案。在策略的優(yōu)化后，資源得到更合理地利用。

未來，Kubernetes精細(xì)化調(diào)度將會覆蓋更多的場景，例如碎片GPU、網(wǎng)絡(luò)拓?fù)浼軜?gòu)、電力調(diào)度。

審核編輯：劉清