作者 | 張磊

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

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

在 2020 年，沒(méi)有人再會(huì)去質疑一個平台團隊采納 Kubernetes 作爲自己的基礎設施的合理性。事(shì)實上，2020 年的 Kubernetes 項目已經(jīng)非常接近于的完成(chéng)了它最重要的使命，即：爲雲計算基礎設施帶來一層可以讓平台團隊基于此構造“一切”的平台層抽象。

我們已經(jīng)能(néng)夠看到， 今天的雲原生社區已經(jīng)開(kāi)始廣泛認可 Kubernetes 項目作爲“The platform for platform”的定位與價值，越來越多的平台團隊正在基于 Kubernetes 構建各種(zhǒng)各樣的上層平台，PaaS, Serverless, AI Platform, Database PaaS 等等。面(miàn)向(xiàng)終态的聲明式 API 與其背後(hòu)“辛勤”工作的控制器，爲“構建基礎設施層抽象”這(zhè)個充滿了挑戰的技術難題，提供了一個能(néng)夠在複雜度與可用性之間取得平衡的解決方案。正是基于此，Kubernetes 項目才擁有了龐大的集成(chéng)生态，讓這(zhè)個“企業基礎設施的标準抽象”，逐步成(chéng)爲了業界公認的事(shì)實。

而更爲重要的是，Kubernetes 真正的成(chéng)功之處，在于它真正押注的是構建抽象的方法而非這(zhè)些抽象本身。在絕大多數情況下，企業基于 Kubernetes 構建上層平台，都(dōu)會(huì)引入各種(zhǒng)各樣其他的抽象作爲補充，甚至取代或者隐藏掉 Kubernetes 的部分内置抽象：阿裡(lǐ)巴巴開(kāi)源的 CloneSet，騰訊的 GameStatefulSet 實踐等擴展型工作負載等都(dōu)是這(zhè)個趨勢的最好(hǎo)的案例。

伴随著(zhe) Kubernetes 生态從底層到應用層能(néng)力的逐步完善，在 2020 年，更多大型互聯網終端企業開(kāi)始加入到了雲原生的梯隊當中。我們看到原本的 Mesos 生态标杆 Apple 公司成(chéng)爲了 KubeCon 2020 北美上的絕對(duì)主角，而金融巨頭 MasterCard 則分享了他們基于 OAM、Kubernetes 和 Crossplane 項目構建跨雲、跨運行時(shí)應用交付平台的内部落地案例。而尤爲值得一提的是，這(zhè)些以往在底層基礎技術上給人以”保守“印象的大型非雲企業，在 2020 年紛紛祭出了對(duì)很多新興技術比如 Virtual Cluster 和标準應用模型技術上的落地與思考。雲原生浪潮對(duì)整個技術産業帶來的深遠影響可見一斑。

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

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

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

長(cháng)久以來，業界對(duì)雲計算的認知，一直圍繞著(zhe)”SaaS + PaaS + IaaS“這(zhè)樣經(jīng)典的三層架構模型展開(kāi)。然而，在 2020 年，随著(zhe)雲原生技術的極大普及，我們卻發(fā)現這(zhè)個模型似乎正遭受著(zhe)挑戰。

今天的雲原生技術，起(qǐ)源于 Docker 以及容器這(zhè)個創新性的技術革命，又受益于經(jīng)典 PaaS （比如 Cloud Foundry）持續已久的心智普及，最終在開(kāi)發(fā)者與平台構建者的雙重關注下，以 Kubernetes 生态爲載體最終落地。

在 2020 年，伴随著(zhe)雲原生技術逐步成(chéng)熟，面(miàn)向(xiàng)用戶的應用管理平台的形态也逐漸開(kāi)始從以 Cloud Foundry/Heroku 爲主體的經(jīng)典 PaaS 形态（即：企業級 PaaS），向(xiàng)輕量級的 App Service 比如 Shipa 和 Kalm 等方向(xiàng)靠攏。不過(guò)，輕量級 App Service 本質上還(hái)是 Heroku 體驗在 Kubernetes 底座上的複刻，它們在提供出色的開(kāi)發(fā)者使用體驗的同時(shí)，也繼承了經(jīng)典 PaaS 的“封閉”與“不可擴展”，這(zhè)在很多大型企業基于雲原生技術棧“DIY”屬于自己的“PaaS”的訴求下，依然會(huì)顯得力不從心。

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

下一代雲原生平台構建體系的崛起(qǐ)

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

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

這(zhè)種(zhǒng)平台構建這(zhè)生态的高度集中，與雲原生希望構建的“普惠式”未來，顯然是不相符的。當然，既然技術發(fā)展還(hái)沒(méi)有跟上願景，那麼(me)雲原生社區也就(jiù)不會(huì)停下腳步。

事(shì)實上，平台構建者之所以要基于 Kubernetes 進(jìn)一步構建上層平台，其根本動機無非來自兩(liǎng)個訴求：

1. 更高的抽象維度：比如，用戶希望操作的概念是“應用”和“灰度發(fā)布”，而不是“容器”和“Pod”；

