解讀容器的 2020：尋找雲原生的下一站

做者 | 張磊
來源|阿里巴巴雲原生公衆號

2020 年註定是不凡的。它在陰霾中開始，在驚歎中結束，也讓將來變得更加撲朔迷離。那麼，容器與雲原生的 2020 年呢？你是否記得它是怎樣開始的？它又將走向何方？

Kubernetes：企業基礎設施的標準抽象

在 2020 年，沒有人再會去質疑一個平臺團隊採納 Kubernetes 做爲本身的基礎設施的合理性。事實上，2020 年的 Kubernetes 項目已經很是接近於地完成了它最重要的使命，即：爲雲計算基礎設施帶來一層可讓平臺團隊基於此構造「一切」的平臺層抽象。

咱們已經可以看到，今天的雲原生社區已經開始普遍承認 Kubernetes 項目做爲「The platform for platform」的定位與價值，愈來愈多的平臺團隊正在基於 Kubernetes 構建各類各樣的上層平臺，好比 PaaS / Serverless / AI Platform  / Database PaaS 等等。面向終態的聲明式 API 與其背後「辛勤」工做的控制器，爲「構建基礎設施層抽象」這個充滿了挑戰的技術難題，提供了一個可以在複雜度與可用性之間取得平衡的解決方案。正是基於此，Kubernetes 項目才擁有了龐大的集成生態，讓這個「企業基礎設施的標準抽象」，逐步成爲了業界公認的事實。

而更爲重要的是，Kubernetes 真正的成功之處，在於它真正押注的是構建抽象的方法而非這些抽象自己。在絕大多數狀況下，企業基於 Kubernetes 構建上層平臺，都會引入各類各樣其餘的抽象做爲補充，甚至取代或者隱藏掉 Kubernetes 的部份內置抽象：阿里巴巴開源的 CloneSet、騰訊的 GameStatefulSet 實踐等擴展型工做負載等都是這個趨勢的最好的案例。

伴隨着 Kubernetes 生態從底層到應用層能力的逐步完善，在 2020 年，更多大型互聯網終端企業開始加入到了雲原生的梯隊當中。咱們看到本來的 Mesos 生態標杆 Apple 公司成爲了 KubeCon 2020 北美上的絕對主角，而金融巨頭 MasterCard 則分享了他們基於 OAM、Kubernetes 和 Crossplane 項目構建跨雲、跨運行時應用交付平臺的內部落地案例。而尤其值得一提的是，這些以往在底層基礎技術上給人以」保守「印象的大型非雲企業，在 2020 年紛紛祭出了對不少新興技術好比 Virtual Cluster 和標準應用模型技術上的落地與思考。雲原生浪潮對整個技術產業帶來的深遠影響可見一斑。

此外，咱們也不難觀察到，Kubernetes 的極大普及以及基於它興起的上層生態，正在跟安卓（Android）的發展路徑愈來愈明顯的趨同。安卓可以對下以一套統一的方式抽象與集成不一樣的手機、電視、甚至汽車等硬件設備，對上則爲程序員暴露出統一的一套開發接口，使他們可以以這套統一的抽象去訪問或者享受到這些基礎設施能力。這種定位與 Kubernetes 很是相似，這裏惟一的區別在於，安卓服務的程序員是 APP 開發者，而 Kubernetes 服務的「程序員」，則是平臺構建者。在這個背景下，諸如「Kubernetes 拋棄 Docker」之類的新聞會很容易理解：安卓自己就不須要專一於手機的電池是哪一個牌子的。

這個路徑，可能也是 Google 比較擅長的一個「打法」：全力地去免費推廣一個「操做系統」，真正獲取商業價值的方式則是是去「收割」操做系統上層的生態價值，而不是操做系統自己。畢竟用戶是不會花錢去購買安卓的。因此 Google Cloud 目前正在 All-in 的，正是經過 Anthos 這樣的 Kubernetes 混合雲底座，將 Google Cloud 服務交付到在全世界任何一個數據中心上去。

正在被打破的雲計算「三層架構」

