編者按

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

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

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

1 K8S綜述

1.1 K8S容器虛擬化

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

容器的優勢：高效利用系統資源、快速啟動、一致的運行環境、持續交付和部署、更輕松的遷移、更輕松維護和擴展。

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

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

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

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

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

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

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

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

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

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

2 硬件加速器面臨的挑戰

2.1 業務快速變化

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

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

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

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

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

2.2.1 算力的粒度

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

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

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

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

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

2.2.2 算力的匹配度

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

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

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

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

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

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

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

2.2.3 算力的協同

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

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

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

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

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

3.1 硬件應該怎么做？

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

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

3.2 框架應該怎么做？

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

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

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

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

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

3.3 業務軟件應該怎么做？

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

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

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

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

4.1 KubeCASH綜述

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

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

KubeCASH的四個演進階段：

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

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

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

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

4.3 應對多樣性算力的挑戰

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

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

4.4KubeCASH開源項目

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

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

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

審核編輯：湯梓紅