一区二区三区三上|欧美在线视频五区|国产午夜无码在线观看视频|亚洲国产裸体网站|无码成年人影视|亚洲AV亚洲AV|成人开心激情五月|欧美性爱内射视频|超碰人人干人人上|一区二区无码三区亚洲人区久久精品

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

Kubernetes是如何解決資源拓?fù)涓兄{(diào)度的呢

程序人生 ? 來源:CSDN云原生 ? 作者:方睿 ? 2022-08-25 12:03 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

資源競(jìng)爭(zhēng)與資源感知問題

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

NUMA架構(gòu)是非對(duì)稱的,每個(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)本身就有一些親和性的元素。

2df9aa10-2429-11ed-ba43-dac502259ad0.png

右圖中,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ì)對(duì)CPU本身的性能造成影響。

2e07ab1a-2429-11ed-ba43-dac502259ad0.png

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

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

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

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

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

2e13b7c0-2429-11ed-ba43-dac502259ad0.png

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

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

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

2e2397e4-2429-11ed-ba43-dac502259ad0.png

在吵鬧的鄰居問題下,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、請(qǐng)求非整數(shù)CPU的Guaranteed。

Exclusive是完全排他的CPU池,主要在兩種情況下使用。一種是Pod:請(qǐng)求整數(shù)CPU的Guaranteed,另一種是Topology Manager:滿足拓?fù)涔芾砥鞫x的要求。

但原生Kubernetes也存在局限性。

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

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)為請(qǐng)求整數(shù)CPU的Guaranteed Pod分配獨(dú)占的CPUSet,但實(shí)際上Pod想定制自己的CPU分配策略,可能只是想分配到一個(gè)NUMA node內(nèi),或是固定CPU甚至是不做綁核。

2e41e24e-2429-11ed-ba43-dac502259ad0.png

在混部場(chǎng)景下,也存在離線算力感知問題。

當(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)致劇烈的資源爭(zhēng)搶,并且每個(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不能很好地解決資源競(jìng)爭(zhēng)與資源感知問題時(shí),亟需對(duì)資源進(jìn)行更加精細(xì)化的調(diào)度。

2e6189f0-2429-11ed-ba43-dac502259ad0.png

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

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

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

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

2e70e5da-2429-11ed-ba43-dac502259ad0.png

擴(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ù)洹?/strong>

在性能方面,優(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)資源分配,我們?cè)O(shè)計(jì)了一個(gè)資源分配系統(tǒng)。

2e972db2-2429-11ed-ba43-dac502259ad0.png

首先,節(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é)果。

2ea85420-2429-11ed-ba43-dac502259ad0.png

關(guān)于容器多級(jí)資源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è)物理核上的邏輯核。

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

由于離線混部場(chǎng)景中,離線會(huì)受到在線的影響,算力是波動(dòng)的。因此,在離線混部場(chǎ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ū)逐。

在不同混部場(chǎng)景下,容器CPUSet策略也是不同的。

2ec76f86-2429-11ed-ba43-dac502259ad0.png

離線CVM混部的場(chǎng)景中,一臺(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資源。

在容器混部的場(chǎng)景中,在線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的不足和混部場(chǎng)景下的算力感知的局限,最后從采集節(jié)點(diǎn)拓?fù)滟Y源、擴(kuò)展Kubernetes調(diào)度器、多級(jí)資源QoS分配策略幾個(gè)方面給出了相應(yīng)的解決方案。在策略的優(yōu)化后,資源得到更合理地利用。

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



審核編輯:劉清

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • cpu
    cpu
    +關(guān)注

    關(guān)注

    68

    文章

    11077

    瀏覽量

    217025
  • 操作系統(tǒng)
    +關(guān)注

    關(guān)注

    37

    文章

    7147

    瀏覽量

    125571
  • 調(diào)度算法
    +關(guān)注

    關(guān)注

    1

    文章

    68

    瀏覽量

    12107

