兩三年前，雲原生勢頭正盛，開始“侵入”各大公司。三年過後，隨著雲原生 2.0 時代的到來以及落地實踐進度的加快，業內對雲原生又有了很多新的理解，對其可為業務帶來的實際價值有了更多感觸，容器的圈子也經歷了一輪洗禮。在各大公司紛紛表示已經邁入雲原生 2.0 時代的今天，我們有幸可以和 KubeSphere 容器平臺產品負責人於爽交流下當前雲原生領域值得關注的技術趨勢和落地方向。

容器的圈子開始捲了嗎？

K8s 專案發展至今，已成為雲端計算領域平臺層當仁不讓的事實標準，但其複雜性、學習曲線陡峭也是不爭的事實。於是，我們在過去三年看到了一眾基於 K8s 衍生出的專案，試圖降低使用者部署 K8s 的難度，並且隨著開源運動的興起，這些專案大都選擇了開源的方式運營。類似的專案，相同的運營方式，競爭在所難免，難道容器的圈子開始內捲了嗎？

“兩三年前，確實有使用者會找來一堆與 KubeSphere 類似的開源專案讓我們提供比較結果，甚至有些開源專案，我們都沒見過。”

如今，CNCF 基金會的雲原生全景圖已經相當龐大，涵蓋基礎設施層、執行時層、編排和管理層、應用定義和開發層以及貫穿所有層的平臺解決方案、可觀察性和分析工具，並且經過這三年的發展，很多專案已經從初級版本走向成熟，擁有穩定的擁護者和使用者。

“三年前，使用者可能需要不少的時間抉擇自己需要的專案，如今從開源社群的角度來看，圍繞著容器平臺的專案基本穩定，也有一些專案在這三年走向淘汰，使用者結合具體的業務場景很容易就可以做好選型。” 從這個角度看，容器的圈子並沒有在過去三年逐步內卷，反而越來越清晰，留下來的專案都有了各自的棲身之地，淘汰的專案原因各不相同，而開源不易是其中很重要的一項影響因素。

專案地址： http://github.com/kubesphere/kubesphere

開源，很容易走彎路

“開源這件事情，我們起初也走了一些彎路。”

從表面上看起來，一家商業公司運營一個開源專案似乎很簡單：將程式碼放到 GitHub 上或者將專案捐獻給某一個基金會，然後建立社群把有相同想法的人聚攏在一起，接下來就是使用者群體不斷壯大，專案不斷更新迭代，最後成功畢業或者走向成熟，這套流程看起來非常水到渠成，但具體到執行層面，有很多問題需要考慮：一個全新的開源專案怎麼讓開發者信任並參與？如何運營開源社群是有效的模式？哪些功能應該貢獻給社群？

開源社群通常不是由一個人控制的，基於商業公司運營的開源專案情況更加複雜。有時候，同一個功能，社群的實現思路和公司不一樣；有時候，公司規劃了一個商業功能，社群提前做出來了......

在 KubeSphere 開源之初，整個團隊想的是把程式碼寫好就可以了，後來的運營過程中發現這種想法是有問題的，如果開源之初沒有想好目標，只是為了開源而開源，就會導致後面的很多工作無法正常開展，把程式碼提交到 GitHub 並不代表開源目標就完成了，如果沒有種子開發者的信任和推廣，很難真正做起來，但怎麼讓種子開發者信任呢？

“我們前期和很多開源領域的資深專家做過溝通。事實上，種子使用者們對開源專案的接受度非常高，對新的開源專案容忍度也非常高，但這一切的前提是你的程式碼和開源文件都足夠完善，只要他可以按照你的文件和程式碼解決實際問題，就會對專案產生信任，從而自發向外推薦。”

雖然種子使用者的容忍度很高，但這批人的技術水平也非常高，亂搞肯定是不行的，於爽補充道，一個完備的開源專案應該擁有完善的開發文件、清晰的技術架構圖，並且有一個清晰的路線圖，願意傾聽種子使用者的建議。如果種子使用者都沒了，轉而去孵化後面的小白使用者，整個鏈條就斷掉了，肯定是做不好的。

過去幾年，我們也看到了一些專案的沒落，大多是團隊沒有意識到開源的價值，沒有真正弄懂開源，進而導致專案的發展呈現負向迴圈，越做越沮喪，甚至成為整個團隊的累贅。

