騰訊方睿：詳解Kubernetes資源拓撲感知調(diào)度

　　在云原生場景下，為了使CPU利用率更高，以及各容器之間不會由于激烈競爭而引起性能下降，容器的資源分配需要更精細化。

　　2022年8月11日，中國信通院、騰訊云、FinOps產(chǎn)業(yè)標準工作組聯(lián)合發(fā)起的《原動力x云原生正發(fā)聲 降本增效大講堂》系列直播活動第6講上，騰訊星辰算力平臺高級工程師方睿分享了Kubernetes資源拓撲感知調(diào)度。

　　資源競爭與資源感知問題

　　從CPU的體系結(jié)構(gòu)上來看，現(xiàn)代CPU多采用NUMA架構(gòu)和方式。

　　NUMA架構(gòu)是非對稱的，每個NUMA node上會有自己的物理CPU內(nèi)核，以及每個NUMA node之間也共享L3 Cache。同時，內(nèi)存也分布在每個NUMA node上的。某些開啟了超線程的CPU，一個物理CPU內(nèi)核在操作系統(tǒng)上會呈現(xiàn)兩個邏輯的核。

　　實際上，CPU內(nèi)核是分布在NUMA node上，NUMA node內(nèi)本身就有一些親和性的元素。

　　右圖中，CPU開始的訪問速度是不一樣的。

　　如果程序都跑在同一個NUMA node上，可以更好地去共享一些L3 Cache，L3 Cache的訪問速度會很快。如果L3 Cache沒有命中，可以到內(nèi)存中讀取數(shù)據(jù)，訪存速度會大大降低。

　　因此，從CPU體系結(jié)構(gòu)中可以看到，如果采用一些錯誤的CPU分配方式，可能會導致進程訪存速度急劇下降，嚴重影響應用程序的性能。

　　在這樣的體系結(jié)構(gòu)下，存在云計算中常見的吵鬧的鄰居問題。當多個容器在節(jié)點上共同運行時，由于資源分配的不合理，會對CPU本身的性能造成影響。

　　從理想的使用方式來看，如果每個進程都使用各自的CPU內(nèi)核，并且不會跨NUMA node訪問，相互之間不會有太多爭搶。

　　從糟糕的使用方式來看，如果兩個進程的CPU內(nèi)核在分配時，可能會沒有遵循NUMA的親和性，會帶來很大的性能問題，體現(xiàn)在三個方面：

　　CPU爭搶帶來頻繁的上下文切換時間;

　　頻繁的進程切換導致CPU高速緩存失敗;

　　跨NUMA訪存會帶來更嚴重的性能瓶頸。

　　Kubernetes中有CPU Manager的功能，CPU Manager可以做一些CPU核心的分配工作。上圖是Kubernetes的一些數(shù)據(jù)呈現(xiàn)。

　　在Guaranteed和Burstable兩種Pod混部測試下，將CPU Manager執(zhí)行時間做基準，如果是原生Kubernetes的方式在不同測試下，性能有較大波動，最差可能會達到1.8倍左右。

　　在Stand-Alone Workloads的情況下，做CPU的綁定和完全不做CPU綁定，執(zhí)行時間差別很大。因為劇烈的CPU爭搶以及頻繁的上下文切換，會導致約1倍的性能差距。

　　在吵鬧的鄰居問題下，Kubernetes是如何解決的呢?

　　CPU Manager是其中的一個解決方法，它被放在Kubelet中，CPUSet將會被CPU Manager分在Default和Exclusive兩個池子中。

　　Default主要在兩種情況下使用。一種是系統(tǒng)守護進程：kube-reserved、system-reserved，另一種是特殊類型的Pod：Burstable、BestEffort、請求非整數(shù)CPU的Guaranteed。

　　Exclusive是完全排他的CPU池，主要在兩種情況下使用。一種是Pod：請求整數(shù)CPU的Guaranteed，另一種是Topology Manager：滿足拓撲管理器定義的要求。

　　但原生Kubernetes也存在局限性。

　　調(diào)度器不感知節(jié)點資源拓撲。