原文標(biāo)題:騰訊方睿:詳解Kubernetes資源拓?fù)涓兄{(diào)度

文章出處:【微信號(hào):coder_life,微信公眾號(hào):程序人生】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。

收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評(píng)論

    相關(guān)推薦
    熱點(diǎn)推薦

    生產(chǎn)環(huán)境中Kubernetes容器安全的最佳實(shí)踐

    隨著容器化技術(shù)的快速發(fā)展,Kubernetes已成為企業(yè)級(jí)容器編排的首選平臺(tái)。然而,在享受Kubernetes帶來的便利性和可擴(kuò)展性的同時(shí),安全問題也日益凸顯。本文將從運(yùn)維工程師的角度,深入探討生產(chǎn)環(huán)境中Kubernetes容器
    的頭像 發(fā)表于 07-14 11:09 ?106次閱讀

    智能路徑調(diào)度:AI驅(qū)動(dòng)負(fù)載均衡的異常路徑治理實(shí)踐

    在AI驅(qū)動(dòng)的數(shù)據(jù)中心網(wǎng)絡(luò)環(huán)境中,傳統(tǒng)的“盡力而為”和“無差別均分”負(fù)載均衡策略已力不從心?;诼窂骄C合質(zhì)量的動(dòng)態(tài)WCMP機(jī)制,通過實(shí)時(shí)感知路徑狀態(tài)、果斷剔除異常、智能調(diào)度“健康”資源,有效解決了AI流量對(duì)網(wǎng)絡(luò)高可靠、高性能的核心
    的頭像 發(fā)表于 07-03 16:26 ?756次閱讀
    智能路徑<b class='flag-5'>調(diào)度</b>:AI驅(qū)動(dòng)負(fù)載均衡的異常路徑治理實(shí)踐

    樹莓派部署 Kubernetes:通過 UDM Pro 實(shí)現(xiàn) BGP 負(fù)載均衡!

    最近,我將家庭實(shí)驗(yàn)室的架構(gòu)核心切換為一組樹莓派。盡管在樹莓派上運(yùn)行的Kubernetes發(fā)行版眾多,但在資源受限的設(shè)備上運(yùn)行Kubernetes時(shí),控制平面的開銷是一個(gè)常見挑戰(zhàn)
    的頭像 發(fā)表于 06-25 18:00 ?253次閱讀
    樹莓派部署 <b class='flag-5'>Kubernetes</b>:通過 UDM Pro 實(shí)現(xiàn) BGP 負(fù)載均衡!

    【啟揚(yáng)方案】基于RK3588的救護(hù)車智能調(diào)度系統(tǒng)應(yīng)用解決方案

    在緊急醫(yī)療救援領(lǐng)域,救護(hù)車調(diào)度效率直接關(guān)乎患者生命與醫(yī)療資源的有效利用。然而,傳統(tǒng)的救護(hù)車調(diào)度面臨事件突發(fā)性、交通復(fù)雜、資源有限及人工決策局限等挑戰(zhàn),常導(dǎo)致響應(yīng)延遲、
    的頭像 發(fā)表于 06-12 17:26 ?256次閱讀
    【啟揚(yáng)方案】基于RK3588的救護(hù)車智能<b class='flag-5'>調(diào)度</b>系統(tǒng)應(yīng)用解決方案

    詳解Kubernetes中的Pod調(diào)度親和性

    Kubernetes(K8s)中,Pod 調(diào)度親和性(Affinity) 是一種高級(jí)調(diào)度策略,用于控制 Pod 與節(jié)點(diǎn)(Node)或其他 Pod 之間的關(guān)聯(lián)(親和)或反關(guān)聯(lián)(反親和)關(guān)系。通過親和性規(guī)則,管理員可以更精細(xì)地控
    的頭像 發(fā)表于 06-07 13:56 ?215次閱讀

    安全生產(chǎn)調(diào)度管理系統(tǒng)的核心功能模塊

    安全生產(chǎn)調(diào)度管理系統(tǒng)是運(yùn)用現(xiàn)代信息技術(shù)構(gòu)建的智能化管理平臺(tái),旨在實(shí)現(xiàn)生產(chǎn)安全風(fēng)險(xiǎn)的全面管控和應(yīng)急資源的優(yōu)化調(diào)度。該系統(tǒng)通過整合物聯(lián)網(wǎng)、大數(shù)據(jù)、人工智能等前沿技術(shù),建立起覆蓋風(fēng)險(xiǎn)監(jiān)測(cè)、預(yù)警預(yù)測(cè)、指揮
    的頭像 發(fā)表于 05-16 15:25 ?180次閱讀

    Kubernetes Helm入門指南

    Helm 是 Kubernetes 的包管理工具,它允許開發(fā)者和系統(tǒng)管理員通過定義、打包和部署應(yīng)用程序來簡(jiǎn)化 Kubernetes 應(yīng)用的管理工作。Helm 的出現(xiàn)是為了解決在 Kubernetes
    的頭像 發(fā)表于 04-30 13:42 ?2269次閱讀
    <b class='flag-5'>Kubernetes</b> Helm入門指南

    Kubernetes負(fù)載均衡器MetalLB介紹

    Kubernetes中一個(gè)應(yīng)用服務(wù)會(huì)有一個(gè)或多個(gè)實(shí)例,每個(gè)實(shí)例(Pod)的IP地址由網(wǎng)絡(luò)插件動(dòng)態(tài)隨機(jī)分配(Pod重啟后IP地址會(huì)改變)。為屏蔽這些后端實(shí)例的動(dòng)態(tài)變化和對(duì)多實(shí)例的負(fù)載均衡,引入了 Service這個(gè)資源對(duì)象。
    的頭像 發(fā)表于 03-18 16:24 ?388次閱讀
    <b class='flag-5'>Kubernetes</b>負(fù)載均衡器MetalLB介紹

    Kubernetes中部署MySQL集群

    一般情況下 Kubernetes 可以通過 ReplicaSet 以一個(gè) Pod 模板創(chuàng)建多個(gè) pod 副本,但是它們都是無狀態(tài)的,任何時(shí)候它們都可以被一個(gè)全新的 pod 替換。
    的頭像 發(fā)表于 03-18 16:22 ?283次閱讀
    <b class='flag-5'>Kubernetes</b>中部署MySQL集群

    Kubernetes包管理工具Helm的安裝和使用

    Helm 可以幫助我們管理 Kubernetes 應(yīng)用程序 - Helm Charts 可以定義、安裝和升級(jí)復(fù)雜的 Kubernetes 應(yīng)用程序,Charts 包很容易創(chuàng)建、版本管理、分享和分布。
    的頭像 發(fā)表于 03-13 16:06 ?916次閱讀

    Kubernetes Pod常用管理命令詳解

    Kubernetes Pod常用管理命令詳解
    的頭像 發(fā)表于 02-17 14:06 ?501次閱讀
    <b class='flag-5'>Kubernetes</b> Pod常用管理命令詳解

    Kubernetes:構(gòu)建高效的容器化應(yīng)用平臺(tái)

    Kubernetes 作為容器編排的事實(shí)標(biāo)準(zhǔn),在容器化應(yīng)用部署中發(fā)揮著關(guān)鍵作用。 搭建 Kubernetes 集群是應(yīng)用的基礎(chǔ)??梢允褂胟ubeadm工具快速搭建。在主節(jié)點(diǎn)執(zhí)行kubeadm
    的頭像 發(fā)表于 01-23 15:22 ?317次閱讀

    使用 Flexus 云服務(wù)器 X 實(shí)例部署 Kubernetes 圖形化管理平臺(tái)

    Kubernetes 作為當(dāng)今最流行的容器編排平臺(tái),隨著云計(jì)算、微服務(wù)架構(gòu)和 DevOps 文化的普及,Kubernetes 在自動(dòng)化部署、擴(kuò)展和管理容器化應(yīng)用程序方面扮演著越來越重要的角色。未來
    的頭像 發(fā)表于 01-21 16:14 ?339次閱讀
    使用 Flexus 云服務(wù)器 X 實(shí)例部署 <b class='flag-5'>Kubernetes</b> 圖形化管理平臺(tái)

    Kubernetes的CNI網(wǎng)絡(luò)插件之flannel

    Kubernetes設(shè)計(jì)了網(wǎng)絡(luò)模型,但卻將它的實(shí)現(xiàn)講給了網(wǎng)絡(luò)插件,CNI網(wǎng)絡(luò)插件最重要的功能就是實(shí)現(xiàn)Pod資源能夠跨主機(jī)通信。
    的頭像 發(fā)表于 01-02 09:43 ?808次閱讀

    使用Velero備份Kubernetes集群

    Velero 是 heptio 團(tuán)隊(duì)(被 VMWare 收購)開源的 Kubernetes 集群備份、遷移工具。
    的頭像 發(fā)表于 08-05 15:43 ?640次閱讀
    使用Velero備份<b class='flag-5'>Kubernetes</b>集群