編者按

Kubernetes（K8S）雖然強(qiáng)大，但也有劣勢(shì)，劣勢(shì)在于K8S主要基于CPU平臺(tái)。有的朋友可能會(huì)說(shuō)，不是有CDI嗎，可以實(shí)現(xiàn)硬件加速器的支持。但其實(shí)CDI能做的事情非常有限，CRI、CNI、CSI、CDI等接口都奉行一個(gè)重要的原則：“不做事，就不會(huì)犯錯(cuò)”。K8S可以理解成嵌于整個(gè)軟硬件堆棧的一個(gè)薄層，僅僅提供硬件到容器環(huán)境的一個(gè)接入。至于具體的軟硬件交互接口和機(jī)制、硬件加速器的系統(tǒng)架構(gòu)和實(shí)現(xiàn)、如何把硬件性能和性能價(jià)值充分發(fā)揮出來(lái)的計(jì)算框架，以及硬件加速原生的軟件架構(gòu)規(guī)范等等，它統(tǒng)統(tǒng)不管。

透過(guò)現(xiàn)象看本質(zhì)，核心的問(wèn)題在于軟件和硬件之間的已經(jīng)產(chǎn)生的巨大鴻溝。做軟件的朋友，在CPU的環(huán)境里，任意馳騁，各種花活玩的很溜；但CPU性能的天花板，使得大家所能玩的越來(lái)越有限，像AI大模型、高階智駕等場(chǎng)景，在容器環(huán)境都很難高效的用起來(lái)。做硬件加速芯片的朋友，距離業(yè)務(wù)很遠(yuǎn)，做出來(lái)的東西，也許很好，但能覆蓋的場(chǎng)景和迭代很少，加速芯片很難大規(guī)模的用起來(lái)。軟硬件鴻溝的本質(zhì)挑戰(zhàn)，難啃的骨頭，K8S也愛(ài)莫能助。

KubeCASH，聚焦于啃硬骨頭，實(shí)現(xiàn)K8S相關(guān)軟件和其他各種加速類型處理器的整合，充分壓榨硬件加速器的性能和多樣性算力的價(jià)值。給K8S裝上騰飛的翅膀，單車變火箭。KubeCASH的目標(biāo)是：相比目前的CPU/GPU平臺(tái)，給客戶提供100+倍的性能提升；以及單位算力成本下降到1%以下。

1 K8S綜述

1.1 K8S容器虛擬化

容器屬于OS層虛擬化技術(shù)，基于Linux內(nèi)核cgroup、namespace、Union FS等技術(shù)，對(duì)進(jìn)程進(jìn)行封裝隔離。最知名的容器引擎Docker，最初基于LXC，從1.11版本開(kāi)始，使用Runc和containerd。

容器的優(yōu)勢(shì)：高效利用系統(tǒng)資源、快速啟動(dòng)、一致的運(yùn)行環(huán)境、持續(xù)交付和部署、更輕松的遷移、更輕松維護(hù)和擴(kuò)展。

Kubernetes是一個(gè)開(kāi)源的容器編排平臺(tái)，自動(dòng)完成應(yīng)用容器的部署、管理和擴(kuò)展。Kubernetes簡(jiǎn)寫(xiě)為K8s。

K8s集群由主節(jié)點(diǎn)（Master）與工作節(jié)點(diǎn)（Worker）組成。這些節(jié)點(diǎn)可以運(yùn)行在VM、物理機(jī)，或公有云實(shí)例上。K8s主節(jié)點(diǎn)，是集群控制面系統(tǒng)服務(wù)的集合。包括API服務(wù)器、控制器管理器、調(diào)度器、ETCD。K8s工作節(jié)點(diǎn)，是K8s集群的實(shí)際容器運(yùn)行的節(jié)點(diǎn)。每個(gè)工作節(jié)點(diǎn)上運(yùn)行的組件包括：節(jié)點(diǎn)本地總控Kubelet、容器運(yùn)行時(shí)、集群網(wǎng)絡(luò)的Kube-proxy、以及運(yùn)行調(diào)度原子單位Pod。

1.2 從硬件視角看K8S存在的問(wèn)題

K8S存在問(wèn)題嗎？說(shuō)真的，作為還跨在門(mén)檻上的我，很難給出全面而權(quán)威的答案。

但從底層軟硬件的視角，還是可以來(lái)分析分析K8S的問(wèn)題的。

我們之前就說(shuō)過(guò)，當(dāng)軟硬件解耦之后，軟件和硬件才能完全的放飛自我，快速迭代發(fā)展。K8S，就是在完全解耦的CPU平臺(tái)上，完全不考慮硬件的情況下，做出來(lái)的既強(qiáng)大又優(yōu)秀，還得到廣大開(kāi)發(fā)者認(rèn)可的容器編排工具，同時(shí)基于K8S已經(jīng)形成了云原生的龐大生態(tài)。

