雲原生五大趨勢預測，K8s 安卓化位列其一

做者 | 李響、張磊

Kubernetes 自己並不直接產生商業價值，你不會花錢去購買 Kubernetes 。這就跟安卓同樣，你不會直接掏錢去買一個安卓系統。Kubernetes 真正產生價值的地方也在於它的上層應用生態。

「將來的軟件必定是生長於雲上的」，這是雲原生理念的最核心假設。而所謂「雲原生」，實際上就是在定義一條可以讓應用最大程度利用雲的能力、發揮雲的價值的最佳路徑。所以，雲原生實際上是一套指導軟件架構設計的思想。按照這樣的思想而設計出來的軟件：首先，自然就「生在雲上，長在雲上」；其次，可以最大化地發揮雲的能力，使得咱們開發的軟件和「雲」可以自然地集成在一塊兒，發揮出「雲」的最大價值。

雲原生的概念你們並不陌生，不少企業也已經基於雲原生的架構和技術理念落地相關實踐。那麼，這麼多企業和開發者熱衷和推崇的雲原生，將來的發展趨勢如何？如何才能順應雲原生的主流方向去發展？ 

咱們邀請到阿里雲資深技術專家、CNCF 技術監督委員會表明，etcd 做者李響和阿里雲高級技術專家、CNCF 應用交付領域 co-chair 張磊分享雲原生的理念、發展以及將來趨勢，爲你們打開新的思路和眼界。

如下內容共享給你們。

Kubernetes 項目的安卓化

雲原生裏有一個很是關鍵的項目，就是 Kubernetes。Kubernetes 的發展很是迅速，它是整個雲原生體系發展的基石。今天咱們來觀察 Kubernetes 項目的發展特色，首先，Kubernetes 無處不在，不管是在雲上，仍是用戶自建的數據中內心，甚至一些咱們想象不到的場景裏，都有 Kubernetes 的存在。

第二，全部雲原生的用戶使用 Kubernetes 的目的，都是爲了交付和管理應用。固然這個應用是一個泛化的概念，能夠是一個網站，也能夠是淘寶這樣很是龐大的電商主站，或者是 AI 做業、計算任務、函數、甚至虛擬機等，這些都是用戶可使用 Kubernetes 去交付和管理的應用類型。

第三，今天咱們來看 Kubernetes 所處的位置，其實是承上啓下。Kubernetes 對上暴露基礎設施能力的格式化數據抽象，好比 Service、Ingress、Pod、Deployment，這些都是 Kubernetes 自己原生 API 給用戶暴露出來的能力。而對下，Kubernetes 提供的是基礎設施能力接入的標準接口，好比說 CNI、CSI、DevicePlugin、CRD，讓雲可以做爲一個能力提供商，以一個標準化的方式把能力接入到 Kubernetes 的體系中。

這一點其實跟安卓很是相似，安卓雖然裝在你的設備裏，可是它可以讓你的硬件、手機、電視、汽車等都能接入到一個平臺裏。對上則暴露統一的一套應用管理接口，讓你可以基於安卓系統來編寫應用，去訪問或者享受到這些基礎設施能力，這也是 Kubernetes 和安卓的類似之處。

最後， Kubernetes 自己並不直接產生商業價值，你不會花錢去購買 Kubernetes。這就跟安卓同樣，你不會直接掏錢去買一個安卓系統。Kubernetes 真正產生價值的地方也在於它的上層應用生態。對安卓來講，它今天已經具有了一個龐大的移動端或設備端應用的開發生態，而對於 Kubernetes 來講也是相似的，只不過如今還在於比較早的階段。但咱們已經可以看到，今天在 Kubernetes 上構建的商業層不少是垂直解決方案，是面向用戶、面向應用這一側真正可以產生商業價值的東西，而不是 Kubernetes 自己這一層。這就是爲何我說 Kubernetes 發展跟安卓很像，固然這可能也是谷歌比較擅長的一個「打法」：全力地去免費推廣一個「操做系統」，真正獲取商業價值的方式則是是去「收割」操做系統上層的生態價值而不是操做系統自己。

基於這些現象，咱們將 Kubernetes 的發展趨勢歸納爲如下幾點：

1. 雲的價值迴歸到應用自己

用戶使用 Kubernetes 的本質目的是去交付和管理應用。從這個現象來看，若是 Kubernetes 發展下去，那麼世界上全部的數據中心和基礎設施上面都會有一層 Kubernetes ，天然而然用戶就會開始以 Kubernetes 爲基礎去編寫和交付以及管理其應用，就跟如今咱們會以安卓這樣一個操做系統爲基礎去編寫移動應用是相似的。

