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