深入解讀基礎軟體雲原生面臨的挑戰 | 龍蜥技術

2022 長沙 · 中國 1024 程式設計師節已於 10 月 23 - 25 日在長沙、北京等多地圓滿舉行。本次程式設計師節以“算力新時代，開源創未來”為活動主題，開設十餘場專業主題論壇，覆蓋多個技術領域。龍蜥社群雲原生 SIG Owner 王強在1024程式設計師節北京峰會分享《基礎軟體雲原生挑戰》演講，以下是本次演講內容：

雲原生的定義比較多，有 CNCF 的，也有各大雲廠商的一些定義，廣義的雲原生是應運而生的系統架構，生在雲上，長在雲上，能夠充分地利用雲端計算的基礎設施。cncf 裡面的定義更多是關注在技術和架構層面，透過容器、微服務、 不可變基礎設施、宣告式 API，基於雲，實現現代應用架構的構建。

經過這些年的發展，可以看到準備或者已經在生產環境使用容器技術的使用者數已經達到受訪者的 93%，這是一個相當高的比例。同時 2021 年 CNCF 也釋出年度調查報告，宣佈跨越鴻溝，成為容器編排的事實標準。可以看到雲原生的趨勢已經勢不可擋。

那麼雲原生給我們帶來了哪些變化，對於底層開發同學，這些變化裡面蘊含著哪些機會？結合下面的圖我們來看看。

傳統形態裡面，使用者是需要完整負責軟硬體技術棧，不單需要懂你的程式，你的程式執行的軟體環境，還需要懂你機器的硬體環境。這種時候真要做一個應用挑戰是比較大的，需要找 OS，還需要管執行應用的物理機器部署到哪裡，網路怎麼辦等等。

到了虛擬化或者 IAAS 場景裡面，我們只需要負責程式和軟體原型環境，硬體相關的就交給 IAAS 提供方負責。這裡面之前物理環境、物理網路這些就不需要再關心，只需要關注好自己的應用和基礎OS 環境。但是 OS 相關人才是很稀缺的，真正需要解決底層問題，或者想充分發揮底層硬體的效能，這塊對使用者來說門檻很高。IAAS 相關技術已經發展了十多年，整體上也還有不少挑戰，不過對上層已經相對比較成熟。

到雲原生場景，透過標準化應用執行環境和應用編排系統，使用者就只需要關注業務邏輯，這樣能夠大大節省底層相關開銷，提升創新速度。但是使用者的簡單，意味著平臺層的挑戰就更大，需要將應用或者函式執行的 runtime、OS、kernel都進行覆蓋，當然挑戰和機遇並存，也正因為這些挑戰，同時也給了基礎軟體同學更多的機會。

使用者介面上移，帶給我們哪些挑戰和機會？我們可以先整體看看雲原生系統的架構。最上層是雲原生應用，其中容器場景我們有一層是應用執行環境——容器映象，函式場景也還好包含語言 runtime。第二層左邊是雲原生管控，負責應用定義、業務編排、服務框架。右邊是我們核心關注的雲原生節點系統。裡面可以分為雲原生節點管控、節點安全、節點運維、雲原生執行時，雲原生儲存，雲原生網路，以及底層支撐容器執行的容器最佳化 OS。最下面的是支撐整體雲原生的基礎設施服務。接下來我們來看下各個子模組裡面的一些具體挑戰。

首先來看下最底層的雲原生容器 OS。傳統的 OS，由於需要考慮複雜的應用執行環境，需要內建大量的服務和驅動，整體 OS 存在體積臃腫的問題。同時由於OS 使用者可以直接修改，沒有合適的管理，很容易出現節點 OS 版本零散，進而叢集的 OS 環境狀態不一致，問題定位和升級困難。另外傳統作業系統裡面包含有大量容器場景不需要的包和系統服務，容易給雲原生帶來更大的攻擊面。另外雲原生場景，根據業務流量，動態的對節點進行擴縮容是常態，可以有效降低業務成本。但是動態擴縮容場景，傳統 OS 並沒有包含雲原生相關元件，導致 OS 擴容後需要逐個下載包，並啟動服務，高併發情況下載和啟動服務都可能帶來穩定性風險，同時也因為這些耗時操作，也會導致節點擴容耗時高，進而影響使用者使用。

針對這樣系列挑戰，社群和雲廠商紛紛推出了容器最佳化 OS，比如阿里雲的LifseaOS、AWS 的 BottlerocketOS；紅帽的 CoreOS，也足見相關挑戰在雲原生場景下的共識。

接下來我們再來看看雲原生執行時的挑戰。

傳統 Linux 原生容器直接跑在節點上面，不同業務和租戶的容器透過節點進行隔離，由於共享核心且無有效安全隔離，存在較多的安全風險挑戰。同時這種隔離存在資源碎片問題，也無法有效的利用不同容器的特徵實現整體利用率的提升。針對這些問題，雲原生裡面又湧現出了執行時。安全容器是比較早出現的，透過結合虛擬化技術和容器技術，有效的避免了容器逃逸帶來的風險，保障了節點的安全。但是引入的虛擬化層，又同時帶來了比較大的開銷，這也是很多人不敢使用安全容器的一個擔心。不過有問題其實也就意味著機遇，這些年連續出現了gvisor、firecracker、rund 等相關技術，核心是用來解決安全容器的資源開銷挑戰問題，可以說透過虛擬化技術和容器結合，開闢了一個新的方向，帶來了諸多的機會，透過這些年的發展也取得了不錯的成果。

