作者 |?李響、張磊

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 等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的公眾號。”

原文鏈接

本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的云原生五大趋势预测，K8s安卓化位列其一的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。