長久以來，業界對雲計算的認知，一直圍繞着「SaaS + PaaS + IaaS」這樣經典的三層架構模型展開。然而，在 2020 年，隨着雲原生技術的極大普及，咱們卻發現這個模型彷佛正遭受着挑戰。

今天的雲原生技術，起源於 Docker 以及容器這個創新性的技術革命，又受益於經典 PaaS （好比 Cloud Foundry）持續已久的心智普及，最終在開發者與平臺構建者的雙重關注下，以 Kubernetes 生態爲載體最終落地。

在 2020 年，伴隨着雲原生技術逐步成熟，面向用戶的應用管理平臺的形態也逐漸開始從以 Cloud Foundry/Heroku 爲主體的經典 PaaS 形態（即：企業級 PaaS），向輕量級的 App Service 好比 Shipa 和 Kalm 等方向靠攏。不過，輕量級 App Service 本質上仍是 Heroku 體驗在 Kubernetes 底座上的復刻，它們在提供出色的開發者使用體驗的同時，也繼承了經典 PaaS 的「封閉」與「不可擴展」，這在不少大型企業基於雲原生技術棧 「DIY」 屬於本身的「PaaS」的訴求下，依然會顯得力不從心。

事實上，對於愈來愈多的平臺構建者來講，隨着雲原生技術的日趨落地，「PaaS」自己的「解釋權」再也不屬於某一家提供商，而更多取決於平臺構建者的業務場景和其終端用戶的實際需求。此外，對於「SaaS」來講，雲原生帶來的容器化軟件打包與交付體系和 Kubernetes 底座，也已經極大地改變了雲端軟件的分發與運維方式。因此，不管是 PaaS 也好，仍是 SaaS 也好，本質上正在被「雲原生」的技術浪潮迅速「壓平」，在這種背景下，傳統「水平」劃分雲計算體系的方法其實已經變得難以自洽。一個典型的例子就是：今天你既不能把 Kubernetes 稱做是 PaaS，也不能把它稱做是 IaaS。它是一個獨特的基礎設施能力接入層與平臺層抽象，做爲平臺構建者，你能夠基於它構建你心目中任何上層平臺，而至於你把這個上層平臺稱做是 PaaS / Serverless / FaaS，甚至是 SaaS，只是進一步抽象的程度和依賴的垂直能力不一樣而已：這裏並無」誰蓋在誰頭上」這樣的劃分。

下一代雲原平生臺構建體系的崛起

Kubernetes 的成功，極大使能了「平臺構建者」這個以往被人們遺忘在企業成本中心（Cost Center） 裏的重要角色。事實上，Kubernetes 之因此可以取代 Docker 生態成爲今天雲計算平臺上的主角，很大程度上是這個羣體作出了最終的決定。不然，按照 Docker 所觸達到的用戶羣體規模以及其在開發者生態中的被接納度， Kubernetes 幾乎毫無勝算。這一點常常是被你們所忽視的。實際上，在企業級平臺落地的過程當中，平臺的最終用戶（好比業務研發與運維）雖然是「顧客與上帝」，但真正能在這個過程當中起到關鍵做用和具備最終決定權的，每每仍是業務背後的平臺團隊和老闆們。

但與此同時，Kubernetes 之上的平臺構建生態，在今天依然是高度集中的。一個典型的觀察就是，今天可以基於 Kubernetes 成體系構建出完整上層平臺的團隊，其實集中在1、二線大型互聯網公司當中，而且其實踐每每「僅供參考」，鮮有可複製性。進一步的，雲原生的極大普及，彷佛並無真正可以讓平臺構建者輕鬆地構建 PaaS 或者其餘上層平臺。這其實也進一步解釋了前面咱們觀察到的「PaaS 生態「在雲原生時代的停滯：基於 Kubernetes 構建上層平臺（包括 PaaS），在 2020 年依然是大型公司和高技術水位團隊們的專利。

這種平臺構建生態的高度集中，與雲原生但願構建的「普惠式」將來，顯然是不相符的。固然，既然技術發展尚未跟上願景，那麼雲原生社區也就不會停下腳步。

事實上，平臺構建者之因此要基於 Kubernetes 進一步構建上層平臺，其根本動機無非來自兩個訴求：

