2020 年注定是不凡的。它在陰霾中開始，在驚嘆中結(jié)束，也讓未來變得更加撲朔迷離。那么，容器與云原生的 2020 年呢？你是否記得它是怎樣開始的？它又將走向何方？

1. Kubernetes：企業(yè)基礎(chǔ)設(shè)施的標(biāo)準(zhǔn)抽象

在 2020 年，沒有人再會(huì)去質(zhì)疑一個(gè)平臺(tái)團(tuán)隊(duì)采納 Kubernetes 作為自己的基礎(chǔ)設(shè)施的合理性。事實(shí)上，2020 年的 Kubernetes 項(xiàng)目已經(jīng)非常接近于的完成了它最重要的使命，即：為云計(jì)算基礎(chǔ)設(shè)施帶來一層可以讓平臺(tái)團(tuán)隊(duì)基于此構(gòu)造“一切”的平臺(tái)層抽象。

我們已經(jīng)能夠看到， 今天的云原生社區(qū)已經(jīng)開始廣泛認(rèn)可 Kubernetes 項(xiàng)目作為“The platform for platform”的定位與價(jià)值，越來越多的平臺(tái)團(tuán)隊(duì)正在基于 Kubernetes 構(gòu)建各種各樣的上層平臺(tái)，PaaS，Serverless，AI Platform ，Database PaaS 等等。面向終態(tài)的聲明式 API 與其背后“辛勤”工作的控制器，為“構(gòu)建基礎(chǔ)設(shè)施層抽象”這個(gè)充滿了挑戰(zhàn)的技術(shù)難題，提供了一個(gè)能夠在復(fù)雜度與可用性之間取得平衡的解決方案。正是基于此，Kubernetes 項(xiàng)目才擁有了龐大的集成生態(tài)，讓這個(gè)“企業(yè)基礎(chǔ)設(shè)施的標(biāo)準(zhǔn)抽象”，逐步成為了業(yè)界公認(rèn)的事實(shí)。

而更為重要的是，Kubernetes 真正的成功之處，在于它真正押注的是構(gòu)建抽象的方法而非這些抽象本身。在絕大多數(shù)情況下，企業(yè)基于 Kubernetes 構(gòu)建上層平臺(tái)，都會(huì)引入各種各樣其他的抽象作為補(bǔ)充，甚至取代或者隱藏掉 Kubernetes 的部分內(nèi)置抽象：阿里巴巴開源的 CloneSet，騰訊的 GameStatefulSet 實(shí)踐等擴(kuò)展型工作負(fù)載等都是這個(gè)趨勢的最好的案例。

伴隨著 Kubernetes 生態(tài)從底層到應(yīng)用層能力的逐步完善，在 2020 年，更多大型互聯(lián)網(wǎng)終端企業(yè)開始加入到了云原生的梯隊(duì)當(dāng)中。我們看到原本的 Mesos 生態(tài)標(biāo)桿 Apple 公司成為了 KubeCon 2020 北美上的絕對(duì)主角，而金融巨頭 MasterCard 則分享了他們基于 OAM、Kubernetes 和 Crossplane 項(xiàng)目構(gòu)建跨云、跨運(yùn)行時(shí)應(yīng)用交付平臺(tái)的內(nèi)部落地案例。而尤為值得一提的是，這些以往在底層基礎(chǔ)技術(shù)上給人以”保守“印象的大型非云企業(yè)，在 2020 年紛紛祭出了對(duì)很多新興技術(shù)比如 Virtual Cluster 和標(biāo)準(zhǔn)應(yīng)用模型技術(shù)上的落地與思考。云原生浪潮對(duì)整個(gè)技術(shù)產(chǎn)業(yè)帶來的深遠(yuǎn)影響可見一斑。

此外，我們也不難觀察到，Kubernetes 的極大普及以及基于它興起的上層生態(tài)，正在跟安卓（Android）的發(fā)展路徑越來越明顯的趨同。安卓能夠?qū)ο乱砸惶捉y(tǒng)一的方式抽象與集成不同的手機(jī)、電視、甚至汽車等硬件設(shè)備，對(duì)上則為程序員暴露出統(tǒng)一的一套開發(fā)接口，使他們能夠以這套統(tǒng)一的抽象去訪問或者享受到這些基礎(chǔ)設(shè)施能力。這種定位與 Kubernetes 非常類似，這里唯一的區(qū)別在于，安卓服務(wù)的程序員是 APP 開發(fā)者，而 Kubernetes 服務(wù)的“程序員”，則是平臺(tái)構(gòu)建者。在這個(gè)背景下，諸如“Kubernetes 拋棄 Docker”之類的新聞會(huì)很容易理解：安卓本身，本就不需要專注于手機(jī)的電池是哪個(gè)牌子的。