這就會致使雲上的大多數軟件和雲產品都是第三方開發的。第三方開發是指全部人均可以面向一個標準界面去開發和交付軟件，這個軟件自己既能夠是本身的軟件，也能夠是一個雲產品。將來，愈來愈多的第三方開源項目，如 MongoDB、Elasticsearch 等，都會以雲原生理念去開發、部署和運維，最後直接演進成爲一種雲服務。

2. 雲端「豌豆莢」的出現

有了 Kubernetes 這樣一個標準，開發者面對的就是一個相似於操做系統的界面。因爲有更多的應用是面向 Kubernetes 誕生的，或者說面向 Kubernetes 去交付的，那麼就須要有一個相似於「豌豆莢」的產品，來做爲雲上的應用商店或者雲上的應用分發系統，它的關鍵能力在於把應用無差異地交付給全世界任何一個 Kubernetes 上面，就跟用豌豆莢把任何一個安卓應用交付在任何一個安卓設備上的原理是同樣的。

其實今天谷歌已經在作這類產品的嘗試了，好比 Anthos （面向混合雲的應用交付平臺），雖然是一款混合雲產品，但它本質上是把谷歌雲的服務，好比數據庫服務、大數據服務，去直接交付於任何一個基於 Kubernetes 的混合雲環境裏面去，其實就至關於一款雲端的「豌豆莢」。

3. 基於 Kubernetes 可擴展能力的開放應用平臺會取代 PaaS 成爲主流

因爲將來整個應用生態會面向 Kubernetes 去構建，那麼基於 Kubernetes 可擴展能力的開放應用平臺會逐漸取代傳統 PaaS 而成爲主流。基於 Kubernetes 可擴展能力去構建一個開放的應用平臺，其能力是可插拔的，可以去交付和管理的應用類型是多樣化的，這才更符合 Kubernetes 所構建的趨勢和生態，因此一些真正高可擴展的平臺層項目會大量產生。

另外，今天咱們看到的 Kubernetes ，跟「理想」中的雲原生應用生態之間其實還有不少路要走，這也是阿里雲原生團隊一直在作的事情，基於 Kubernetes 在應用層構建更豐富的應用生態，幫助用戶實現多樣化的需求。

應用與能力的「 Operator 化」

縱觀雲原生時代應用或者雲的能力的發展方向，你會發現另外一個趨勢，就是 Operator 化。Operator 是 Kubernetes 的一個概念，是指 Kubernetes 交付的一個實體，這個實體有一個基礎模型存在，這個模型分爲兩部分：一部分是 Kubernetes 的  API  對象（CRD），另外一部分是一個控制器（Controller），以下圖所示：

這裏要區分兩個概念，自定義和自動化。不少人會說 Operator 能夠幫助我作自定義，由於不少人都會以爲 Kubernetes 內置的能力是不夠用的，因此用戶會利用它的可擴展能力去寫一個 Controller ，從而實現跟多自定義的需求。但自定義只是 Operator 中很小的一部分價值，咱們今天對應用和能力作 Operator 化的核心動力在於實際上是爲了實現自動化，並且只有自動化了，咱們才能講雲原生。

這是由於，雲原生帶來的最大的紅利是可讓咱們最大限度、最高效地使用雲的能力，二這種最高效、最大化的方式必定沒辦法經過人工來實現的。換句話說，只有經過自動化的方式去開發、運維應用以及與雲進行交互，才能真正把雲原生的價值發揮出來。

而若是要經過自動化的方式跟雲進行交互，那麼在雲原生生態裏，必須有一個相似於Controller 或者 Operator 這樣的插件的存在。今天阿里巴巴在雲上交付的 PolarDB、OceanBase 等，其實都有一個跟 Kubernetes 銜接的 Controller 的存在。經過 Controller 與基礎設施、雲進行交互，把雲的能力輸入到產品裏面去。

在將來，會有大量的雲上的應用和對應的運維能力、管理能力都會以 Kubernetes Operator 的方式交付。在這個背景下， Kubernetes 真正扮演的一個角色就是能力的接入層和標準界面。以下圖所示，這是一個很是典型的用戶側 Kubernetes 集羣的樣子。

一個用戶的 Kubernetes 只有紅框裏面這部分是 Kubernetes 原生提供的 API ，而大量的能力都是以插件化或者說 Operator 化的方式存在。就好比上圖右邊全部這些自定義的資源和能力所有來自於第三方開發，經過 Operator 這樣一個標準的形態開發出來的能力來服務最終用戶的。這就意味着在將來雲原生的生態裏面，基於 CRD Operator 的而非 Kubernetes 原生 API 的應用和能力會佔到絕大多數。

