簡介：Kubernetes 本身并不直接產生商業價值，你不會花錢去購買 Kubernetes 。這就跟安卓一樣，你不會直接掏錢去買一個安卓系統。Kubernetes 真正產生價值的地方也在于它的上層應用生態。

“未來的軟件一定是生長于云上的”，這是云原生理念的最核心假設。而所謂“云原生”，實際上就是在定義一條能夠讓應用最大程度利用云的能力、發揮云的價值的最佳路徑。因此，云原生其實是一套指導軟件架構設計的思想。按照這樣的思想而設計出來的軟件：首先，天然就“生在云上，長在云上”；其次，能夠最大化地發揮云的能力，使得我們開發的軟件和“云”能夠天然地集成在一起，發揮出“云”的最大價值。

云原生的概念大家并不陌生，很多企業也已經基于云原生的架構和技術理念落地相關實踐。那么，這么多企業和開發者熱衷和推崇的云原生，未來的發展趨勢如何？如何才能順應云原生的主流方向去發展？怎么在云原生時代“乘風破浪”？

我們邀請到阿里云原生資深技術專家、CNCF技術監督委員會代表，etcd作者李響和阿里云高級技術專家、CNCF 應用交付領域聯席主席張磊分享云原生的理念、發展以及未來趨勢，為大家打開新的思路和眼界。

以下內容共享給大家。

一、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原生化的基礎設施的發展趨勢。

云計算的下一站，就是云原生；IT架構的下一站，就是云原生架構，這是屬于所有開發者最好的時代。阿里云將于7月上線《云原生架構白皮書》，助力所有的開發者、架構師和技術決策者們，共同定義云原生，擁抱云原生。

原文鏈接：https://developer.aliyun.com/article/767047?

版權聲明：本文中所有內容均屬于阿里云開發者社區所有，任何媒體、網站或個人未經阿里云開發者社區協議授權不得轉載、鏈接、轉貼或以其他方式復制發布/發表。申請授權請郵件developerteam@list.alibaba-inc.com，已獲得阿里云開發者社區協議授權的媒體、網站，在轉載使用時必須注明"稿件來源：阿里云開發者社區，原文作者姓名"，違者本社區將依法追究責任。 如果您發現本社區中有涉嫌抄襲的內容，歡迎發送郵件至：developer2020@service.aliyun.com 進行舉報，并提供相關證據，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

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

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