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

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

　　資源競爭與資源感知問題

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

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

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

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

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

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

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

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

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

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

　　頻繁的進(jìn)程切換導(dǎo)致CPU高速緩存失敗;

　　跨NUMA訪存會(huì)帶來更嚴(yán)重的性能瓶頸。

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

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

　　在Stand-Alone Workloads的情況下，做CPU的綁定和完全不做CPU綁定，執(zhí)行時(shí)間差別很大。因?yàn)閯×业腃PU爭搶以及頻繁的上下文切換，會(huì)導(dǎo)致約1倍的性能差距。

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

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

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

　　Exclusive是完全排他的CPU池，主要在兩種情況下使用。一種是Pod：請求整數(shù)CPU的Guaranteed，另一種是Topology Manager：滿足拓?fù)涔芾砥鞫�義的要求。

　　但原生Kubernetes也存在局限性。

　　調(diào)度器不感知節(jié)點(diǎn)資源拓?fù)洹?/p>

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

　　CPUSet分配策略過于單一。

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

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

　　當(dāng)在線與離線任務(wù)混部在同一臺(tái)主機(jī)上，在線閑時(shí)，離線任務(wù)可以充分使用資源，提升主機(jī)利用率;在線忙時(shí)，離線任務(wù)會(huì)被在線搶占，等待資源釋放。

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

　　如果忙時(shí)調(diào)度過多的離線任務(wù)，會(huì)導(dǎo)致劇烈的資源爭搶，并且每個(gè)離線Pod的性能都會(huì)下降。

　　因此，調(diào)度器在調(diào)度時(shí)，需要?jiǎng)討B(tài)感知離線實(shí)時(shí)算力。驅(qū)逐器也應(yīng)當(dāng)在線嚴(yán)重干擾離線時(shí)，驅(qū)逐離線Pod，保證節(jié)點(diǎn)的算力穩(wěn)定。

　　Kuberbnetes精細(xì)化調(diào)度

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

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

　　Cassini-Worker能從節(jié)點(diǎn)采集資源拓?fù)湫畔⒉��?chuàng)建NRT對象。

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

　　Scheduler-Plugins能擴(kuò)展調(diào)度器，為Pod進(jìn)行資源拓?fù)浞峙洹?/p>

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

　　在Fitter的插件內(nèi)，可以過濾節(jié)點(diǎn)拓?fù)滟Y源和選擇Zone并分配資源。

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

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

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

　　在調(diào)度算法上，可以從性能和負(fù)載均衡兩個(gè)方面做出考慮，以便更好地選擇節(jié)點(diǎn)和拓?fù)洹?/p>

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

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

　　容器CPUSet管理

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

　　首先，節(jié)點(diǎn)Kubelet會(huì)監(jiān)聽到Pod并準(zhǔn)備啟動(dòng)Pod。

　　隨后，節(jié)點(diǎn)Kubelet調(diào)用容器運(yùn)行時(shí)接口啟動(dòng)容器。

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

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

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

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

　　None：不做CPU綁核的策略，可以使用節(jié)點(diǎn)的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)核心;

　　同時(shí)，還希望一個(gè)Pod盡量不使用在同一個(gè)物理核上的邏輯核。

　　在離線混部場景下的實(shí)踐

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

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

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

　　建立算力平臺(tái)通用Metrics;

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

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

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

　　此時(shí)需要采取Exclusive策略：

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

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

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

　　在容器混部的場景中，在線Pod和離線Pod同時(shí)部署在同一臺(tái)物理機(jī)上。

　　此時(shí)需要采取NUMA策略：

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

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

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

　　總結(jié)

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

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

　　【原動(dòng)力×云原生正發(fā)聲降本增效大講堂】第一期聚焦在優(yōu)秀實(shí)踐方法論、資源與彈性、架構(gòu)設(shè)計(jì);第二期聚焦全場景在離線混部、K8s GPU資源效率提升、K8s資源拓?fù)涓兄�調(diào)度主題，點(diǎn)擊『此處』進(jìn)入活動(dòng)專題，帶你體驗(yàn)云原生降本增效實(shí)踐案例、了解如何解決企業(yè)用云痛點(diǎn)、掌握降本增效關(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