針對不同業務和租戶混合部署的問題，同時也出現了另一個虛擬機器容器，透過 k8s 來管理虛擬機器，讓使用者既能夠支援原來 IAAS 層的虛擬機器相關資源，同時也能夠支援容器。

隨著機密計算 TEE 相關硬體技術的發展，機密容器也應運而生，透過機密容器，能夠讓基礎設施無法訪問到容器內部的資料，進一步保障了使用者的隱私安全。在越來越重視隱私的未來，這塊也必將得到更多的應用。但是機密容器當前始終面臨的大挑戰是效能，加密的記憶體、加密的儲存、加密的網路，都給當前的軟體棧帶來了比較重的負擔，需要軟硬體結合發展，才能夠最終實現機密容器的普惠發展。

雲原生儲存是一個比較寬泛的概念，這裡我們簡單看下里面容器映象和資料加速方面的。

容器帶來了應用打包分發的標準化，但同時也讓應用需要額外包含一個執行應用的環境，讓應用體積成倍增大。在併發場景，由於不同節點的 pod 啟動都需要下載映象，映象倉庫的頻寬往往會成為瓶頸。另外容器映象單獨儲存，也使得容器啟動依賴於映象下載，對應一些 serverless 場景映象下載會嚴重拖慢容器啟動速度。此外，對於存放大量映象的映象倉庫，裡面每個容器都包含有一個執行環境的基礎映象，這部分是有大量的重複資料，如何能夠有效的提升儲存效率也是一個比較有挑戰的工作。

隨著學術界研究表明一般容器映象只有 6% 內容會被實際使用，直接牽動了整個容器映象的大量最佳化工作，比如容器映象的按需載入，比如 P2P。各大雲廠商為了解決容器映象載入問題，也是各顯神通，有將映象整合到雲盤的，有為映象構建索引檔案的，有構建新的映象儲存格式的。但是目前還沒有形成一個統一的方案，也沒有形成標準，這塊後面還有不少路需要走。

儲存裡面另外一塊是資料加速挑戰，大資料和 AI 場景雲原生應用依賴的資料量往往比較大，但是這些資料裡面真實訪問的往往只是裡面很小一部分，而且會有比較多的熱點。是否能夠透過小的快取，實現大儲存資料訪問的加速，是一個比較有挑戰的。另外 AI 場景，由於 GPU 很多資料依賴於儲存，由於儲存訪問速度慢進而拖慢整個 GPU 資源使用效率問題比較常見，如何有效地提升這些資料訪問頻寬。

這塊這幾年開源的比較多，比如 Nydus、Dragonfly、fluid、stargz 等，給大家帶來了比較多的選擇。

看完儲存，再來看下雲原生網路。

雲原生場景，同時隨著微服務化和函式化，例項規格也越來越小，同時便捷的擴縮容也對網路彈性提出了較大的挑戰。為了避免故障影響面，通常需要將服務分散到不同的物理節點部署，在規模大的情況，路由更新會是一個比較慢的過程，需要數秒甚至到分鐘級，對雲原生應用快速彈性帶來了比較大的制約。同時隨著規格的減小，單節點部署的例項規模也會越來越高，這種情況如何支撐單節點的高密網路，也是存在比較大的挑戰。另外，隨著核心 eBPF 技術的發展，給雲原生網路最佳化也帶來了諸多機會，基於eBPF 的 kube-proxy 最佳化，基於 eBPF 最佳化ovs，也是有不少的機會點。

最後再來看看雲原生安全。中國開源界這幾年在快速的發展，而且是越來越正規的發展，安全在開源裡面挑戰確實很大，因為開源軟體本身供應鏈上面沒有很好的保障，大家都可以往裡面貢獻程式碼，所以安全這個地方確實是真的很需要大家下功夫的一個點。雲原生作為整體底層架構的創新，也同樣面臨諸多安全挑戰。

在供應鏈安全上，我們可以看到容器映象安全是個大的挑戰，大量公用的容器映象，並沒有直接為其來源進行有效稽核和跟蹤。配置檔案安全也是雲原生一大關注點，使用者證照的安全保障，節點被攻擊後如何有效避免對整個叢集的攻擊。再就是雲原生軟體棧安全，軟體棧的 cve 維護和更新，軟體棧供應鏈的安全。同時執行時也面臨不少安全挑戰，之前已經介紹過，這裡不再展開。

另外一個就是安全的檢測和風險阻斷。基於 eBPF 能夠實現輕量的安全檢查，同時也構建了越來越完善的安全阻斷能力，這給傳統的安全檢測和風險阻斷帶來了不少機遇。

基於過去的一些經驗給大家分享了一些在雲原生技術上的挑戰，阿里雲過去幾年在雲原生領域成立了袋鼠雲原生底層系統相關的組，我們是整個專注在底層系統核心技術上突破。同時，在這個過程中我們也積極的參與上游開源社群，在內部構建自己系統的時候也希望這些技術開源出來讓大家共同使用，整體推動國內基礎軟體在雲原生領域得到蓬勃的發展。

當然，我們也成立了龍蜥雲原生 SIG，專注在雲原生底層系統上的構架，我們希望秉承著開放協作、共迎挑戰、共創雲原生未來這樣一個方式和社群夥伴攜手共進。希望大家能夠體驗我們容器雲原生這塊的技術，真正把這些技術應用到生產環境，幫助業務獲得更低的成本、更高效能、更可靠的安全性。

2022年雲棲大會，龍蜥社群特設雲原生專場分享，點選 這裡一鍵檢視詳情，本次專場只對外開放 30 個報名名額，報名且現場參會的同學人人一份龍蜥伴手禮！記得報名~

雲原生 SIG 地址連結：

—— 完 ——