如今，KubeSphere 3.1.0 版本已正式釋出，該版本包含了來自 KubeSphere 社群及企業使用者發現的 bug 及提出 的需求，涉及到 KubeSphere 前後端各個元件；全球近 100 位貢獻者參與 3.1.0 的開發、測試工作，有個人愛 好者，也有大量的企業使用者、開源專案參與貢獻，如中通、銳捷、馬上消費金融、紅亞科技、Kube-OVN 等；主倉庫 160 多個 PR 提交。在 3.1.0 版本 之後，KubeSphere 小版本的釋出頻率會更頻繁。

“回頭想想，做開源專案就好像在下棋，然後旁邊有很多人在指導你，你不單單是在做一個專案，也是在交朋友、做圈子。如果你是純做商業產品，圈子就會非常垂直，集中在和商業閉環這個圈裡的人打交道。”

除了技術的文件層面準備就緒，青雲自上而下對開源的認知也讓 KubeSphere 從誕生之初就決定走全球化的路線，而不是閉門造車，為此開通了海外溝通方式，並提供了大量英文素材，希望全球開發者都可以加入到其中平等溝通，並設定了專門的運營團隊負責對接全球開發者提的問題，管理開發者關係，為開源社群輸送對應的文件和資料。

現在擁抱 FaaS 的理由是什麼？

基於上述認知，KubeSphere 得以在容器圈擁有一席之地，並於近日新增了 FaaS（函式計算）支援。事實上，FaaS 在雲原生的圈子裡也不是什麼新鮮概念，這代表著一種計算模式，可以極致優化資源成本，自動應對波峰波谷，對於特定領域的開發，它可以極大地釋放開發者的開發運維壓力。過往幾年，我們也見到了一些網際網路大廠在此方面的實踐和輸出，但對傳統企業而言，這還是一個“新鮮事物”。

相較於公有云廠商的一早入局，青雲此時開始做 FaaS 會不會有些晚。對此，於爽表示現階段公開支援 FaaS 主要基於三方面的考慮：一是隨著容器的普及，FaaS 的落地難度逐漸降低，業內已有許多開源框架可供選擇，雖然功能層面還不能完全滿足客戶，但從架構完整性角度來說已經準備就緒；二是客戶對此已提出需求，基於 Java 的框架可能更好招人但整個框架給技術團隊帶來較大負擔，對於中小客戶而言，可快速拼接的業務框架或許是更優的選擇，每個開源框架都有自己的優劣，但在一些私有化環境裡面，客戶需要藉助一個通用性框架實現跨平臺的 FaaS；三是青雲內部的技術儲備已經足夠，併為本次開源準備了半年有餘，主要工作已經完成。

隨著 FaaS 開發框架的加入，KubeSphere 未來也會加入對 Serverless 的支援，整個 FaaS 框架與 KubeSphere 不是強繫結關係，開發者可單獨選用，也可搭配 KubeSphere 使用，KubeSphere 本身也為可以更好支援該框架進行了適配。

人均邁入的雲原生 2.0 是啥？

最近兩年，業界不約而同地進入到雲原生 2.0 時代。幾年前，我們對雲原生的定義更多的是停留在微服務、DevOps、敏捷基礎設施層面，談論更多的雲化通常指資源的池化，主要是計算、網路、儲存三大資源。那麼，雲原生 2.0 階段區別於此的特徵是什麼呢？

採訪中，於爽表示，不同的廠商對於 2.0 有著不同的定義，但大抵是希望對自己或者與競爭對手的技術成熟度進行區分，以便使用者可以感知到差異。在 1.0 階段，很多使用者沒開始或者在容器化的初始階段，很多業務只是單純滿足容器訴求，但還沒有和業務進行深入結合。在 2.0 階段，使用者的關注點從容器化轉移到更低的投入產出比，並開始嘗試相容雲原生基礎設施的技術架構，比如 Service Mesh、FaaS 等，開發人員寫程式碼的方式不變，只是通過雲的方式遮蔽了底層架構的複雜性。