從底層軟硬件視角看，K8S，或者說(shuō)K8S生態(tài)的問(wèn)題主要在于：

K8S生態(tài)主要基于CPU。然而，我們的CPU已經(jīng)存在了50多年的時(shí)間了，早已不堪重負(fù)，CPU做點(diǎn)管理工作還行，做點(diǎn)性能敏感的計(jì)算這點(diǎn)“重體力”活，會(huì)累得夠嗆。而K8S生態(tài)對(duì)硬件加速的支持很少。

相比虛機(jī)，K8S容器完全“脫實(shí)向虛”。K8S基于一個(gè)標(biāo)準(zhǔn)化的解耦的軟硬件接口——CPU架構(gòu)，不用不考慮硬件對(duì)軟件的影響。基于CPU實(shí)現(xiàn)的標(biāo)準(zhǔn)化軟硬件接口，意味著擴(kuò)展新的加速硬件處理器就變得很難，其他各種性能更優(yōu)的硬件加速器就很難加入到K8S的底層計(jì)算平臺(tái)支撐。

一方面，K8S以應(yīng)用為中心，相比虛機(jī)（以硬件資源為中心），對(duì)硬件靈活性的要求要更高。而另一方面，加速處理器在增加性能的時(shí)候，其靈活性勢(shì)必是降低的。這樣，兩者背向而行，硬件加速處理器就變得愈發(fā)無(wú)法滿足K8S的更高靈活性要求。

2 硬件加速器面臨的挑戰(zhàn)

2.1 業(yè)務(wù)快速變化

本質(zhì)的講，隨著業(yè)務(wù)越來(lái)越龐大，越來(lái)越復(fù)雜，其變化也就越來(lái)越快，想用專用的加速器去實(shí)現(xiàn)業(yè)務(wù)的加速，勢(shì)必越來(lái)越難。

作為底層芯片開(kāi)發(fā)者，即使再努力，也只能捕捉到一個(gè)高質(zhì)量的業(yè)務(wù)的瞬時(shí)狀態(tài)而已。等花費(fèi)大量人力物力以及時(shí)間成本，把硬件加速器做好的時(shí)候，業(yè)務(wù)早已變的“面目全非”。

用“面目全非”來(lái)形容業(yè)務(wù)，并不夸張。上層的軟件業(yè)務(wù)通常是2個(gè)月一個(gè)小迭代，半年一個(gè)大迭代，作為算法和業(yè)務(wù)邏輯的開(kāi)發(fā)者來(lái)說(shuō)，都很難預(yù)料未來(lái)兩年三年，算法和業(yè)務(wù)會(huì)變成什么樣子。

業(yè)務(wù)開(kāi)發(fā)者自己都很難把握業(yè)務(wù)的發(fā)展方向，底層的芯片開(kāi)發(fā)者則更難把握業(yè)務(wù)；并且，芯片的開(kāi)發(fā)周期2年，生命周期5年，這么長(zhǎng)的時(shí)間周期，更難預(yù)判業(yè)務(wù)的未來(lái)發(fā)展。

2.2 算力無(wú)法靈活、充分的利用

2.2.1 算力的粒度

通過(guò)虛擬化，可以實(shí)現(xiàn)資源按粒度自由切分和重組。虛擬化能力是系統(tǒng)靈活性的一種體現(xiàn)：

CPU是一個(gè)非常好的處理器，線程調(diào)度可以讓很多軟件共享單個(gè)CPU Core，虛擬化可以實(shí)現(xiàn)用于軟件工作任務(wù)的資源彈性?？梢园袰PU按照時(shí)間片的細(xì)粒度進(jìn)行劃分，然后分配給軟件。我們給軟件工作任務(wù)分配的CPU核的數(shù)量可以是萬(wàn)分之一、千分之一、百分之一、一、十、百等各種不同的規(guī)格，非常的靈活。因?yàn)镃PU是完全軟件化的運(yùn)行平臺(tái)，軟件開(kāi)發(fā)者可以隨心所欲，做任何可以想象到的事情。

而GPU的虛擬化共享，就比較困難。很長(zhǎng)一段時(shí)期，GPU并不支持虛擬化和可擴(kuò)展性。目前，GPU即使支持虛擬化，其虛擬化功能也非常的有限，比如有的GPU支持把設(shè)備虛擬化成若干固定的份數(shù)，這些是硬件支持的能力，而軟件仍然無(wú)法自由定義虛擬化的份數(shù)。

GPU已經(jīng)是相對(duì)靈活的加速處理器了，其他的各類更偏專用的加速處理器器，就更難談對(duì)虛擬化的支持了。