2. 更多的擴展能(néng)力：比如，用戶希望的應用灰度發(fā)布策略是基于“雙 Deployment + Istio” 的金絲雀發(fā)布，而不是 Kubernetes 默認的 Pod 線性滾動升級。這(zhè)些增強或者擴展能(néng)力，在 Kubernetes 中一般是以 CRD + Controller 的插件方式來實現的。

所以說(shuō)，基于 Kubernetes 構建上層平台在今天看起(qǐ)來似乎雜亂無章、沒(méi)什麼(me)規律，但本質上都(dōu)不會(huì)離開(kāi)“抽象 + 插件能(néng)力管理”這(zhè)兩(liǎng)個核心訴求。再舉個例子，今天大家爲 Kubernetes 構建的各種(zhǒng) Dashboard，其實就(jiù)是一種(zhǒng)“抽象”的實現方式：這(zhè)些 Dashboard 本質上是在 Kubernetes API 對(duì)象的基礎上暴露出了一組允許用戶填寫的字段，從而實現了‘’簡化用戶使用心智、提升用戶體驗‘’的目的 —— 這(zhè)當然也是所有“抽象”的根本目标。

基于對(duì)“抽象 + 插件能(néng)力管理”這(zhè)兩(liǎng)個訴求的持續實踐與思考，雲原生社區在 2020 年誕生了像 KubeVela 這(zhè)樣專注于使能(néng)平台團隊構建上層平台的開(kāi)源項目。這(zhè)個項目的定位在整個雲原生生态中是非常獨特的：它并不是某種(zhǒng)垂直能(néng)力，它更像是一套基于 Kubernetes 構建上層平台的“工具”組合，比如：

1. 基于模闆的抽象機制，以及基于此生成(chéng)能(néng)力使用文檔和 OpenAPI Schema 的自動化流程（從而幫助平台團隊快速構建 Dashboard 或者 Appfile）；

2. 基于 OAM 模型的插件式能(néng)力注冊、管理與發(fā)現機制，以此來模塊化、自動化的管理插件能(néng)力，甚至提前預警插件能(néng)力之間的沖突等。

無獨有偶，在阿裡(lǐ)雲開(kāi)源 KubeVela 項目後(hòu)不久，雲計算領頭羊 AWS 在 Re:Invent 2020 上也高調宣布了 AWS Proton 商業産品的正式誕生，其思想同 KubeVela 項目非常類似，隻不過(guò)構建平台的底座換成(chéng)了 AWS 雲平台，定義抽象的模闆使用了 AWS 自己的 Cloud Formation (KubeVela 目前支持的是 Google 開(kāi)源的 CUELang 模闆語言）。

可以預見，在雲原生與 Kubernetes 項目極大程度的統一與标準化了基礎設施層抽象之後(hòu)，如何進(jìn)一步幫助平台團隊在此之上快速、輕松、可複制的構建上層平台，正在成(chéng)爲業界開(kāi)始積極思考的一條關鍵路徑。再一次的，你很難在傳統的雲計算“三層架構”中找到适合這(zhè)些産品的位置，無論是 KubeVela 還(hái)是 AWS Proton，它們既不是 PaaS，也不是 IaaS，更不是 Kubernetes 的競争者：它們是雲原生背景下新一代平台構建體系逐步崛起(qǐ)的萌芽。

探索雲原生的下一站

2020 年的雲原生可以說(shuō)是整個雲計算生态中發(fā)展最迅速的一條主線脈絡，而也正是伴随著(zhe)這(zhè)樣的發(fā)展勁頭，雲原生在新的一年裡(lǐ)，已經(jīng)要開(kāi)始思考它的下一步發(fā)展空間。事(shì)實上，我們已經(jīng)能(néng)夠看到各種(zhǒng)各樣的廠商和團隊在不同的領域積極發(fā)力和探索。

本地開(kāi)發(fā)與測試

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

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

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

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

Kubernetes 的“安卓化”趨勢，少不了將(jiāng) Kubernetes 部署到全世界任何一個數據中心去的“雄心壯志”，這(zhè)裡(lǐ)當然也包括“邊緣”設備。除了華爲的拳頭産品 KubeEdge 之外，阿裡(lǐ)雲的 OpenYurt 項目在 2020 年也進(jìn)入了 CNCF 沙箱孵化，而騰訊雲則提出了 SuperEdge 緊随其後(hòu)。與此同時(shí)，AWS 在 2020 年重磅開(kāi)源了其 EKS 服務背後(hòu)的 Kubernetes 發(fā)行版 EKS-D，這(zhè)裡(lǐ)當然隐含了對(duì) Google Cloud 的 Anthos 和微軟雲的 Arc 布局的強勢回應。可以預見，雲廠商們對(duì)“將(jiāng) Kubernetes 部署到任何一個角落”的這(zhè)份執著，會(huì)讓 Kubernetes “安卓化”比想象中來得更快，也少不了在 ISV 和服務集成(chéng)商側的一番“腥風血雨”。

雲原生應用管理與 GitOps

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

2020 年：沒(méi)有“确切定義”的雲原生

“雲原生”到底是什麼(me)？它就(jiù)是容器和 Kubernetes 嗎？虛拟機是雲原生的嗎？……

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

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

作者介紹：

張磊，阿裡(lǐ)雲高級技術專家，CNCF SIG App Delivery Co-chair，CNCF 官方大使