這個(gè)路徑，可能也是 Google 比較擅長的一個(gè)“打法”：全力地去免費(fèi)推廣一個(gè)“操作系統(tǒng)”，真正獲取商業(yè)價(jià)值的方式則是是去“收割”操作系統(tǒng)上層的生態(tài)價(jià)值而不是操作系統(tǒng)本身。畢竟用戶是不會(huì)花錢去購買安卓的。所以 Google Cloud 目前正在 All-in 的，正是通過 Anthos 這樣的 Kubernetes 混合云底座，將 Google Cloud 服務(wù)交付到在全世界任何一個(gè)數(shù)據(jù)中心上去。

2. 正在被打破的云計(jì)算“三層架構(gòu)”

長久以來，業(yè)界對(duì)云計(jì)算的認(rèn)知，一直圍繞著”SaaS + PaaS + IaaS“這樣經(jīng)典的三層架構(gòu)模型展開。然而，在 2020 年，隨著云原生技術(shù)的極大普及，我們卻發(fā)現(xiàn)這個(gè)模型似乎正遭受著挑戰(zhàn)。

今天的云原生技術(shù)，起源于 Docker 以及容器這個(gè)創(chuàng)新性的技術(shù)革命，又受益于經(jīng)典 PaaS （比如 Cloud Foundry）持續(xù)已久的心智普及，最終在開發(fā)者與平臺(tái)構(gòu)建者的雙重關(guān)注下，以 Kubernetes 生態(tài)為載體最終落地。

在 2020 年，伴隨著云原生技術(shù)逐步成熟，面向用戶的應(yīng)用管理平臺(tái)的形態(tài)也逐漸開始從以 Cloud Foundry/Heroku 為主體的經(jīng)典 PaaS 形態(tài)（即：企業(yè)級(jí) PaaS），向輕量級(jí)的 App Service 比如 Shipa 和 Kalm 等方向靠攏。不過，輕量級(jí) App Service 本質(zhì)上還是 Heroku 體驗(yàn)在 Kubernetes 底座上的復(fù)刻，它們?cè)谔峁┏錾拈_發(fā)者使用體驗(yàn)的同時(shí)，也繼承了經(jīng)典 PaaS 的“封閉”與“不可擴(kuò)展”，這在很多大型企業(yè)基于云原生技術(shù)棧 “DIY” 屬于自己的“PaaS”的訴求下，依然會(huì)顯得力不從心。

事實(shí)上，對(duì)于越來越多的平臺(tái)構(gòu)建者來說，隨著云原生技術(shù)的日趨落地，“PaaS”本身的“解釋權(quán)”不再屬于某一家提供商，而更多取決于平臺(tái)構(gòu)建者的業(yè)務(wù)場景和其終端用戶的實(shí)際需求。此外，對(duì)于 “SaaS”來說，云原生帶來的容器化軟件打包與交付體系和 Kubernetes 底座，也已經(jīng)極大的改變了云端軟件的分發(fā)與運(yùn)維方式。所以，無論是 PaaS 也好，SaaS 也好，本質(zhì)上正在被“云原生”的技術(shù)浪潮迅速“壓平”，在這種背景下，傳統(tǒng)“水平”劃分云計(jì)算體系的方法其實(shí)已經(jīng)變得難以自洽。一個(gè)典型的例子就是今天你既不能把 Kubernetes 稱作是 PaaS，也不能把它稱作是 IaaS。它是一個(gè)獨(dú)特的基礎(chǔ)設(shè)施能力接入層與平臺(tái)層抽象，作為平臺(tái)構(gòu)建者，你可以基于它構(gòu)建你心目中任何上層平臺(tái)，而至于你把這個(gè)上層平臺(tái)稱作是 PaaS，Serverless，F(xiàn)aaS，甚至是 SaaS，只是進(jìn)一步抽象的程度和依賴的垂直能力不同而已：這里并沒有”誰蓋在誰頭上”這樣的劃分。

3. 下一代云原生平臺(tái)構(gòu)建體系的崛起