隨着這個趨勢的不斷演進，愈來愈多的軟件和能力經過 Kubernetes Operator 去描述和定義，雲產品也會開始默認以 Kubernetes 爲底座，基於 Operator 進行交付。

正是由於愈來愈多的 Operator 的出現，這裏就會逐步須要一箇中心化的方式去解決 Operator 潛在的穩定性、可發現性和性能問題，也就是說在將來極可能會有一個橫向的 Operator 管理平臺出現，對全部基於 Kubernetes Operator 開發的應用和能力進行統一管理，從而更好、更專業地服務用戶。

此外，因爲將來每個能力、每個應用都須要去編寫 Operator ，因此說對開發者友好的 Operator 編寫框架也是將來一個很重要的趨勢。這個編寫框架能夠支持不一樣語言，如 Go、Java、C、Rust 語言等，而且編寫過程是專一於運維邏輯和應用的管理、能力的管理，而不是專一在 Kubernetes 的語義和細節上面。

最後，隨着雲原生生態的普及，雲服務也將實現 Operator 化，而且面向多集羣/混合雲場景出現面向應用層的雲服務標準化定義與抽象，並在雲原生領域逐漸取代 IaC 項目（好比 Terraform 等）成爲雲服管理與消費的主流方式。 

應用中間件能力進一步下沉

隨着雲原生以及整個生態的發展，咱們看到應用中間件領域也隨之發生了不少改變。從原先最開始的中心化 ESB ，到後來的胖客戶端，逐步演化到今天咱們常常提到的 Service Mesh 這樣一種 Sidecar 化的方式。

其實今天你會發現，不管是雲的能力仍是基礎設施的能力，都在不斷豐富，不少原先只能經過中間件作的事情，如今能夠很容易經過雲服務來實現。應用中間件再也不是能力的提供方，而是能力接入的標準界面，而且這個標準界面的構建再也不基於胖客戶端，而是經過很是普通的 HTTP 協議、 gRPC 協議去作，而後經過 Sidecar 方式把整個服務的接入層跟應用業務邏輯作一個解耦，這其實就是 Service Mesh 的思想。

目前 Service Mesh 只作了傳統中間件裏面的流量治理、路由策略、訪問控制這一層的事情。而實際上， Sidecar 這個模型能夠應用到全部中間件的場景裏，實現中間件邏輯跟應用業務邏輯徹底解耦，讓應用中間件能力「下沉」，變成 Kubernetes 能力的一部分。這樣應用自己會更加專注化，更多的關注業務邏輯自己。

伴隨着這個趨勢，在 Kubernetes 這一層還會有另一個趨勢出現，就是 Sidecar 的自動化的、規模化的運維能力會成爲一個必選項。由於 Sidecar 的數量會極其龐大，應用中間件極可能會演化成 Sidecar 集羣，那麼這些 Sidecar 的管理和規模化的運維能力，會是集羣或者雲產品的一個必備選項。 

下一代 DevOps 模型與體系

隨着雲原生生態的不斷髮展，雲原生理念的不斷普及， DevOps 的思想極可能也會發生一個本質的變化，即下一代 DevOps 模型與體系。隨着 Kubernetes 的能力愈來愈多、愈來愈強大，基礎設施也會變得愈來愈複雜，那麼基於這樣一個強大的基礎設施去構建一個應用平臺就會很是簡單，而且這個應用平臺最終會取代傳統的PaaS平臺。

咱們如今之因此在用 DevOps 這一套思想，其實是因爲基礎設施自己不夠強大，不夠標準化，不夠好用，因此咱們須要在業務研發側作一套工具去黏合研發人員和基礎設施。例如，基礎設施提供的能力是一個虛擬機，怎麼能讓虛擬機變成研發側想要的藍綠髮布或者一個漸進式的應用交付系統呢？這就須要一系列的 DevOps 的工具、 CI/CD 的流水線來完成。

可是如今的狀況已經發生了變化。基於 Kubernetes 的基礎設施自己的能力已經很是豐富，像藍綠髮布這些能力自己就是 Kubernetes 能夠提供的能力。在這樣的背景下， DevOps 的發展趨勢也會發生很大的改變：

1. 關注點分離