“不受硬件約束，軟件隨心所欲的虛擬化”，對(duì)硬件加速器來(lái)說(shuō)，是一種奢望。

2.2.2 算力的匹配度

云計(jì)算也好，邊緣計(jì)算也好，在服務(wù)器上運(yùn)行什么樣的業(yè)務(wù)，其實(shí)是非常不確定的。

如果我們?cè)诜?wù)器上準(zhǔn)備的加速處理器是專用的加速，這意味著，在絕大部分時(shí)間里，客戶的業(yè)務(wù)可能無(wú)法把這個(gè)算力資源用起來(lái)。

此外，受用戶業(yè)務(wù)差異性和迭代的影響，硬件加速器跟業(yè)務(wù)算法和邏輯可能存在偏差，致使算力的利用率很低。

可以說(shuō)，實(shí)際環(huán)境，硬件加速器和業(yè)務(wù)的匹配度存在偏差的可能性極高。我們稍微量化一下：

長(zhǎng)期來(lái)看，業(yè)務(wù)可能只有5%左右的時(shí)間里，可以利用硬件加速的資源；

并且，即使在這5%左右的時(shí)間里，能利用到的算力也僅有標(biāo)稱算力的5%左右；

兩者相乘，意味著算力的實(shí)際利用率僅有0.25%。

2.2.3 算力的協(xié)同

因?yàn)镃PU已經(jīng)性能瓶頸，因?yàn)镚PU逐漸性能瓶頸，我們不得不選擇越來(lái)越多的加速算力。在微觀的芯片和設(shè)備級(jí)，我們把這樣的計(jì)算架構(gòu)稱為多/超異構(gòu)、異構(gòu)融合；在宏觀的數(shù)據(jù)中心以及云網(wǎng)邊端級(jí)，我們把它描述為多元異構(gòu)、算力多樣性等等。

不管怎么稱呼，異構(gòu)的算力越來(lái)越多，已經(jīng)成為共識(shí)。那么，緊接著的挑戰(zhàn)，就是如何把這么多的異構(gòu)算力資源充分協(xié)同起來(lái)。

“一根筷子輕輕被折斷，十雙筷子牢牢抱成團(tuán)”，如果無(wú)法實(shí)現(xiàn)如此多異構(gòu)算力的協(xié)同計(jì)算，那么一盤(pán)散沙的多樣性算力，幾乎碎到不能再碎的各自私有的軟硬件生態(tài)，不但無(wú)法解決算力挑戰(zhàn)的問(wèn)題，反而會(huì)使得系統(tǒng)越來(lái)越復(fù)雜，最后得不償失。

3 軟硬件之間的鴻溝需要填平

軟件和硬件的矛盾如此嚴(yán)重，那該如何做？拋磚引玉，我們給出的答案是：全棧協(xié)同優(yōu)化。

3.1 硬件應(yīng)該怎么做？

硬件上，一方面是需要集成更多的異構(gòu)算力，實(shí)現(xiàn)顯著的Scale Up。從計(jì)算架構(gòu)的角度，則是從CPU的同構(gòu)計(jì)算、GPU/AI處理器等的異構(gòu)計(jì)算，再到更多異構(gòu)集成的多/超異構(gòu)計(jì)算，最終實(shí)現(xiàn)更多異構(gòu)處理器充分協(xié)同和融合的異構(gòu)融合計(jì)算。

當(dāng)然，只實(shí)現(xiàn)更多異構(gòu)的融合計(jì)算還不夠。受限于業(yè)務(wù)的差異性和快速迭代，芯片需要足夠通用。依據(jù)“二八原理”，系統(tǒng)越來(lái)越復(fù)雜，沉淀下來(lái)的確定性的不怎么變化的工作任務(wù)就越多，因此可以通過(guò)CPU+GPU+多個(gè)DSA的方式，以及軟硬件融合設(shè)計(jì)能力，實(shí)現(xiàn)通用的異構(gòu)融合計(jì)算。

3.2 框架應(yīng)該怎么做？

計(jì)算框架是非常關(guān)鍵的部分，承上啟下：上接業(yè)務(wù)軟件，下接硬件處理器。其主要工作包括：

首先，本職工作。能夠把硬件加速器的性能和性能價(jià)值徹底的發(fā)揮出來(lái)。

其次，計(jì)算框架要能和K8S的集群管理系統(tǒng)完美融合，充分實(shí)現(xiàn)虛擬化支持以及基于容器的計(jì)算和調(diào)度。

再次，計(jì)算框架需要實(shí)現(xiàn)跨處理器運(yùn)行。比如能夠基于CPU、GPU和DSA處理器運(yùn)行。