Kubernetes 的成功，極大的使能了“平臺(tái)構(gòu)建者”這個(gè)以往被人們遺忘在企業(yè)成本中心（Cost Center） 里的重要角色。事實(shí)上，Kubernetes 之所以能夠取代 Docker 生態(tài)成為今天云計(jì)算平臺(tái)上的主角，很大程度上是這個(gè)群體做出了最終的決定。否則，按照 Docker 所觸達(dá)到的用戶群體規(guī)模以及其在開發(fā)者生態(tài)中的被接納度， Kubernetes 幾乎毫無勝算。這一點(diǎn)經(jīng)常是被大家所忽視的。實(shí)際上，在企業(yè)級(jí)平臺(tái)落地的過程中，平臺(tái)的最終用戶（比如業(yè)務(wù)研發(fā)與運(yùn)維）雖然是“顧客與上帝”，但真正能在這個(gè)過程中能起到關(guān)鍵作用和具有最終決定權(quán)的，往往還是業(yè)務(wù)背后的平臺(tái)團(tuán)隊(duì)和老板們。

但與此同時(shí)，Kubernetes 之上的平臺(tái)構(gòu)建生態(tài)，在今天依然是高度集中的。一個(gè)典型的觀察就是，今天能夠基于 Kubernetes 成體系構(gòu)建出完整上層平臺(tái)的團(tuán)隊(duì)，其實(shí)集中在一、二線大型互聯(lián)網(wǎng)公司當(dāng)中，并且其實(shí)踐往往“僅供參考”，鮮有可復(fù)制性。進(jìn)一步的，云原生的極大普及，似乎并沒有真正能夠讓平臺(tái)構(gòu)建者輕松的構(gòu)建 PaaS 或者其他上層平臺(tái)。這，其實(shí)也進(jìn)一步解釋了前面我們觀察到的“PaaS 生態(tài)“在云原生時(shí)代的停滯：基于 Kubernetes 構(gòu)建上層平臺(tái)（包括 PaaS），在 2020 年依然是大型公司和高技術(shù)水位團(tuán)隊(duì)們的專利。

這種平臺(tái)構(gòu)建這生態(tài)的高度集中，與云原生希望構(gòu)建的“普惠式”未來，顯然是不相符的。當(dāng)然，既然技術(shù)發(fā)展還沒有跟上愿景，那么云原生社區(qū)也就不會(huì)停下腳步。

事實(shí)上，平臺(tái)構(gòu)建者之所以要基于 Kubernetes 進(jìn)一步構(gòu)建上層平臺(tái)，其根本動(dòng)機(jī)無非來自兩個(gè)訴求：

• 更高的抽象維度：比如，用戶希望操作的概念是“應(yīng)用”和“灰度發(fā)布”，而不是“容器”和“Pod”；
• 更多的擴(kuò)展能力：比如，用戶希望的應(yīng)用灰度發(fā)布策略是基于“雙 Deployment + Istio” 的金絲雀發(fā)布，而不是 Kubernetes 默認(rèn)的 Pod 線性滾動(dòng)升級(jí)。這些增強(qiáng)或者擴(kuò)展能力，在 Kubernetes 中一般是以 CRD + Controller 的插件方式來實(shí)現(xiàn)的。

所以說，基于 Kubernetes 構(gòu)建上層平臺(tái)在今天看起來似乎雜亂無章、沒什么規(guī)律，但本質(zhì)上都不會(huì)離開“抽象 + 插件能力管理”這兩個(gè)核心訴求。再舉個(gè)例子，今天大家為 Kubernetes 構(gòu)建的各種 Dashboard，其實(shí)就是一種“抽象”的實(shí)現(xiàn)方式：這些 Dashboard 本質(zhì)上是在 Kubernetes API 對(duì)象的基礎(chǔ)上暴露出了一組允許用戶填寫的字段，從而實(shí)現(xiàn)了‘’簡化用戶使用心智、提升用戶體驗(yàn)‘’的目的 —— 這當(dāng)然也是所有“抽象”的根本目標(biāo)。

基于對(duì)“抽象 + 插件能力管理”這兩個(gè)訴求的持續(xù)實(shí)踐與思考，云原生社區(qū)在 2020 年誕生了像 KubeVela 這樣專注于使能平臺(tái)團(tuán)隊(duì)構(gòu)建上層平臺(tái)的開源項(xiàng)目。這個(gè)項(xiàng)目的定位在整個(gè)云原生生態(tài)中是非常獨(dú)特的：它并不是某種垂直能力，它更像是一套基于 Kubernetes 構(gòu)建上層平臺(tái)的“工具”組合，比如：