從技術層面來看，CNCF 提供了包含微服務、容器等在內的雲原生最佳實踐。經過企業的實踐，根據【2019-2020 年的雲原生實踐調研報告】顯示 8.2% 的企業用了超過 5000 個容器，大部分參與調研企業使用容器的數量在 500 以下（61.2%），500-1000 個容器的比例為 21.4%，1000-5000 個容器為 9.2%。21.7% 的受訪者中將雲原生技術（包括容器、DevOps、微服務）已用於核心業務生產，30.6% 用於邊緣性業務，20.1% 用於測試階段，16.3% 尚處於評估階段，11.3% 還沒有采用這些前沿的技術。

從數字來看，容器的整體應用率還是偏低的。根據於爽的實際瞭解，很多企業在使用容器的方式上也與技術層面的最佳實踐有偏差，很多企業會將之前執行在虛擬機器上的任務無縫打包到容器，也就是業界常提起的“胖容器”。從業務視角來看，微服務改造可能帶來管理複雜度的成倍增長，這也是很多企業沒有進行大規模微服務改造的原因，但通過容器化可以享受到 K8s 帶來的便利也是沒有問題的。

相較技術層面的最佳實踐而言，越過微服務而先進行容器化對企業來說投入成本更低，但是見效不會很明顯，如果原有業務全部都是容器化的可能在上到 K8s 平臺後效果明顯；如果原有業務偏傳統，為了容器化而容器化，見效甚微，即便後期開始進行微服務改造也是需要投入巨大精力的。

在 1.0 階段之後，“以應用為中心”的概念進入我們的視角。在於爽看來，這可以認為是 1.0 和 2.0 之間的過渡階段，而 2.0 階段的主要特徵是“以業務為中心”，青雲的目標是希望讓原有的業務開發人員直接享受到雲原生的紅利而無需投入過多學習成本。

容器混合雲架構

在 2.0 階段，容器混合雲架構成為絕大多數傳統企業的選擇，這些企業的需求基本一致，那就是兼顧穩態與敏態的業務，以一套統一的雲平臺或雲架構支援多種不同的工作負載，既能確保應用和資料的穩定、可靠和安全，又能夠支援不斷湧現的新應用。

“私有云 + 公有云”可以稱之為狹義的混合雲，而今天更廣義上的混合雲可以理解為是一種混合的環境或架構，它可以將物理的、虛擬化的、容器的、邊緣的、雲化的環境統一納管起來，遮蔽各種不同的底層技術之間連線、協作的複雜性，為上層應用提供統一的、友好的的資源池。

不同的私有云、公有云由於採用了不同的架構、技術，遵循不同的標準和規範，它們之間的連通性、相容性是具有相當大難度的，資料和應用在本地與雲端，甚至雲和雲之間遷移、共享、協作，不得不跨越技術和廠商層面的壁壘，甚至可以說鴻溝。

直到容器的出現，它遮蔽了底層異構環境的複雜性，為上層應用提供了統一的標準和介面，為混合雲提供了機會和空間。

在此之前，人們對混合雲的審視主要是從 IaaS 層面切入的，集中在對裸金屬、虛擬機器等裝置的管理；在此之後，混合雲的架構體系以 K8s 作為標準和基礎，對底層基礎設施的各項能力進行抽象化和標準化。 從容器視角來看，只要映象打包標準統一，使用者可以無縫跨各種雲，不存在廠商繫結風險；從混合雲的視角來看，這種架構會讓跨 Region 容災等更加好操作；從客戶的視角來看，整個技術趨勢以及業務訴求都在推著客戶選擇這種模式。

站在 KubeSphere 的視角，容器混合雲架構是必須要做的一件事情，無論是對專案本身發展還是滿足客戶需求層面，這都是一件值得投入精力的事情。與公有云大廠不同，KubeSphere 作為一個開源容器專案可以平滑執行在不同的底層雲平臺之上，對於容器混合雲架構的實踐具備天然優勢，並在積極參與跨混合雲管理架構的研發，目前，KubeSphere 提供多叢集多雲混合部署並支援跨雲管理及應用分發，其使用者遍佈多個公有云。 “無論未來的架構標準由誰來完成，KubeSphere 都希望參與其中。”

嘉賓介紹：

於爽（Calvin Yu），KubeSphere 容器平臺產品負責人，參與並研發了多款青雲容器相關產品，如 K8s On QingCloud，KubeSphere 等。在加入青雲科技之前供職於 IBM，對中介軟體監控、電子商務等多個領域有深入的研究。

作者

趙鈺瑩 InfoQ

本文由部落格一文多發平臺 OpenWrite 釋出！