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

1. 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 服務交付到在全世界任何一個數據中心上去。

2. 正在被打破的云計算“三層架構”

長久以來，業界對云計算的認知，一直圍繞著”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，只是進一步抽象的程度和依賴的垂直能力不同而已：這里并沒有”誰蓋在誰頭上”這樣的劃分。

3. 下一代云原生平臺構建體系的崛起

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

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

這種平臺構建這生態的高度集中，與云原生希望構建的“普惠式”未來，顯然是不相符的。當然，既然技術發展還沒有跟上愿景，那么云原生社區也就不會停下腳步。

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

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

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

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

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

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

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

4. 探索云原生的下一站

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

本地開發與測試

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

云原生“中間件”的技術變革

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

“邊緣”與 Kubernetes 發行版

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

云原生應用管理與 GitOps

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

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

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

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

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