• 基于模板的抽象機(jī)制，以及基于此生成能力使用文檔和 OpenAPI Schema 的自動(dòng)化流程（從而幫助平臺(tái)團(tuán)隊(duì)快速構(gòu)建 Dashboard 或者 Appfile）；
• 基于 OAM 模型的插件式能力注冊(cè)、管理與發(fā)現(xiàn)機(jī)制，以此來模塊化、自動(dòng)化的管理插件能力，甚至提前預(yù)警插件能力之間的沖突等。

無獨(dú)有偶，在阿里云開源 KubeVela 項(xiàng)目后不久，云計(jì)算領(lǐng)頭羊 AWS 在 Re:Invent 2020 上也高調(diào)宣布了 AWS Proton 商業(yè)產(chǎn)品的正式誕生，其思想同 KubeVela 項(xiàng)目非常類似，只不過構(gòu)建平臺(tái)的底座換成了 AWS 云平臺(tái)，定義抽象的模板使用了 AWS 自己的 Cloud Formation (KubeVela 目前支持的是 Google 開源的 CUELang 模板語言）。

可以預(yù)見，在云原生與 Kubernetes 項(xiàng)目極大程度的統(tǒng)一與標(biāo)準(zhǔn)化了基礎(chǔ)設(shè)施層抽象之后，如何進(jìn)一步幫助平臺(tái)團(tuán)隊(duì)在此之上快速、輕松、可復(fù)制的構(gòu)建上層平臺(tái)，正在成為業(yè)界開始積極思考的一條關(guān)鍵路徑。再一次的，你很難在傳統(tǒng)的云計(jì)算“三層架構(gòu)”中找到適合這些產(chǎn)品的位置，無論是 KubeVela 還是 AWS Proton，它們既不是 PaaS，也不是 IaaS，更不是 Kubernetes 的競爭者：它們是云原生背景下新一代平臺(tái)構(gòu)建體系逐步崛起的萌芽。

4. 探索云原生的下一站

2020 年的云原生可以說是整個(gè)云計(jì)算生態(tài)中發(fā)展最迅速的一條主線脈絡(luò)，而也正是伴隨著這樣的發(fā)展勁頭，云原生在新的一年里，已經(jīng)要開始思考它的下一步發(fā)展空間。事實(shí)上，我們已經(jīng)能夠看到各種各樣的廠商和團(tuán)隊(duì)在不同的領(lǐng)域積極發(fā)力和探索。

本地開發(fā)與測試

使能開發(fā)者面向 Kubernetes 進(jìn)行本地開發(fā)和測試正在開始成為一個(gè)備受關(guān)注的話題，在這個(gè)領(lǐng)域中，來自紐約的 Tilt 項(xiàng)目是其中的佼佼者。阿里云和騰訊云有也分別有這個(gè)話題下的不同維度的解決方案，比如 KT Connet 和 Nocalhost。

云原生“中間件”的技術(shù)變革

Sidecar 模式正在以更加迅猛的勢頭的將中間件領(lǐng)域的能力下沉至 Kubernetes 這個(gè)新一代的應(yīng)用基礎(chǔ)設(shè)施當(dāng)中，除了已經(jīng)如火如荼的 Istio 對(duì)流量治理領(lǐng)域的顛覆，微軟已經(jīng)不甘示弱的開源了 Open Service Mesh 作為回應(yīng)。而與此同時(shí)， OAM 在微軟的姊妹項(xiàng)目 Dapr 則直接拉齊了 Kubernetes 與中間件在“服務(wù)發(fā)現(xiàn)與綁定”側(cè)的距離，老牌項(xiàng)目 Dubbo 亦宣布了下一代云原生中間件的技術(shù)藍(lán)圖。當(dāng)然， 所有這一切背后的用戶動(dòng)機(jī)是非常清晰的：云原生時(shí)代的中間件，要語言無關(guān)，要平臺(tái)無關(guān)。

“邊緣”與 Kubernetes 發(fā)行版

Kubernetes 的“安卓化”趨勢，少不了將 Kubernetes 部署到全世界任何一個(gè)數(shù)據(jù)中心去的“雄心壯志”，這里當(dāng)然也包括“邊緣”設(shè)備。除了華為的拳頭產(chǎn)品 KubeEdge 之外，阿里云的 OpenYurt 項(xiàng)目在 2020 年也進(jìn)入了 CNCF 沙箱孵化，而騰訊云則提出了 SuperEdge 緊隨其后。與此同時(shí)，AWS 在 2020 年重磅開源了其 EKS 服務(wù)背后的 Kubernetes 發(fā)行版 EKS-D，這里當(dāng)然隱含了對(duì) Google Cloud 的 Anthos 和微軟云的 Arc 布局的強(qiáng)勢回應(yīng)?？梢灶A(yù)見，云廠商們對(duì)“將 Kubernetes 部署到任何一個(gè)角落”的這份執(zhí)著，會(huì)讓 Kubernetes “安卓化”比想象中來得更快，也少不了在 ISV 和服務(wù)集成商側(cè)的一番“腥風(fēng)血雨”。

云原生應(yīng)用管理與 GitOps

云原生應(yīng)用管理與交付，已然正在成為 Kubernetes 這個(gè)“新安卓”之上重要的價(jià)值聚焦點(diǎn)。在這個(gè)領(lǐng)域，阿里云聯(lián)合微軟的 OAM + OpenKruise 組合已經(jīng)嶄露頭角，與此同時(shí)，社區(qū)上也出現(xiàn)了 KubeVela 這樣進(jìn)一步使能平臺(tái)構(gòu)建者的開源框架，開發(fā)者工具領(lǐng)域的佼佼者 Hashicorp 更是不失時(shí)機(jī)的發(fā)布了 Waypoint 這樣的跨平臺(tái)開發(fā)者界面工具。而伴隨著 Kubernetes 之上的應(yīng)用層技術(shù)快速演進(jìn)的同時(shí)，基于 Git 作為應(yīng)用配置管理中心交付應(yīng)用的理念（即：GitOps），則正在迅速取代傳統(tǒng) CI/CD 中的 CD 環(huán)節(jié)，成為 Kubernetes 上應(yīng)用分發(fā)的不二之選。在 2020 年末，CNCF 應(yīng)用交付領(lǐng)域小組正式宣布了 GitOps Working Group 的組建，很有可能會(huì)將 GitOps 逐步推向云原生 CD 的事實(shí)標(biāo)準(zhǔn)。在 Kubernetes “安卓化”勢不可擋的今天，我們對(duì)這個(gè)領(lǐng)域在新的一年即將出現(xiàn)的更多顛覆與創(chuàng)新充滿期待。

5. 2020 年：沒有“確切定義”的云原生

“云原生”到底是什么？它就是容器和 Kubernetes 嗎？虛擬機(jī)是云原生的嗎？……

這些“靈魂拷問”，一直是很多初次接觸云原生理念的公司和團(tuán)隊(duì)常常提出的困惑。實(shí)際上，作為一套“以利用云計(jì)算技術(shù)為用戶降本增效”的最佳實(shí)踐與方法論，云原生這個(gè)術(shù)語自誕生，到壯大，到今天的極大普及，都處于一個(gè)不斷的自我演進(jìn)與革新的過程當(dāng)中。這種“永遠(yuǎn)沒有確切定義”的持續(xù)生命力，才是“云原生”之所以對(duì)云計(jì)算生態(tài)充滿吸引力的源泉。

在 2020 年，整個(gè)云原生社區(qū)在不同領(lǐng)域的積極探索與嘗試，正在取代 Kubernetes、Service Mesh 等已經(jīng)成熟的實(shí)現(xiàn)項(xiàng)目，逐步成為云原生生態(tài)獨(dú)一無二的主旋律。這其實(shí)不難理解，云原生發(fā)展到今天，正在離它所暢想的“軟件天然生在云上、長在云上”越來越近，但也暴露出了現(xiàn)有的云原生技術(shù)底盤過分關(guān)注于基礎(chǔ)設(shè)施抽象與管理、忽視了最終用戶側(cè)的體驗(yàn)和技術(shù)帶來的諸多問題。這些問題，需要依靠整個(gè)云原生社區(qū)不停歇的思考、沉淀與再創(chuàng)新進(jìn)行補(bǔ)充和修正，才能讓云原生的技術(shù)價(jià)值逐步“上浮”，對(duì)最終用戶產(chǎn)生直接的價(jià)值與體感；也才能讓云原生技術(shù)逐步“民主化”，讓構(gòu)建簡單、易用的云原生平臺(tái)不再成為大公司們“秀肌肉”的專屬。