1. 更高的抽象維度：好比，用戶但願操做的概念是「應用」和「灰度發佈」，而不是「容器」和「Pod」。
2. 更多的擴展能力：好比，用戶但願的應用灰度發佈策略是基於「雙 Deployment + Istio」 的金絲雀發佈，而不是 Kubernetes 默認的 Pod 線性滾動升級。這些加強或者擴展能力，在 Kubernetes 中通常是以 CRD + Controller 的插件方式來實現的。

因此說，基於 Kubernetes 構建上層平臺在今天看起來彷佛雜亂無章、沒什麼規律，但本質上都不會離開「抽象 + 插件能力管理」這兩個核心訴求。再舉個例子，今天你們爲 Kubernetes 構建的各類 Dashboard，其實就是一種「抽象」的實現方式：這些 Dashboard 本質上是在 Kubernetes API 對象的基礎上暴露出了一組容許用戶填寫的字段，從而實現了「簡化用戶使用心智、提高用戶體驗」的目的 —— 這固然也是全部「抽象」的根本目標。

基於對「抽象 + 插件能力管理」這兩個訴求的持續實踐與思考，雲原生社區在 2020 年誕生了像 KubeVela 這樣專一於使能平臺團隊構建上層平臺的開源項目。這個項目的定位在整個雲原生生態中是很是獨特的：它並非某種垂直能力，更像是一套基於 Kubernetes 構建上層平臺的「工具」組合，好比：

1. 基於模板的抽象機制，以及基於今生成能力使用文檔和 OpenAPI Schema 的自動化流程（從而幫助平臺團隊快速構建 Dashboard 或者 Appfile）。
2. 基於 OAM 模型的插件式能力註冊、管理與發現機制，以此來模塊化、自動化的管理插件能力，甚至提早預警插件能力之間的衝突等。

