解讀容器的 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 成體系建構出完整上層平台的團隊，其實集中在一、二線大型網際網路公司當中，并且其實踐往往“僅供參考”，鮮有可複制性。進一步的，雲原生的極大普及，似乎并沒有真正能夠讓平台建構者輕松地建構 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 等已經成熟的實作項目，逐漸成為雲原生生态獨一無二的主旋律。這其實不難了解，雲原生發展到今天，正在離它所暢想的“軟體天然生在雲上、長在雲上”越來越近，但也暴露出了現有的雲原生技術底盤過分關注于基礎設施抽象與管理、忽視了最終使用者側的體驗和技術帶來的諸多問題。這些問題，需要依靠整個雲原生社群不停歇的思考、沉澱與再創新進行補充和修正，才能讓雲原生的技術價值逐漸“上浮”，對最終使用者産生直接的價值與體感；也才能讓雲原生技術逐漸“民主化”，讓建構簡單、易用的雲原生平台不再成為大公司們“秀肌肉”的專屬。

相關開源項目傳送門：

• ： https://github.com/oam-dev/kubevela
• OpenKruise https://github.com/openkruise
• OpenYurt https://github.com/alibaba/openyurt

作者簡介

張磊，阿裡雲進階技術專家，CNCF SIG App Delivery Co-chair，CNCF 官方大使