在 Kubernetes 的背景下，「軟件」再也不是一個由應用 Owner 掌控的單一交付物，而是多個 Kubernetes 對象的集合，而這一堆 Kubernetes 裏面的對象只有不多一部分其實才跟研發有關，因此說有不少對象會不在應用 Owner 的認知範圍內，這就致使平臺必須去作關注點分離，研發側的關注點和運維側、系統側的關注點是徹底不同的東西。也就是研發不用再考慮運維方面的細節，好比藍綠髮布怎麼作，水平擴容什麼策略，只要把業務代碼寫完交付就好。

伴隨着 Kubernetes 和基礎設施愈來愈複雜，概念愈來愈多，做爲平臺層是不大可能讓研發瞭解全部的概念，所以將來雲原生生態必定會作抽象和分層。每一層的角色只跟屬於本身的數據抽象去交互，研發側有一套本身的聲明式 API 對象，運維側有一套本身的聲明式 API 對象，每一層的關注點也是不同的，這會是將來整個 DevOps 體系裏發展的一個重要的背景。

2. Serverless 泛化

雲原生自己的關注點就是應用，在這樣一個背景下，Serverless 自己再也不是一個獨立場景，再也不侷限在某幾個很是垂直的領域，而會變成雲原生應用管理體系的一種泛化思想和自然組成部分。我從兩個層面解釋一下：一是在能力側，「輕運維」「 NoOps 」以及「自助式運維能力」會成爲應用運維的主流方式。雲原生生態上的應用管理會體現出一種輕運維的狀態，就是說應用運維再也不是一我的工的、很是複雜的過程，而是一組開箱即用的、很是簡單的模塊化操做。不管是經過 Kubernetes 仍是經過雲原生能力，都是對下層基礎設施的一個模塊化的分裝，這跟 Serverless 所提倡的 NoOps 理念很是相似。

二是在應用側，應用描述會普遍地進行用戶側的抽象，事件驅動和 Serverless 理念被拆分和泛化，能夠被應用於多樣化的場景中而不只僅是今天狹義的 Serverless 場景好比 FaaS 或者 Container Instance，將來全部的應用均可以實現 scale-to-zero 。

3. 基於 Infrastructure as Data（IaD）思想的應用層技術漸成主流

第一，基於 Infrastructure as Data（IaD）的思想會成爲一個主流技術，IaD 實際就是 Kubernetes 的聲明式 API ，聲明式 API 的核心在於把基礎設施、應用、能力以一個聲明式的文件、聲明式的對象去描述，那麼這個文件或者對象自己就是「數據」。而 Kubernetes 或者基礎設施這一層是經過數據去驅動的，這就是 Infrastructure as Data。這樣的思想會延伸出不少技術和前沿的思想，好比 GitOps 、管道型 YAML 操做工具（Kustomize/kpt）等。這樣的管道型應用管理會成爲雲原生生態裏面一個很是主流的應用管理方式。

第二，聲明式應用定義模型（好比 OAM），以及聲明式的 CI/CD 系統和 Pipeline 會成爲一個新的應用交付的模式。好比傳統的 Jenkins 是一個命令式的組織方式，而隨着聲明式的 Pipeline 的出現，加上雲原生生態、Kubernetes 的普及，基於 Infrastructure as Data 思想的流水線和下一代的 CI/CD 系統也會成爲業界的主流。這跟之前的 CI/CD 和流水線有本質的區別，由於這個 CI/CD 系統裏面全部的操做都是一個聲明式描述。正由於是聲明式描述，全部這些操做以及 CI/CD 裏面的環節均可以託管到 Git 上，哪怕一我的工審覈（Manual Approve）這樣的動做均可以託管在 Git 裏面，經過 Git 去審計和作版本管理等。

Infrastructure as Data 的出現就是告訴咱們，將來雲原生的系統。一切皆對象，一切皆數據。隨着對象和數據愈來愈多，對他們的管理、審計、驗證等就變得愈來愈複雜，那麼圍繞它們的策略引擎（Policy Engine）會成爲一個很是重要的需求。策略引擎會成爲一個很是重要的組件，將來 Kubernetes 全部的應用平臺可能都須要一個策略引擎的存在，幫助用戶處理不一樣場景下對數據的操做策略。

4. 構建於 IaD 之上的最終用戶體驗層

須要注意的一點是，雖然 Infrastructure as Data 會成爲應用層的主流技術，可是它有一個「硬傷」，就是對最終用戶並不友好。由於人的大腦比較容易去處理流程化的、規則化的事情，而不是去處理一個靜態的數據，因此說在 IaD 之上會有一層面向最終用戶的體驗層的存在。這就意味着 Kubernetes 不會把聲明式的數據直接交給最終用戶，而是經過其餘方式來操做這些數據，好比經過一種可以理解 Kubernetes 數據模型的動態配置語言（DSL）來完成，或者經過基於 API 對象的 CLI 或者 dashboard 來完成，也多是經過一種以應用爲中心的交互與協做流程來完成。而最終用戶體驗層會決定產品有沒有黏性，這是雲原生的這套體系有沒有黏性，是否是用戶友好的一個關鍵環節。