無獨有偶，在阿里雲開源 KubeVela 項目後不久，雲計算領頭羊 AWS 在 Re:Invent 2020 上也高調宣佈了 AWS Proton 商業產品的正式誕生，其思想同 KubeVela 項目很是相似，只不過構建平臺的底座換成了 AWS 雲平臺，定義抽象的模板使用了 AWS 本身的 Cloud Formation (KubeVela 目前支持的是 Google 開源的 CUELang 模板語言）。

能夠預見，在雲原生與 Kubernetes 項目極大程度地統一與標準化了基礎設施層抽象以後，如何進一步幫助平臺團隊在此之上快速、輕鬆、可複製地構建上層平臺，正在成爲業界開始積極思考的一條關鍵路徑。再一次的，你很難在傳統的雲計算「三層架構」中找到適合這些產品的位置，不管是 KubeVela 仍是 AWS Proton，它們既不是 PaaS，也不是 IaaS，更不是 Kubernetes 的競爭者：它們是雲原生背景下新一代平臺構建體系逐步崛起的萌芽。

探索雲原生的下一站

2020 年的雲原生能夠說是整個雲計算生態中發展最迅速的一條主線脈絡，而也正是伴隨着這樣的發展勁頭，雲原生在新的一年裏，已經要開始思考它的下一步發展空間。事實上，咱們已經可以看到各類各樣的廠商和團隊在不一樣的領域積極發力和探索。

1. 本地開發與測試

使能開發者面向 Kubernetes 進行本地開發和測試正在開始成爲一個備受關注的話題，在這個領域中，來自紐約的 Tilt 項目是其中的佼佼者。阿里雲和騰訊雲也分別有這個話題下的不一樣維度的解決方案，好比 KT Connet 和 Nocalhost。

2. 雲原生「中間件」的技術變革

Sidecar 模式正在以更加迅猛的勢頭將中間件領域的能力下沉至 Kubernetes 這個新一代的應用基礎設施當中，除了已經如火如荼的 Istio 對流量治理領域的顛覆，微軟已經不甘示弱的開源了 Open Service Mesh 做爲迴應。而與此同時， OAM 在微軟的姊妹項目 Dapr 則直接拉齊了 Kubernetes 與中間件在「服務發現與綁定」側的距離，老牌項目 Dubbo 亦宣佈了下一代雲原生中間件的技術藍圖。固然， 全部這一切背後的用戶動機是很是清晰的：雲原生時代的中間件，要語言無關，要平臺無關。

3. 「邊緣」與 Kubernetes 發行版

Kubernetes 的「安卓化」趨勢，少不了將 Kubernetes 部署到全世界任何一個數據中心去的「雄心壯志」，這裏固然也包括「邊緣」設備。除了華爲的拳頭產品 KubeEdge 以外，阿里雲的 OpenYurt 項目在 2020 年也進入了 CNCF 沙箱孵化，而騰訊雲則提出了 SuperEdge 緊隨其後。與此同時，AWS 在 2020 年重磅開源了其 EKS 服務背後的 Kubernetes 發行版 EKS-D，這裏固然隱含了對 Google Cloud 的 Anthos 和微軟雲的 Arc 佈局的強勢迴應。能夠預見，雲廠商們對「將 Kubernetes 部署到任何一個角落」的這份執著，會讓 Kubernetes 「安卓化」比想象中來得更快，也少不了在 ISV 和服務集成商側的一番「腥風血雨」。

4. 雲原生應用管理與 GitOps

雲原生應用管理與交付，已然正在成爲 Kubernetes 這個「新安卓」之上重要的價值聚焦點。在這個領域，阿里雲聯合微軟的 OAM + OpenKruise 組合已經嶄露頭角，與此同時，社區上也出現了 KubeVela 這樣進一步使能平臺構建者的開源框架，開發者工具領域的佼佼者 Hashicorp，更是不失時機的發佈了 Waypoint 這樣的跨平臺開發者界面工具。而伴隨着 Kubernetes 之上的應用層技術快速演進的同時，基於 Git 做爲應用配置管理中心交付應用的理念（即：GitOps），則正在迅速取代傳統 CI/CD 中的 CD 環節，成爲 Kubernetes 上應用分發的不二之選。在 2020 年底，CNCF 應用交付領域小組正式宣佈了 GitOps Working Group 的組建，頗有可能會將 GitOps 逐步推向雲原生 CD 的事實標準。在 Kubernetes 「安卓化」勢不可擋的今天，咱們對這個領域在新的一年即將出現的更多顛覆與創新充滿期待。

2020 年：沒有「確切定義」的雲原生

「雲原生」究竟是什麼？它就是容器和 Kubernetes 嗎？虛擬機是雲原生的嗎？……

這些「靈魂拷問」，一直是不少初次接觸雲原生理念的公司和團隊經常提出的困惑。實際上，做爲一套「以利用雲計算技術爲用戶降本增效」的最佳實踐與方法論，雲原生這個術語自誕生，到壯大，再到今天的極大普及，都處於一個不斷的自我演進與革新的過程中。這種「永遠沒有確切定義」的持續生命力，纔是「雲原生」之因此對雲計算生態充滿吸引力的源泉。

在 2020 年，整個雲原生社區在不一樣領域的積極探索與嘗試，正在取代 Kubernetes、Service Mesh 等已經成熟的實現項目，逐步成爲雲原生生態獨一無二的主旋律。這其實不難理解，雲原生髮展到今天，正在離它所暢想的「軟件自然生在雲上、長在雲上」愈來愈近，但也暴露出了現有的雲原生技術底盤過度關注於基礎設施抽象與管理、忽視了最終用戶側的體驗和技術帶來的諸多問題。這些問題，須要依靠整個雲原生社區不停歇的思考、沉澱與再創新進行補充和修正，才能讓雲原生的技術價值逐步「上浮」，對最終用戶產生直接的價值與體感；也才能讓雲原生技術逐步「民主化」，讓構建簡單、易用的雲原平生臺再也不成爲大公司們「秀肌肉」的專屬。

相關開源項目傳送門：

• KubeVela：

https://github.com/oam-dev/kubevela

• OpenKruise：

https://github.com/openkruise

• OpenYurt：

https://github.com/alibaba/openyurt

做者簡介

張磊，阿里雲高級技術專家，CNCF SIG App Delivery Co-chair，CNCF 官方大使