![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/95e2e220445d4496a7002804b858587e.png)

作者 | 張磊
來源|[阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/es_7gB4XbN0-cKlf0yXfrw)

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](https://openkruise.io/en-us/docs/cloneset.html)、騰訊的 [GameStatefulSet](https://www.cnblogs.com/tencent-cloud-native/p/14136918.html) 實踐等擴充套件型工作負載等都是這個趨勢的最好的案例。

伴隨著 Kubernetes 生態從底層到應用層能力的逐步完善，在 2020 年，更多大型網際網路終端企業開始加入到了雲原生的梯隊當中。我們看到原本的 Mesos 生態標杆 Apple 公司成為了 KubeCon 2020 北美上的絕對主角，而金融巨頭 MasterCard 則分享了他們基於 OAM、Kubernetes 和 Crossplane 專案構建跨雲、跨執行時應用交付平臺的內部落地案例。而尤為值得一提的是，這些以往在底層基礎技術上給人以”保守“印象的大型非雲企業，在 2020 年紛紛祭出了對很多新興技術比如 [Virtual Cluster](https://github.com/kubernetes-sigs/cluster-api-provider-nested) 和[標準應用模型技術](https://github.com/oam-dev/spec)上的落地與思考。雲原生浪潮對整個技術產業帶來的深遠影響可見一斑。

此外，我們也不難觀察到，**Kubernetes 的極大普及以及基於它興起的上層生態，正在跟安卓（Android）的發展路徑越來越明顯的趨同**。安卓能夠對下以一套統一的方式抽象與整合不同的手機、電視、甚至汽車等硬體裝置，對上則為程式設計師暴露出統一的一套開發介面，使他們能夠以這套統一的抽象去訪問或者享受到這些基礎設施能力。這種定位與 Kubernetes 非常類似，這裡唯一的區別在於，安卓服務的程式設計師是 APP 開發者，而 Kubernetes 服務的“程式設計師”，則是平臺構建者。在這個背景下，諸如“Kubernetes 拋棄 Docker”之類的新聞會很容易理解：安卓本身就不需要專注於手機的電池是哪個牌子的。

這個路徑，可能也是 Google 比較擅長的一個“打法”：全力地去免費推廣一個“作業系統”，真正獲取商業價值的方式則是是去“收割”作業系統上層的生態價值，而不是作業系統本身。畢竟使用者是不會花錢去購買安卓的。所以 Google Cloud 目前正在 All-in 的，正是透過 [Anthos](https://cloud.google.com/anthos) 這樣的 Kubernetes 混合雲底座，將 Google Cloud 服務交付到在全世界任何一個資料中心上去。

# 正在被打破的雲端計算“三層架構”

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

![1.png](https://ucc.alicdn.com/pic/developer-ecology/7266c5c811884a81a10d0f75aa6301ca.png)

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

在 2020 年，伴隨著雲原生技術逐步成熟，面向使用者的應用管理平臺的形態也逐漸開始從以 Cloud Foundry/Heroku 為主體的經典 PaaS 形態（即：企業級 PaaS），向輕量級的 App Service 比如 [Shipa](https://shipa.io/) 和 [Kalm](https://kalm.dev/) 等方向靠攏。不過，輕量級 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”。
1. **更多的擴充套件能力**：比如，使用者希望的應用灰度釋出策略是基於“雙 Deployment + Istio” 的金絲雀釋出，而不是 Kubernetes 預設的 Pod 線性滾動升級。這些增強或者擴充套件能力，在 Kubernetes 中一般是以 CRD + Controller 的外掛方式來實現的。

所以說，基於 Kubernetes 構建上層平臺在今天看起來似乎雜亂無章、沒什麼規律，但本質上都不會離開“抽象 + 外掛能力管理”這兩個核心訴求。再舉個例子，今天大家為 Kubernetes 構建的各種 Dashboard，其實就是一種“抽象”的實現方式：這些 Dashboard 本質上是在 Kubernetes API 物件的基礎上暴露出了一組允許使用者填寫的欄位，從而實現了“簡化使用者使用心智、提升使用者體驗”的目的 —— 這當然也是所有“抽象”的根本目標。

基於對“抽象 + 外掛能力管理”這兩個訴求的持續實踐與思考，雲原生社群在 2020 年誕生了像 [KubeVela](https://github.com/oam-dev/kubevela) 這樣專注於使能平臺團隊構建上層平臺的開源專案。這個專案的定位在整個雲原生生態中是非常獨特的：它並不是某種垂直能力，更像是一套基於 Kubernetes 構建上層平臺的“工具”組合，比如：

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

![2.png](https://ucc.alicdn.com/pic/developer-ecology/bc84da3fdfaf48d98a8abba376b95f39.png)

無獨有偶，在阿里雲開源 KubeVela 專案後不久，**雲端計算領頭羊 AWS 在 Re:Invent 2020 上也高調宣佈了 **[**AWS Proton 商業產品**](https://aws.amazon.com/cn/proton/)**的正式誕生**，其思想同 KubeVela 專案非常類似，只不過構建平臺的底座換成了 AWS 雲平臺，定義抽象的模板使用了 AWS 自己的 Cloud Formation (KubeVela 目前支援的是 Google 開源的 CUELang 模板語言）。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/4ecc1bd10918403bb9b7a55d0b1ab0b3.png)

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

# 探索雲原生的下一站

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

## 1. 本地開發與測試

使能開發者面向 Kubernetes 進行本地開發和測試正在開始成為一個備受關注的話題，在這個領域中，來自紐約的 [Tilt](https://tilt.dev/) 專案是其中的佼佼者。阿里雲和騰訊雲也分別有這個話題下的不同維度的解決方案，比如 [KT Connet](https://github.com/alibaba/kt-connect) 和 [Nocalhost](https://github.com/nocalhost/nocalhost)。

## 2. 雲原生“中介軟體”的技術變革

Sidecar 模式正在以更加迅猛的勢頭將中介軟體領域的能力下沉至 Kubernetes 這個新一代的應用基礎設施當中，除了已經如火如荼的 Istio 對流量治理領域的顛覆，微軟已經不甘示弱的開源了 [Open Service Mesh](https://openservicemesh.io/) 作為回應。而與此同時， OAM 在微軟的姊妹專案 [Dapr](https://dapr.io/) 則直接拉齊了 Kubernetes 與中介軟體在“服務發現與繫結”側的距離，老牌專案 Dubbo 亦宣佈了下一代雲原生中介軟體的[技術藍圖](https://developer.aliyun.com/article/770964)。當然， 所有這一切背後的使用者動機是非常清晰的：雲原生時代的中介軟體，要語言無關，要平臺無關。

## 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 嗎？虛擬機器是雲原生的嗎？……

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

![4.png](https://ucc.alicdn.com/pic/developer-ecology/724300ddaf684628b2886d042af4ab26.png)

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

相關開源專案傳送門：

- [**KubeVela**](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247496420&idx=1&sn=3c7f079c40fde0ea915c3960b8939062&chksm=fae6f92bcd91703d8cc7f8584a050efd6cfe9c62d5801d89ce7799bcc595dadf54b7ad2544ea&scene=21#wechat_redirect)：
[https://github.com/oam-dev/kubevela](https://github.com/oam-dev/kubevela)

- [**OpenKruise**](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247499530&idx=1&sn=39d9661993b94e43aff0e0af7967ed4a&chksm=fae6f4c5cd917dd353f9464b73df0d9fecc0ed854a630621d46591fcc3f36fe8e4a9bdba30e5&scene=21#wechat_redirect)：
[https://github.com/openkruise](https://github.com/openkruise)

- [**OpenYurt**](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247499784&idx=1&sn=df40f51cc1c4c073cda886247656c4ee&chksm=fae6cbc7cd9142d106f3014915878aa3bfb19b3fdbaef97ea75568668310aabaa31a1a7fa4c1&scene=21#wechat_redirect)：
[https://github.com/alibaba/openyurt](https://github.com/alibaba/openyurt)

### **作者簡介**

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

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

相關文章