人均云原生2.0，容器的圈子內(nèi)卷嗎？
兩三年前，云原生勢頭正盛，開始“侵入”各大公司。三年過后，隨著云原生 2.0 時代的到來以及落地實踐進度的加快，業(yè)內(nèi)對云原生又有了很多新的理解，對其可為業(yè)務帶來的實際價值有了更多感觸，容器的圈子也經(jīng)歷了一輪洗禮。在各大公司紛紛表示已經(jīng)邁入云原生 2.0 時代的今天，我們有幸可以和 KubeSphere 容器平臺產(chǎn)品負責人于爽交流下當前云原生領域值得關注的技術趨勢和落地方向。
K8s 項目發(fā)展至今，已成為云計算領域平臺層當仁不讓的事實標準，但其復雜性、學習曲線陡峭也是不爭的事實。于是，我們在過去三年看到了一眾基于 K8s 衍生出的項目，試圖降低用戶部署 K8s 的難度，并且隨著開源運動的興起，這些項目大都選擇了開源的方式運營。類似的項目，相同的運營方式，競爭在所難免，難道容器的圈子開始內(nèi)卷了嗎？
“兩三年前，確實有用戶會找來一堆與 KubeSphere 類似的開源項目讓我們提供比較結(jié)果，甚至有些開源項目，我們都沒見過。”
如今，CNCF 基金會的云原生全景圖已經(jīng)相當龐大，涵蓋基礎設施層、運行時層、編排和管理層、應用定義和開發(fā)層以及貫穿所有層的平臺解決方案、可觀察性和分析工具，并且經(jīng)過這三年的發(fā)展，很多項目已經(jīng)從初級版本走向成熟，擁有穩(wěn)定的擁護者和使用者。
“三年前，用戶可能需要不少的時間抉擇自己需要的項目，如今從開源社區(qū)的角度來看，圍繞著容器平臺的項目基本穩(wěn)定，也有一些項目在這三年走向淘汰，用戶結(jié)合具體的業(yè)務場景很容易就可以做好選型。”
從這個角度看，容器的圈子并沒有在過去三年逐步內(nèi)卷，反而越來越清晰，留下來的項目都有了各自的棲身之地，淘汰的項目原因各不相同，而開源不易是其中很重要的一項影響因素。
項目地址：
https://github.com/kubesphere/kubesphere
“開源這件事情，我們起初也走了一些彎路。”
從表面上看起來，一家商業(yè)公司運營一個開源項目似乎很簡單：將代碼放到 GitHub 上或者將項目捐獻給某一個基金會，然后建立社區(qū)把有相同想法的人聚攏在一起，接下來就是用戶群體不斷壯大，項目不斷更新迭代，最后成功畢業(yè)或者走向成熟，這套流程看起來非常水到渠成，但具體到執(zhí)行層面，有很多問題需要考慮：一個全新的開源項目怎么讓開發(fā)者信任并參與？如何運營開源社區(qū)是有效的模式？哪些功能應該貢獻給社區(qū)？
開源社區(qū)通常不是由一個人控制的，基于商業(yè)公司運營的開源項目情況更加復雜。有時候，同一個功能，社區(qū)的實現(xiàn)思路和公司不一樣；有時候，公司規(guī)劃了一個商業(yè)功能，社區(qū)提前做出來了......
在 KubeSphere 開源之初，整個團隊想的是把代碼寫好就可以了，后來的運營過程中發(fā)現(xiàn)這種想法是有問題的，如果開源之初沒有想好目標，只是為了開源而開源，就會導致后面的很多工作無法正常開展，把代碼提交到 GitHub 并不代表開源目標就完成了，如果沒有種子開發(fā)者的信任和推廣，很難真正做起來，但怎么讓種子開發(fā)者信任呢？
“我們前期和很多開源領域的資深專家做過溝通。事實上，種子用戶們對開源項目的接受度非常高，對新的開源項目容忍度也非常高，但這一切的前提是你的代碼和開源文檔都足夠完善，只要他可以按照你的文檔和代碼解決實際問題，就會對項目產(chǎn)生信任，從而自發(fā)向外推薦。”
雖然種子用戶的容忍度很高，但這批人的技術水平也非常高，亂搞肯定是不行的，于爽補充道，一個完備的開源項目應該擁有完善的開發(fā)文檔、清晰的技術架構(gòu)圖，并且有一個清晰的路線圖，愿意傾聽種子用戶的建議。如果種子用戶都沒了，轉(zhuǎn)而去孵化后面的小白用戶，整個鏈條就斷掉了，肯定是做不好的。
過去幾年，我們也看到了一些項目的沒落，大多是團隊沒有意識到開源的價值，沒有真正弄懂開源，進而導致項目的發(fā)展呈現(xiàn)負向循環(huán)，越做越沮喪，甚至成為整個團隊的累贅。
如今，KubeSphere 3.1.0 版本已正式發(fā)布，該版本包含了來自 KubeSphere 社區(qū)及企業(yè)用戶發(fā)現(xiàn)的 bug 及提出 的需求，涉及到 KubeSphere 前后端各個組件；全球近 100 位貢獻者參與 3.1.0 的開發(fā)、測試工作，有個人愛 好者，也有大量的企業(yè)用戶、開源項目參與貢獻，如中通、銳捷、馬上消費金融、紅亞科技、Kube-OVN 等；主倉庫 160 多個 PR 提交。在 3.1.0 版本 之后，KubeSphere 小版本的發(fā)布頻率會更頻繁。
“回頭想想，做開源項目就好像在下棋，然后旁邊有很多人在指導你，你不單單是在做一個項目，也是在交朋友、做圈子。如果你是純做商業(yè)產(chǎn)品，圈子就會非常垂直，集中在和商業(yè)閉環(huán)這個圈里的人打交道。”
除了技術的文檔層面準備就緒，青云自上而下對開源的認知也讓 KubeSphere 從誕生之初就決定走全球化的路線，而不是閉門造車，為此開通了海外溝通方式，并提供了大量英文素材，希望全球開發(fā)者都可以加入到其中平等溝通，并設置了專門的運營團隊負責對接全球開發(fā)者提的問題，管理開發(fā)者關系，為開源社區(qū)輸送對應的文檔和資料。
“其實，國內(nèi)很多做開源的人都是既寫代碼又做社區(qū)運營，也不乏有做的好的，但寫代碼的人所希望聚焦的問題未必是和運營相同，所以我們設立了專門的團隊來做運營，希望開發(fā)者在社區(qū)中的體驗更好，希望對用戶反饋問題的響應更加及時。”
基于上述認知，KubeSphere 得以在容器圈擁有一席之地，并于近日新增了 FaaS（函數(shù)計算）支持。事實上，F(xiàn)aaS 在云原生的圈子里也不是什么新鮮概念，這代表著一種計算模式，可以極致優(yōu)化資源成本，自動應對波峰波谷，對于特定領域的開發(fā)，它可以極大地釋放開發(fā)者的開發(fā)運維壓力。過往幾年，我們也見到了一些互聯(lián)網(wǎng)大廠在此方面的實踐和輸出，但對傳統(tǒng)企業(yè)而言，這還是一個“新鮮事物”。
相較于公有云廠商的一早入局，青云此時開始做 FaaS 會不會有些晚。對此，于爽表示現(xiàn)階段公開支持 FaaS 主要基于三方面的考慮：一是隨著容器的普及，F(xiàn)aaS 的落地難度逐漸降低，業(yè)內(nèi)已有許多開源框架可供選擇，雖然功能層面還不能完全滿足客戶，但從架構(gòu)完整性角度來說已經(jīng)準備就緒；二是客戶對此已提出需求，基于 Java 的框架可能更好招人但整個框架給技術團隊帶來較大負擔，對于中小客戶而言，可快速拼接的業(yè)務框架或許是更優(yōu)的選擇，每個開源框架都有自己的優(yōu)劣，但在一些私有化環(huán)境里面，客戶需要借助一個通用性框架實現(xiàn)跨平臺的 FaaS；三是青云內(nèi)部的技術儲備已經(jīng)足夠，并為本次開源準備了半年有余，主要工作已經(jīng)完成。
隨著 FaaS 開發(fā)框架的加入，KubeSphere 未來也會加入對 Serverless 的支持，整個 FaaS 框架與 KubeSphere 不是強綁定關系，開發(fā)者可單獨選用，也可搭配 KubeSphere 使用，KubeSphere 本身也為可以更好支持該框架進行了適配。
最近兩年，業(yè)界不約而同地進入到云原生 2.0 時代。幾年前，我們對云原生的定義更多的是停留在微服務、DevOps、敏捷基礎設施層面，談論更多的云化通常指資源的池化，主要是計算、網(wǎng)絡、存儲三大資源。那么，云原生 2.0 階段區(qū)別于此的特征是什么呢？
采訪中，于爽表示，不同的廠商對于 2.0 有著不同的定義，但大抵是希望對自己或者與競爭對手的技術成熟度進行區(qū)分，以便用戶可以感知到差異。在 1.0 階段，很多用戶沒開始或者在容器化的初始階段，很多業(yè)務只是單純滿足容器訴求，但還沒有和業(yè)務進行深入結(jié)合。在 2.0 階段，用戶的關注點從容器化轉(zhuǎn)移到更低的投入產(chǎn)出比，并開始嘗試兼容云原生基礎設施的技術架構(gòu)，比如 Service Mesh、FaaS 等，開發(fā)人員寫代碼的方式不變，只是通過云的方式屏蔽了底層架構(gòu)的復雜性。
從技術層面來看，CNCF 提供了包含微服務、容器等在內(nèi)的云原生最佳實踐。經(jīng)過企業(yè)的實踐，根據(jù)【2019-2020 年的云原生實踐調(diào)研報告】顯示 8.2% 的企業(yè)用了超過 5000 個容器，大部分參與調(diào)研企業(yè)使用容器的數(shù)量在 500 以下（61.2%），500-1000 個容器的比例為 21.4%，1000-5000 個容器為 9.2%。21.7% 的受訪者中將云原生技術（包括容器、DevOps、微服務）已用于核心業(yè)務生產(chǎn)，30.6% 用于邊緣性業(yè)務，20.1% 用于測試階段，16.3% 尚處于評估階段，11.3% 還沒有采用這些前沿的技術。
從數(shù)字來看，容器的整體應用率還是偏低的。根據(jù)于爽的實際了解，很多企業(yè)在使用容器的方式上也與技術層面的最佳實踐有偏差，很多企業(yè)會將之前運行在虛擬機上的任務無縫打包到容器，也就是業(yè)界常提起的“胖容器”。從業(yè)務視角來看，微服務改造可能帶來管理復雜度的成倍增長，這也是很多企業(yè)沒有進行大規(guī)模微服務改造的原因，但通過容器化可以享受到 K8s 帶來的便利也是沒有問題的。
相較技術層面的最佳實踐而言，越過微服務而先進行容器化對企業(yè)來說投入成本更低，但是見效不會很明顯，如果原有業(yè)務全部都是容器化的可能在上到 K8s 平臺后效果明顯；如果原有業(yè)務偏傳統(tǒng)，為了容器化而容器化，見效甚微，即便后期開始進行微服務改造也是需要投入巨大精力的。
在 1.0 階段之后，“以應用為中心”的概念進入我們的視角。在于爽看來，這可以認為是 1.0 和 2.0 之間的過渡階段，而 2.0 階段的主要特征是“以業(yè)務為中心”，青云的目標是希望讓原有的業(yè)務開發(fā)人員直接享受到云原生的紅利而無需投入過多學習成本。
在 2.0 階段，容器混合云架構(gòu)成為絕大多數(shù)傳統(tǒng)企業(yè)的選擇，這些企業(yè)的需求基本一致，那就是兼顧穩(wěn)態(tài)與敏態(tài)的業(yè)務，以一套統(tǒng)一的云平臺或云架構(gòu)支持多種不同的工作負載，既能確保應用和數(shù)據(jù)的穩(wěn)定、可靠和安全，又能夠支持不斷涌現(xiàn)的新應用。
“私有云 + 公有云”可以稱之為狹義的混合云，而今天更廣義上的混合云可以理解為是一種混合的環(huán)境或架構(gòu)，它可以將物理的、虛擬化的、容器的、邊緣的、云化的環(huán)境統(tǒng)一納管起來，屏蔽各種不同的底層技術之間連接、協(xié)作的復雜性，為上層應用提供統(tǒng)一的、友好的的資源池。
不同的私有云、公有云由于采用了不同的架構(gòu)、技術，遵循不同的標準和規(guī)范，它們之間的連通性、兼容性是具有相當大難度的，數(shù)據(jù)和應用在本地與云端，甚至云和云之間遷移、共享、協(xié)作，不得不跨越技術和廠商層面的壁壘，甚至可以說鴻溝。
直到容器的出現(xiàn)，它屏蔽了底層異構(gòu)環(huán)境的復雜性，為上層應用提供了統(tǒng)一的標準和接口，為混合云提供了機會和空間。
在此之前，人們對混合云的審視主要是從 IaaS 層面切入的，集中在對裸金屬、虛擬機等設備的管理；在此之后，混合云的架構(gòu)體系以 K8s 作為標準和基礎，對底層基礎設施的各項能力進行抽象化和標準化。
從容器視角來看，只要鏡像打包標準統(tǒng)一，用戶可以無縫跨各種云，不存在廠商綁定風險；從混合云的視角來看，這種架構(gòu)會讓跨 Region 容災等更加好操作；從客戶的視角來看，整個技術趨勢以及業(yè)務訴求都在推著客戶選擇這種模式。
站在 KubeSphere 的視角，容器混合云架構(gòu)是必須要做的一件事情，無論是對項目本身發(fā)展還是滿足客戶需求層面，這都是一件值得投入精力的事情。與公有云大廠不同，KubeSphere 作為一個開源容器項目可以平滑運行在不同的底層云平臺之上，對于容器混合云架構(gòu)的實踐具備天然優(yōu)勢，并在積極參與跨混合云管理架構(gòu)的研發(fā)，目前，KubeSphere 提供多集群多云混合部署并支持跨云管理及應用分發(fā)，其用戶遍布多個公有云。
“無論未來的架構(gòu)標準由誰來完成，KubeSphere 都希望參與其中。”
本文來自微信公眾號 “InfoQ”（ID：infoqchina），作者：趙鈺瑩，36氪經(jīng)授權(quán)發(fā)布。