　　Kubernetes中調(diào)度器只負責為Pod選擇節(jié)點，并不感知節(jié)點NUMA拓撲結(jié)構(gòu)，Pod的CPU分配交給Kubelet完成。當節(jié)點單NUMA node上沒有足夠的CPU時，Pod啟動失敗，控制器重建Pod后會陷入死循環(huán)。

　　CPUSet分配策略過于單一。

　　Kubernetes中CPU Manager默認為請求整數(shù)CPU的Guaranteed Pod分配獨占的CPUSet，但實際上Pod想定制自己的CPU分配策略，可能只是想分配到一個NUMA node內(nèi)，或是固定CPU甚至是不做綁核。

　　在混部場景下，也存在離線算力感知問題。

　　當在線與離線任務混部在同一臺主機上，在線閑時，離線任務可以充分使用資源，提升主機利用率;在線忙時，離線任務會被在線搶占，等待資源釋放。

　　當離線可用算力受在線干擾動態(tài)變化時，調(diào)度器僅感知節(jié)點靜態(tài)資源(Kubelet采集)。

　　如果忙時調(diào)度過多的離線任務，會導致劇烈的資源爭搶，并且每個離線Pod的性能都會下降。

　　因此，調(diào)度器在調(diào)度時，需要動態(tài)感知離線實時算力。驅(qū)逐器也應當在線嚴重干擾離線時，驅(qū)逐離線Pod，保證節(jié)點的算力穩(wěn)定。

　　Kuberbnetes精細化調(diào)度

　　在原生Kubernetes不能很好地解決資源競爭與資源感知問題時，亟需對資源進行更加精細化的調(diào)度。

　　如上圖，是精細化調(diào)度系統(tǒng)的結(jié)構(gòu)。

　　Cassini-Worker能從節(jié)點采集資源拓撲信息并創(chuàng)建NRT對象。

　　Cassini-Master能從外部系統(tǒng)采集節(jié)點擴展信息(可選)。

　　Scheduler-Plugins能擴展調(diào)度器，為Pod進行資源拓撲分配。

　　擴展調(diào)度器是通過Scheduler-Plugins來實現(xiàn)的，可以在幾個插入點做一些插件，保證實現(xiàn)標庫資源頭部感知調(diào)度的功能。

　　在Fitter的插件內(nèi)，可以過濾節(jié)點拓撲資源和選擇Zone并分配資源。

　　在Score的插件內(nèi)，可以根據(jù)Zone個數(shù)降序打分。

　　在Reserver的插件內(nèi)，可以為待綁定節(jié)點預留拓撲資源避免數(shù)據(jù)不一致。

　　在PreBind的插件內(nèi)，可以將拓撲調(diào)度結(jié)果附加到Pod Annotations中。

　　在調(diào)度算法上，可以從性能和負載均衡兩個方面做出考慮，以便更好地選擇節(jié)點和拓撲。

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

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

　　容器CPUSet管理

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

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

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

　　與此同時，節(jié)點Cassini-Worker通過List Kubelet的10250端口獲得節(jié)點上的所有Pod，再從Pod Annotations中獲取調(diào)度器的拓撲調(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)度：

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

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

　　建立算力平臺通用Metrics;

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

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

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

　　此時需要采取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的資源拓撲感知調(diào)度的主題展開。從CPU體系結(jié)構(gòu)和吵鬧的鄰居問題切人，隨后闡述了原生Kubernetes的不足和混部場景下的算力感知的局限，最后從采集節(jié)點拓撲資源、擴展Kubernetes調(diào)度器、多級資源QoS分配策略幾個方面給出了相應的解決方案。在策略的優(yōu)化后，資源得到更合理地利用。

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

　　【原動力×云原生正發(fā)聲降本增效大講堂】第一期聚焦在優(yōu)秀實踐方法論、資源與彈性、架構(gòu)設(shè)計;第二期聚焦全場景在離線混部、K8s GPU資源效率提升、K8s資源拓撲感知調(diào)度主題，點擊『此處』進入活動專題，帶你體驗云原生降本增效實踐案例、了解如何解決企業(yè)用云痛點、掌握降本增效關(guān)鍵技能……

　　————————————————

　　版權(quán)聲明：本文為CSDN博主「CSDN云原生」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接及本聲明。

　　原文鏈接：https://blog.csdn.net/m0_46700908/article/details/126518766