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

作者 | 李響、張磊

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），如下圖所示：

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

這裡要區分兩個概念，自定義和自動化。很多人會說 Operator 可以幫助我做自定義，因為很多人都會覺得 Kubernetes 內建的能力是不夠用的，所以使用者會利用它的可擴充套件能力去寫一個 Controller ，從而實現跟多自定義的需求。但自定義只是 Operator 中很小的一部分價值，我們今天對應用和能力做 Operator 化的核心動力在於其實是為了實現自動化，而且只有自動化了，我們才能講雲原生。

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

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

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

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

一個使用者的 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 化的方式。

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

其實今天你會發現，無論是雲的能力還是基礎設施的能力，都在不斷豐富，很多原先只能透過中介軟體做的事情，現在可以很容易透過雲服務來實現。應用中介軟體不再是能力的提供方，而是能力接入的標準介面，並且這個標準介面的構建不再基於胖客戶端，而是透過非常普通的 HTTP 協議、 gRPC 協議去做，然後透過 Sidecar 方式把整個服務的接入層跟應用業務邏輯做一個解耦，這其實就是 Service Mesh 的思想。

目前 Service Mesh 只做了傳統中介軟體裡面的流量治理、路由策略、訪問控制這一層的事情。而實際上， Sidecar 這個模型可以應用到所有中介軟體的場景裡，實現中介軟體邏輯跟應用業務邏輯完全解耦，讓應用中介軟體能力“下沉”，變成 Kubernetes 能力的一部分。這樣應用本身會更加專一化，更多的關注業務邏輯本身。

伴隨著這個趨勢，在 Kubernetes 這一層還會有另外一個趨勢出現，就是 Sidecar 的自動化的、規模化的運維能力會成為一個必選項。因為 Sidecar 的數量會極其龐大，應用中介軟體很可能會演化成 Sidecar 叢集，那麼這些 Sidecar 的管理和規模化的運維能力，會是叢集或者雲產品的一個必備選項。

# 下一代 DevOps 模型與體系

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

我們現在之所以在用 DevOps 這一套思想，實際上是由於基礎設施本身不夠強大，不夠標準化，不夠好用，所以我們需要在業務研發側做一套工具去黏合研發人員和基礎設施。例如，基礎設施提供的能力是一個虛擬機器，怎麼能讓虛擬機器變成研發側想要的藍綠髮布或者一個漸進式的應用交付系統呢？這就需要一系列的 DevOps 的工具、 CI/CD 的流水線來完成。

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

但是現在的情況已經發生了變化。基於 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 體系來做一個“膠水層”，去彌補基礎設施跟應用、研發、運維人員之間的鴻溝。

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

![5.png](https://ucc.alicdn.com/pic/developer-ecology/8ed0c11130434445b22388a198c22b3c.png)

這個理念跟 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](https://mp.weixin.qq.com/s/aMGMme2-p296798wlGQQfQ)。

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247491754&idx=2&sn=d99ac17dbec045a6333aad258e561ed2&chksm=fae6eb65cd9162735a6b175a0d53a0858bf3c74f134579e21581cde0faf0bbb5d48432a4424f&token=513817799&lang=zh_CN#rd)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

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

相關文章