最后，不同處理器的子框架還需要整合，實(shí)現(xiàn)多種架構(gòu)處理器的協(xié)同和融合，實(shí)現(xiàn)支持異構(gòu)“融合”計(jì)算的宏計(jì)算框架。

3.3 業(yè)務(wù)軟件應(yīng)該怎么做？

這里，我們借用“云原生”的概念，給出一個(gè)新概念“硬件加速原生”。

硬件加速原生：指的是，軟件在架構(gòu)設(shè)計(jì)的時(shí)候，就要把控制面和數(shù)據(jù)面分離，然后定義好兩者之間交互的標(biāo)準(zhǔn)化接口；這樣，后續(xù)優(yōu)化的時(shí)候，就可以在不改變既有運(yùn)行機(jī)制的情況下，快速友好的實(shí)現(xiàn)數(shù)據(jù)面的硬件加速器運(yùn)行。這個(gè)時(shí)候，控制面仍然運(yùn)行在CPU，而數(shù)據(jù)面可以在CPU和硬件加速器自由切換，或者實(shí)現(xiàn)類似快慢路徑的兩路并行機(jī)制。

軟件在架構(gòu)設(shè)計(jì)的時(shí)候，就考慮硬件加速的支持，可以實(shí)現(xiàn)“硬件加速原生”的軟件開(kāi)發(fā)，可以實(shí)現(xiàn)業(yè)務(wù)軟件對(duì)硬件加速的支持，可以實(shí)現(xiàn)業(yè)務(wù)性能多個(gè)數(shù)量級(jí)的提升和運(yùn)行成本多個(gè)數(shù)量級(jí)的下降。

4 KubeCASH：基于軟硬件融合的容器管理平臺(tái)

4.1 KubeCASH綜述

KubeCASH，Kubernetes + CASH（Converged Architecture of Software and Hardware，軟硬件融合架構(gòu)），實(shí)現(xiàn)基于軟硬件融合的、充分壓榨硬件算力及算力價(jià)值的、開(kāi)源開(kāi)放的容器管理平臺(tái)。

4.2 底層計(jì)算架構(gòu)：支持同構(gòu)、異構(gòu)、多異構(gòu)和異構(gòu)融合

KubeCASH的四個(gè)演進(jìn)階段：

第一階段，僅支持CPU處理器。包括x86、ARM和RISCv；

第二階段，僅支持GPU加速處理器。包括NVIDIA GPU和AMD GPU，未來(lái)也考慮支持國(guó)產(chǎn)GPU。

第三階段，逐步加入對(duì)更多加速處理器的支持。這些處理器可以是集成單芯片，也可以是單個(gè)服務(wù)器里的多個(gè)分立的處理器，還可以是通過(guò)集群/跨集群實(shí)現(xiàn)的各種不同架構(gòu)的遠(yuǎn)程處理器資源。

第四階段，在第三階段基礎(chǔ)上實(shí)現(xiàn)異構(gòu)融合的支持，充分實(shí)現(xiàn)各種異構(gòu)處理器、多樣性算力之間的協(xié)同和融合。

4.3 應(yīng)對(duì)多樣性算力的挑戰(zhàn)

在2.2節(jié)我們介紹了算力無(wú)法充分利用的問(wèn)題，這里簡(jiǎn)單概括一下：一方面，算力的匹配度導(dǎo)致算力利用率非常低，另一方面，算力之間沒(méi)有協(xié)同效應(yīng)，越來(lái)越多的異構(gòu)算力，越使得系統(tǒng)走向失衡。

KubeCASH，能夠?qū)崿F(xiàn)更多算力的接入，能夠更好的匹配算力和業(yè)務(wù)，能夠?qū)崿F(xiàn)多種架構(gòu)處理器算力的充分利用，能夠?qū)崿F(xiàn)多樣性算力的充分協(xié)同，以此滿足上層業(yè)務(wù)日益快速增長(zhǎng)的算力需求。

4.4KubeCASH開(kāi)源項(xiàng)目

KubeCASH，聚焦于啃硬骨頭，實(shí)現(xiàn)K8S相關(guān)軟件和其他各種加速類型處理器的整合，充分壓榨硬件加速器的性能和多樣性算力的價(jià)值。給K8S裝上騰飛的翅膀，單車變火箭。

KubeCASH的目標(biāo)是：相比目前的CPU/GPU平臺(tái)，給客戶提供100+倍的性能提升；以及單位算力成本下降到1%以下。

軟硬件融合技術(shù)社區(qū)，發(fā)起KubeCASH開(kāi)源項(xiàng)目，尋找“同頻共振”的伙伴一起，共同開(kāi)發(fā)，共襄盛舉。

審核編輯：湯梓紅