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

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

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

1 K8S綜述

1.1 K8S容器虛擬化

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

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

Kubernetes是一個開源的容器編排平臺，自動完成應用容器的部署、管理和擴展。Kubernetes簡寫為K8s。

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

參考文獻：

Docker-從入門到實踐，https://yeasy.gitbook.io/docker_practice/

Kubernetes 簡介，https://juejin.cn/post/7243081126826016805

容器技術之容器引擎與江湖門派（外宣版），https://developer.aliyun.com/article/778752

Kubernetes 基礎教程，https://lib.jimmysong.io/kubernetes-handbook/

1.2 從硬件視角看K8S存在的問題

K8S存在問題嗎？說真的，作為還跨在門檻上的我，很難給出全面而權威的答案。

但從底層軟硬件的視角，還是可以來分析分析K8S的問題的。

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

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

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

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

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

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

2.1 業(yè)務快速變化

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

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

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

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

2.2 算力無法靈活、充分的利用

2.2.1 算力的粒度

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

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

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

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

“不受硬件約束，軟件隨心所欲的虛擬化”，對硬件加速器來說，是一種奢望。

2.2.2 算力的匹配度

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

如果我們在服務器上準備的加速處理器是專用的加速，這意味著，在絕大部分時間里，客戶的業(yè)務可能無法把這個算力資源用起來。

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

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

長期來看，業(yè)務可能只有5%左右的時間里，可以利用硬件加速的資源；

并且，即使在這5%左右的時間里，能利用到的算力也僅有標稱算力的5%左右；

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

2.2.3 算力的協(xié)同

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

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

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

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

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

3.1 硬件應該怎么做？

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

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

3.2 框架應該怎么做？

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

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

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

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

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

3.3 業(yè)務軟件應該怎么做？

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

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

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

4 KubeCASH：基于軟硬件融合的容器管理平臺

4.1 KubeCASH綜述

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

4.2 底層計算架構：支持同構、異構、多異構和異構融合

KubeCASH的四個演進階段：

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

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

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

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

4.3 應對多樣性算力的挑戰(zhàn)

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

KubeCASH，能夠實現(xiàn)更多算力的接入，能夠更好的匹配算力和業(yè)務，能夠實現(xiàn)多種架構處理器算力的充分利用，能夠實現(xiàn)多樣性算力的充分協(xié)同，以此滿足上層業(yè)務日益快速增長的算力需求。

4.4?KubeCASH開源項目

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

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

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

（正文完）