5. DevSecOps

隨着如前所述的下一代 DevOps 體系的發展，安全會從一開始就變成應用交付的一部分。在業界你們稱之爲 DevSecOps ，就是從 day zero 開始就把安全策略、對安全的考量、安全配置做爲應用的一部分，而不是等到應用交付出去了甚至應用已經上線了再去作過後的安全審計和管理。

底層基礎設施的 Serverless 雲原生化

隨着雲原生體系的發展，雲的價值逐漸走向應用層，不斷向基於聲明式 API 、基於 IaD 的理念去發展，那麼下層的基礎設施也會發生相應的變化。第一個變化是基礎設施能力聲明式 API 化、自助化。今天的雲是基礎設施能力的集大成者，能夠認爲是一個無限的能力層，今天咱們能想象到的基礎設施上全部的能力，雲均可以提供，這跟之前的基礎設施徹底不同。之前雲的能力很薄弱，基礎設施的能力也很薄弱，因此才須要一個龐大的中間件體系和精密的 DevOps 體系來作一個「膠水層」，去彌補基礎設施跟應用、研發、運維人員之間的鴻溝。

而將來，應用纔是整個雲原生生態的主角。應用須要使用某個能力，那麼雲就會提供這個能力，而且是經過一個標準化的接入層來提供，而不是直接跟基礎設施打交道。雲原生生態的發展會使得用戶側的視角發生很大的改變，從面向基礎設施變爲面向應用，從基礎設施有什麼用戶才能用什麼，變成用戶要什麼，基礎設施就能夠提供什麼。以應用爲中心的基礎設施會是將來基礎設施的一個基本形態。

這個理念跟 Serverless 理念很是相似，咱們能夠將它稱爲底層基礎設施的 Serverless 原生化，這意味着基礎設施會在將來也逐漸的聲明式 API 化，而聲明式 API 化帶來的一個直接結果就是他會變成一個自助化的基礎設施。

另外，因爲基礎設施可以實現聲明式 API 化，實現自助化，那麼打造更加智能化的基礎設施就成爲一個重要方向。由於基礎設施系統的模塊化能力變成了一個數據化的定義方式，那麼就能夠和容易的經過監控數據、歷史數據來驅動基礎設施的運轉，也就是「自動駕駛的基礎設施」。數據驅動的智能化基礎設施會在將來成爲可能，固然其前提是基礎設施自己實現聲明式 API 化和自助化。

與此同時，因爲應用層自己會 Serverless 泛化，像 「scale to 0」 和 「pay as you go」 這些功能，會成爲應用的一個基礎的假設，致使資源層也會走向極致彈性+無限資源池的方向。做爲一個智能化的基礎設施，能夠去作更加智能的調度與混部，從而提供極致的資源利用效能，實現成本的極低化。

與此同時，因爲要實現極致的資源效能，就意味着底層必定是一個強多租架構，而且這個強多租架構是面向 Kubernetes 的，跟 Kubernetes 有一個自然的、很是融合的集成。這體如今兩個方面：第一，在運行時這一層，這個基礎設施會傾向走基於硬件虛擬化的容器運行時而非傳統虛擬機的方向，好比 Kata Container ，而且認爲神龍裸金屬服務器更適合作宿主機。伴隨着這套技術的發展，輕量化的 VMM（虛擬化管理技術）會成爲優化容器運行時、優化整個基礎設施敏捷度的一個關鍵技術和關鍵鏈路。

第二，強多租的控制面會針對不一樣租戶作物理隔離，而不僅是邏輯隔離，這是 Kubernetes 數據模型的要求，即租戶的控制面板之間須要有強的物理隔離，這就是爲何咱們講將來的強多租架構必定會面向 Kubernetes 來構建。阿里內部也是看到了這樣的趨勢，在不斷作一些嘗試，去更好地響應將來 Serverless 原生化的基礎設施的發展趨勢。

另外，咱們團隊正在招聘2021年畢業的應屆生，歡迎各位同窗加入咱們：

• 簡歷投遞：yaowei.cyw@alibaba-inc.com
• 郵件標題：雲原生-崗位名稱

詳情可點擊查看：https://mp.weixin.qq.com/s/aMGMme2-p296798wlGQQfQ。

「阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的公衆號。」