作者 | 李響、張磊 Kubernetes 本身并不直接產(chǎn)生商業(yè)價值，你不會花錢去購買 Kubernetes 。這就跟安卓一樣，你不會直接掏錢去買一個安卓系統(tǒng)。Kubernetes 真正產(chǎn)生價值的地方也在于它的上層應(yīng)用生態(tài)。 

“未來的軟件一定是生長于云上的”**，這是云原生理念的最核心假設(shè)。而所謂“云原生”，實際上就是在定義一條能夠讓應(yīng)用最大程度利用云的能力、發(fā)揮云的價值的最佳路徑。因此，云原生其實是一套指導(dǎo)軟件架構(gòu)設(shè)計的思想。按照這樣的思想而設(shè)計出來的軟件：首先，天然就“生在云上，長在云上”；其次，能夠最大化地發(fā)揮云的能力，使得我們開發(fā)的軟件和“云”能夠天然地集成在一起，發(fā)揮出“云”的最大價值。 云原生的概念大家并不陌生，很多企業(yè)也已經(jīng)基于云原生的架構(gòu)和技術(shù)理念落地相關(guān)實踐。那么，這么多企業(yè)和開發(fā)者熱衷和推崇的云原生，未來的發(fā)展趨勢如何？如何才能順應(yīng)云原生的主流方向去發(fā)展？  

我們邀請到阿里云資深技術(shù)專家、CNCF 技術(shù)監(jiān)督委員會代表，etcd 作者**李響**和阿里云高級技術(shù)專家、CNCF 應(yīng)用交付領(lǐng)域 co-chair **張磊**分享云原生的理念、發(fā)展以及未來趨勢，為大家打開新的思路和眼界。 以下內(nèi)容共享給大家。 # Kubernetes 項目的安卓化 云原生里有一個非常關(guān)鍵的項目，就是 Kubernetes。Kubernetes 的發(fā)展非常迅速，它是整個云原生體系發(fā)展的基石。今天我們來觀察 Kubernetes 項目的發(fā)展特點，

首先，Kubernetes 無處不在，無論是在云上，還是用戶自建的數(shù)據(jù)中心里，甚至一些我們想象不到的場景里，都有 Kubernetes 的存在。 

第二，所有云原生的用戶使用 Kubernetes 的目的，都是為了交付和管理應(yīng)用。當(dāng)然這個應(yīng)用是一個泛化的概念，可以是一個網(wǎng)站，也可以是淘寶這樣非常龐大的電商主站，或者是 AI 作業(yè)、計算任務(wù)、函數(shù)、甚至虛擬機等，這些都是用戶可以使用 Kubernetes 去交付和管理的應(yīng)用類型。 

第三，今天我們來看 Kubernetes 所處的位置，實際上是承上啟下。Kubernetes 對上暴露基礎(chǔ)設(shè)施能力的格式化數(shù)據(jù)抽象，比如 Service、Ingress、Pod、Deployment，這些都是 Kubernetes 本身原生 API 給用戶暴露出來的能力。而對下，Kubernetes 提供的是基礎(chǔ)設(shè)施能力接入的標(biāo)準(zhǔn)接口，比如說 CNI、CSI、DevicePlugin、CRD，讓云能夠作為一個能力提供商，以一個標(biāo)準(zhǔn)化的方式把能力接入到 Kubernetes 的體系中。 這一點其實跟安卓非常類似，安卓雖然裝在你的設(shè)備里，但是它能夠讓你的硬件、手機、電視、汽車等都能接入到一個平臺里。對上則暴露統(tǒng)一的一套應(yīng)用管理接口，讓你能夠基于安卓系統(tǒng)來編寫應(yīng)用，去訪問或者享受到這些基礎(chǔ)設(shè)施能力，這也是 Kubernetes 和安卓的相似之處。 最后， Kubernetes 本身并不直接產(chǎn)生商業(yè)價值，你不會花錢去購買 Kubernetes。

這就跟安卓一樣，你不會直接掏錢去買一個安卓系統(tǒng)。Kubernetes 真正產(chǎn)生價值的地方也在于它的上層應(yīng)用生態(tài)。對安卓來說，它今天已經(jīng)具備了一個龐大的移動端或設(shè)備端應(yīng)用的開發(fā)生態(tài)，而對于 Kubernetes 來說也是類似的，只不過現(xiàn)在還在于比較早的階段。但我們已經(jīng)能夠看到，今天在 Kubernetes 上構(gòu)建的商業(yè)層很多是垂直解決方案，是面向用戶、面向應(yīng)用這一側(cè)真正能夠產(chǎn)生商業(yè)價值的東西，而不是 Kubernetes 本身這一層。這就是為什么我說 Kubernetes 發(fā)展跟安卓很像，當(dāng)然這可能也是谷歌比較擅長的一個“打法”：全力地去免費推廣一個“操作系統(tǒng)”，真正獲取商業(yè)價值的方式則是是去“收割”操作系統(tǒng)上層的生態(tài)價值而不是操作系統(tǒng)本身。 

基于這些現(xiàn)象，我們將 Kubernetes 的發(fā)展趨勢概括為以下幾點： ## 1. 云的價值回歸到應(yīng)用本身 用戶使用 Kubernetes 的本質(zhì)目的是去交付和管理應(yīng)用。從這個現(xiàn)象來看，如果 Kubernetes 發(fā)展下去，那么世界上所有的數(shù)據(jù)中心和基礎(chǔ)設(shè)施上面都會有一層 Kubernetes ，自然而然用戶就會開始以 Kubernetes 為基礎(chǔ)去編寫和交付以及管理其應(yīng)用，就跟現(xiàn)在我們會以安卓這樣一個操作系統(tǒng)為基礎(chǔ)去編寫移動應(yīng)用是類似的。 這就會導(dǎo)致云上的大多數(shù)軟件和云產(chǎn)品都是第三方開發(fā)的。第三方開發(fā)是指所有人都可以面向一個標(biāo)準(zhǔn)界面去開發(fā)和交付軟件，這個軟件本身既可以是自己的軟件，也可以是一個云產(chǎn)品。

未來，越來越多的第三方開源項目，如 MongoDB、Elasticsearch 等，都會以云原生理念去開發(fā)、部署和運維，最后直接演進成為一種云服務(wù)。 ## 2. 云端“豌豆莢”的出現(xiàn) 有了 Kubernetes 這樣一個標(biāo)準(zhǔn)，開發(fā)者面對的就是一個類似于操作系統(tǒng)的界面。由于有更多的應(yīng)用是面向 Kubernetes 誕生的，或者說面向 Kubernetes 去交付的，那么就需要有一個類似于“豌豆莢”的產(chǎn)品，來作為云上的應(yīng)用商店或者云上的應(yīng)用分發(fā)系統(tǒng)，它的關(guān)鍵能力在于把應(yīng)用無差別地交付給全世界任何一個 Kubernetes 上面，就跟用豌豆莢把任何一個安卓應(yīng)用交付在任何一個安卓設(shè)備上的原理是一樣的。 其實今天谷歌已經(jīng)在做這類產(chǎn)品的嘗試了，比如 Anthos （面向混合云的應(yīng)用交付平臺），雖然是一款混合云產(chǎn)品，但它本質(zhì)上是把谷歌云的服務(wù)，比如數(shù)據(jù)庫服務(wù)、大數(shù)據(jù)服務(wù)，去直接交付于任何一個基于 Kubernetes 的混合云環(huán)境里面去，其實就相當(dāng)于一款云端的“豌豆莢”。 

 3. 基于 Kubernetes 可擴展能力的開放應(yīng)用平臺會取代 PaaS 成為主流 由于未來整個應(yīng)用生態(tài)會面向 Kubernetes 去構(gòu)建，那么基于 Kubernetes 可擴展能力的開放應(yīng)用平臺會逐漸取代傳統(tǒng) PaaS 而成為主流?；?Kubernetes 可擴展能力去構(gòu)建一個開放的應(yīng)用平臺，其能力是可插拔的，能夠去交付和管理的應(yīng)用類型是多樣化的，這才更符合 Kubernetes 所構(gòu)建的趨勢和生態(tài)，所以一些真正高可擴展的平臺層項目會大量產(chǎn)生。 另外，今天我們看到的 Kubernetes ，跟“理想”中的云原生應(yīng)用生態(tài)之間其實還有很多路要走，這也是阿里云原生團隊一直在做的事情，基于 Kubernetes 在應(yīng)用層構(gòu)建更豐富的應(yīng)用生態(tài)，幫助用戶實現(xiàn)多樣化的需求。 

 應(yīng)用與能力的“ Operator 化” 縱觀云原生時代應(yīng)用或者云的能力的發(fā)展方向，你會發(fā)現(xiàn)另一個趨勢，就是 Operator 化。Operator 是 Kubernetes 的一個概念，是指 Kubernetes 交付的一個實體，這個實體有一個基礎(chǔ)模型存在，這個模型分為兩部分：一部分是 Kubernetes 的 API 對象（CRD），另一部分是一個控制器（Controller），如下圖所示： 這里要區(qū)分兩個概念，自定義和自動化。很多人會說 Operator 可以幫助我做自定義，因為很多人都會覺得 Kubernetes 內(nèi)置的能力是不夠用的，所以用戶會利用它的可擴展能力去寫一個 Controller ，從而實現(xiàn)跟多自定義的需求。但自定義只是 Operator 中很小的一部分價值，我們今天對應(yīng)用和能力做 Operator 化的核心動力在于其實是為了實現(xiàn)自動化，而且只有自動化了，我們才能講云原生。 這是因為，云原生帶來的最大的紅利是可以讓我們最大限度、最高效地使用云的能力，二這種最高效、最大化的方式一定沒辦法通過人工來實現(xiàn)的。換句話說，只有通過自動化的方式去開發(fā)、運維應(yīng)用以及與云進行交互，才能真正把云原生的價值發(fā)揮出來。 而如果要通過自動化的方式跟云進行交互，那么在云原生生態(tài)里，必須有一個類似于Controller 或者 Operator 這樣的插件的存在。今天阿里巴巴在云上交付的 PolarDB、OceanBase 等，其實都有一個跟 Kubernetes 銜接的 Controller 的存在。通過 Controller 與基礎(chǔ)設(shè)施、云進行交互，把云的能力輸入到產(chǎn)品里面去。 

在未來，會有大量的云上的應(yīng)用和對應(yīng)的運維能力、管理能力都會以 Kubernetes Operator 的方式交付。在這個背景下， Kubernetes 真正扮演的一個角色就是能力的接入層和標(biāo)準(zhǔn)界面。如下圖所示，這是一個非常典型的用戶側(cè) Kubernetes 集群的樣子。 一個用戶的 Kubernetes 只有紅框里面這部分是 Kubernetes 原生提供的 API ，而大量的能力都是以插件化或者說 Operator 化的方式存在。就比如上圖右邊所有這些自定義的資源和能力全部來自于第三方開發(fā)，通過 Operator 這樣一個標(biāo)準(zhǔn)的形態(tài)開發(fā)出來的能力來服務(wù)最終用戶的。這就意味著在未來云原生的生態(tài)里面，基于 CRD Operator 的而非 Kubernetes 原生 API 的應(yīng)用和能力會占到絕大多數(shù)。

 隨著這個趨勢的不斷演進，越來越多的軟件和能力通過 Kubernetes Operator 去描述和定義，云產(chǎn)品也會開始默認(rèn)以 Kubernetes 為底座，基于 Operator 進行交付。 正是因為越來越多的 Operator 的出現(xiàn)，這里就會逐步需要一個中心化的方式去解決 Operator 潛在的穩(wěn)定性、可發(fā)現(xiàn)性和性能問題，也就是說在未來很可能會有一個橫向的 Operator 管理平臺出現(xiàn)，對所有基于 Kubernetes Operator 開發(fā)的應(yīng)用和能力進行統(tǒng)一管理，從而更好、更專業(yè)地服務(wù)用戶。

 此外，由于未來每一個能力、每一個應(yīng)用都需要去編寫 Operator ，所以說對開發(fā)者友好的 Operator 編寫框架也是未來一個很重要的趨勢。這個編寫框架可以支持不同語言，如 Go、Java、C、Rust 語言等，并且編寫過程是專注于運維邏輯和應(yīng)用的管理、能力的管理，而不是專注在 Kubernetes 的語義和細節(jié)上面。 

最后，隨著云原生生態(tài)的普及，云服務(wù)也將實現(xiàn) Operator 化，并且面向多集群/混合云場景出現(xiàn)面向應(yīng)用層的云服務(wù)標(biāo)準(zhǔn)化定義與抽象，并在云原生領(lǐng)域逐漸取代 IaC 項目（比如 Terraform 等）成為云服管理與消費的主流方式。  

 應(yīng)用中間件能力進一步下沉 隨著云原生以及整個生態(tài)的發(fā)展，我們看到應(yīng)用中間件領(lǐng)域也隨之發(fā)生了很多改變。從原先最開始的中心化 ESB ，到后來的胖客戶端，逐步演化到今天我們經(jīng)常提到的 Service Mesh 這樣一種 Sidecar 化的方式。 其實今天你會發(fā)現(xiàn)，無論是云的能力還是基礎(chǔ)設(shè)施的能力，都在不斷豐富，很多原先只能通過中間件做的事情，現(xiàn)在可以很容易通過云服務(wù)來實現(xiàn)。應(yīng)用中間件不再是能力的提供方，而是能力接入的標(biāo)準(zhǔn)界面，并且這個標(biāo)準(zhǔn)界面的構(gòu)建不再基于胖客戶端，而是通過非常普通的 HTTP 協(xié)議、 gRPC 協(xié)議去做，然后通過 Sidecar 方式把整個服務(wù)的接入層跟應(yīng)用業(yè)務(wù)邏輯做一個解耦，這其實就是 Service Mesh 的思想。 目前 Service Mesh 只做了傳統(tǒng)中間件里面的流量治理、路由策略、訪問控制這一層的事情。

而實際上， Sidecar 這個模型可以應(yīng)用到所有中間件的場景里，實現(xiàn)中間件邏輯跟應(yīng)用業(yè)務(wù)邏輯完全解耦，讓應(yīng)用中間件能力“下沉”，變成 Kubernetes 能力的一部分。這樣應(yīng)用本身會更加專一化，更多的關(guān)注業(yè)務(wù)邏輯本身。 

伴隨著這個趨勢，在 Kubernetes 這一層還會有另外一個趨勢出現(xiàn)，就是 Sidecar 的自動化的、規(guī)?；倪\維能力會成為一個必選項。因為 Sidecar 的數(shù)量會極其龐大，應(yīng)用中間件很可能會演化成 Sidecar 集群，那么這些 Sidecar 的管理和規(guī)模化的運維能力，會是集群或者云產(chǎn)品的一個必備選項。  

下一代 DevOps 模型與體系 隨著云原生生態(tài)的不斷發(fā)展，云原生理念的不斷普及， DevOps 的思想很可能也會發(fā)生一個本質(zhì)的變化，即下一代 DevOps 模型與體系。隨著 Kubernetes 的能力越來越多、越來越強大，基礎(chǔ)設(shè)施也會變得越來越復(fù)雜，那么基于這樣一個強大的基礎(chǔ)設(shè)施去構(gòu)建一個應(yīng)用平臺就會非常簡單，并且這個應(yīng)用平臺最終會取代傳統(tǒng)的PaaS平臺。 我們現(xiàn)在之所以在用 DevOps 這一套思想，實際上是由于基礎(chǔ)設(shè)施本身不夠強大，不夠標(biāo)準(zhǔn)化，不夠好用，所以我們需要在業(yè)務(wù)研發(fā)側(cè)做一套工具去黏合研發(fā)人員和基礎(chǔ)設(shè)施。例如，基礎(chǔ)設(shè)施提供的能力是一個虛擬機，怎么能讓虛擬機變成研發(fā)側(cè)想要的藍綠發(fā)布或者一個漸進式的應(yīng)用交付系統(tǒng)呢？這就需要一系列的 DevOps 的工具、 CI/CD 的流水線來完成。 但是現(xiàn)在的情況已經(jīng)發(fā)生了變化?；?Kubernetes 的基礎(chǔ)設(shè)施本身的能力已經(jīng)非常豐富，像藍綠發(fā)布這些能力本身就是 Kubernetes 可以提供的能力。在這樣的背景下， DevOps 的發(fā)展趨勢也會發(fā)生很大的改變： 

 1. 關(guān)注點分離 在 Kubernetes 的背景下，“軟件”不再是一個由應(yīng)用 Owner 掌控的單一交付物，而是多個 Kubernetes 對象的集合，而這一堆 Kubernetes 里面的對象只有很少一部分其實才跟研發(fā)有關(guān)，所以說有很多對象會不在應(yīng)用 Owner 的認(rèn)知范圍內(nèi)，這就導(dǎo)致平臺必須去做關(guān)注點分離，研發(fā)側(cè)的關(guān)注點和運維側(cè)、系統(tǒng)側(cè)的關(guān)注點是完全不一樣的東西。也就是研發(fā)不用再考慮運維方面的細節(jié)，比如藍綠發(fā)布怎么做，水平擴容什么策略，只要把業(yè)務(wù)代碼寫完交付就好。 伴隨著 Kubernetes 和基礎(chǔ)設(shè)施越來越復(fù)雜，概念越來越多，作為平臺層是不大可能讓研發(fā)了解所有的概念，因此未來云原生生態(tài)一定會做抽象和分層。每一層的角色只跟屬于自己的數(shù)據(jù)抽象去交互，研發(fā)側(cè)有一套自己的聲明式 API 對象，運維側(cè)有一套自己的聲明式 API 對象，每一層的關(guān)注點也是不一樣的，這會是未來整個 DevOps 體系里發(fā)展的一個重要的背景。 

2. Serverless 泛化 云原生本身的關(guān)注點就是應(yīng)用，在這樣一個背景下，Serverless 本身不再是一個獨立場景，不再局限在某幾個非常垂直的領(lǐng)域，而會變成云原生應(yīng)用管理體系的一種泛化思想和天然組成部分。我從兩個層面解釋一下：一是在能力側(cè)，“輕運維”“ NoOps ”以及“自助式運維能力”會成為應(yīng)用運維的主流方式。云原生生態(tài)上的應(yīng)用管理會體現(xiàn)出一種輕運維的狀態(tài)，就是說應(yīng)用運維不再是一個人工的、非常復(fù)雜的過程，而是一組開箱即用的、非常簡單的模塊化操作。無論是通過 Kubernetes 還是通過云原生能力，都是對下層基礎(chǔ)設(shè)施的一個模塊化的分裝，這跟 Serverless 所提倡的 NoOps 理念非常類似。 二是在應(yīng)用側(cè)，應(yīng)用描述會廣泛地進行用戶側(cè)的抽象，事件驅(qū)動和 Serverless 理念被拆分和泛化，可以被應(yīng)用于多樣化的場景中而不僅僅是今天狹義的 Serverless 場景比如 FaaS 或者 Container Instance，未來所有的應(yīng)用都可以實現(xiàn) scale-to-zero 。 

3. 基于 Infrastructure as Data（IaD）思想的應(yīng)用層技術(shù)漸成主流 第一，基于 Infrastructure as Data（IaD）的思想會成為一個主流技術(shù)，IaD 實際就是 Kubernetes 的聲明式 API ，聲明式 API 的核心在于把基礎(chǔ)設(shè)施、應(yīng)用、能力以一個聲明式的文件、聲明式的對象去描述，那么這個文件或者對象本身就是“數(shù)據(jù)”。而 Kubernetes 或者基礎(chǔ)設(shè)施這一層是通過數(shù)據(jù)去驅(qū)動的，這就是 Infrastructure as Data。這樣的思想會延伸出很多技術(shù)和前沿的思想，比如 GitOps 、管道型 YAML 操作工具（Kustomize/kpt）等。這樣的管道型應(yīng)用管理會成為云原生生態(tài)里面一個非常主流的應(yīng)用管理方式。 

第二，聲明式應(yīng)用定義模型（比如 OAM），以及聲明式的 CI/CD 系統(tǒng)和 Pipeline 會成為一個新的應(yīng)用交付的模式。比如傳統(tǒng)的 Jenkins 是一個命令式的組織方式，而隨著聲明式的 Pipeline 的出現(xiàn)，加上云原生生態(tài)、Kubernetes 的普及，基于 Infrastructure as Data 思想的流水線和下一代的 CI/CD 系統(tǒng)也會成為業(yè)界的主流。這跟以前的 CI/CD 和流水線有本質(zhì)的區(qū)別，因為這個 CI/CD 系統(tǒng)里面所有的操作都是一個聲明式描述。

正因為是聲明式描述，所有這些操作以及 CI/CD 里面的環(huán)節(jié)都可以托管到 Git 上，哪怕一個人工審核（Manual Approve）這樣的動作都可以托管在 Git 里面，通過 Git 去審計和做版本管理等。 Infrastructure as Data 的出現(xiàn)就是告訴我們，未來云原生的系統(tǒng)。一切皆對象，一切皆數(shù)據(jù)。隨著對象和數(shù)據(jù)越來越多，對他們的管理、審計、驗證等就變得越來越復(fù)雜，那么圍繞它們的策略引擎（Policy Engine）會成為一個非常重要的需求。策略引擎會成為一個非常重要的組件，未來 Kubernetes 所有的應(yīng)用平臺可能都需要一個策略引擎的存在，幫助用戶處理不同場景下對數(shù)據(jù)的操作策略。 

4. 構(gòu)建于 IaD 之上的最終用戶體驗層 需要注意的一點是，雖然 Infrastructure as Data 會成為應(yīng)用層的主流技術(shù)，但是它有一個“硬傷”，就是對最終用戶并不友好。因為人的大腦比較容易去處理流程化的、規(guī)則化的事情，而不是去處理一個靜態(tài)的數(shù)據(jù)，所以說在 IaD 之上會有一層面向最終用戶的體驗層的存在。這就意味著 Kubernetes 不會把聲明式的數(shù)據(jù)直接交給最終用戶，而是通過其他方式來操作這些數(shù)據(jù)，比如通過一種能夠理解 Kubernetes 數(shù)據(jù)模型的動態(tài)配置語言（DSL）來完成，或者通過基于 API 對象的 CLI 或者 dashboard 來完成，也可能是通過一種以應(yīng)用為中心的交互與協(xié)作流程來完成。而最終用戶體驗層會決定產(chǎn)品有沒有黏性，這是云原生的這套體系有沒有黏性，是不是用戶友好的一個關(guān)鍵環(huán)節(jié)。 

5. DevSecOps 隨著如前所述的下一代 DevOps 體系的發(fā)展，安全會從一開始就變成應(yīng)用交付的一部分。在業(yè)界大家稱之為 DevSecOps ，就是從 day zero 開始就把安全策略、對安全的考量、安全配置作為應(yīng)用的一部分，而不是等到應(yīng)用交付出去了甚至應(yīng)用已經(jīng)上線了再去做事后的安全審計和管理。 

底層基礎(chǔ)設(shè)施的 Serverless 云原生化 隨著云原生體系的發(fā)展，云的價值逐漸走向應(yīng)用層，不斷向基于聲明式 API 、基于 IaD 的理念去發(fā)展，那么下層的基礎(chǔ)設(shè)施也會發(fā)生相應(yīng)的變化。第一個變化是基礎(chǔ)設(shè)施能力聲明式 API 化、自助化。今天的云是基礎(chǔ)設(shè)施能力的集大成者，可以認(rèn)為是一個無限的能力層，今天我們能想象到的基礎(chǔ)設(shè)施上所有的能力，云都可以提供，這跟以前的基礎(chǔ)設(shè)施完全不一樣。以前云的能力很薄弱，基礎(chǔ)設(shè)施的能力也很薄弱，所以才需要一個龐大的中間件體系和精密的 DevOps 體系來做一個“膠水層”，去彌補基礎(chǔ)設(shè)施跟應(yīng)用、研發(fā)、運維人員之間的鴻溝。 

而未來，應(yīng)用才是整個云原生生態(tài)的主角。應(yīng)用需要使用某個能力，那么云就會提供這個能力，并且是通過一個標(biāo)準(zhǔn)化的接入層來提供，而不是直接跟基礎(chǔ)設(shè)施打交道。云原生生態(tài)的發(fā)展會使得用戶側(cè)的視角發(fā)生很大的改變，從面向基礎(chǔ)設(shè)施變?yōu)槊嫦驊?yīng)用，從基礎(chǔ)設(shè)施有什么用戶才能用什么，變成用戶要什么，基礎(chǔ)設(shè)施就可以提供什么。以應(yīng)用為中心的基礎(chǔ)設(shè)施會是未來基礎(chǔ)設(shè)施的一個基本形態(tài)。 這個理念跟 Serverless 理念非常類似，我們可以將它稱為底層基礎(chǔ)設(shè)施的 Serverless 原生化，這意味著基礎(chǔ)設(shè)施會在未來也逐漸的聲明式 API 化，而聲明式 API 化帶來的一個直接結(jié)果就是他會變成一個自助化的基礎(chǔ)設(shè)施。

 另外，由于基礎(chǔ)設(shè)施能夠?qū)崿F(xiàn)聲明式 API 化，實現(xiàn)自助化，那么打造更加智能化的基礎(chǔ)設(shè)施就成為一個重要方向。因為基礎(chǔ)設(shè)施系統(tǒng)的模塊化能力變成了一個數(shù)據(jù)化的定義方式，那么就可以和容易的通過監(jiān)控數(shù)據(jù)、歷史數(shù)據(jù)來驅(qū)動基礎(chǔ)設(shè)施的運轉(zhuǎn)，也就是“自動駕駛的基礎(chǔ)設(shè)施”。數(shù)據(jù)驅(qū)動的智能化基礎(chǔ)設(shè)施會在未來成為可能，當(dāng)然其前提是基礎(chǔ)設(shè)施本身實現(xiàn)聲明式 API 化和自助化。 與此同時，由于應(yīng)用層本身會 Serverless 泛化，像 “scale to 0” 和 “pay as you go” 這些功能，會成為應(yīng)用的一個基礎(chǔ)的假設(shè)，導(dǎo)致資源層也會走向極致彈性+無限資源池的方向。

作為一個智能化的基礎(chǔ)設(shè)施，可以去做更加智能的調(diào)度與混部，從而提供極致的資源利用效能，實現(xiàn)成本的極低化。 與此同時，由于要實現(xiàn)極致的資源效能，就意味著底層一定是一個強多租架構(gòu)，并且這個強多租架構(gòu)是面向 Kubernetes 的，跟 Kubernetes 有一個天然的、非常融合的集成。這體現(xiàn)在兩個方面：第一，在運行時這一層，這個基礎(chǔ)設(shè)施會傾向走基于硬件虛擬化的容器運行時而非傳統(tǒng)虛擬機的方向，比如 Kata Container ，并且認(rèn)為神龍裸金屬服務(wù)器更適合做宿主機。伴隨著這套技術(shù)的發(fā)展，輕量化的 VMM（虛擬化管理技術(shù)）會成為優(yōu)化容器運行時、優(yōu)化整個基礎(chǔ)設(shè)施敏捷度的一個關(guān)鍵技術(shù)和關(guān)鍵鏈路。 第二，強多租的控制面會針對不同租戶做物理隔離，而不只是邏輯隔離，這是 Kubernetes 數(shù)據(jù)模型的要求，即租戶的控制面板之間需要有強的物理隔離，這就是為什么我們講未來的強多租架構(gòu)一定會面向 Kubernetes 來構(gòu)建。阿里內(nèi)部也是看到了這樣的趨勢，在不斷做一些嘗試，去更好地響應(yīng)未來 Serverless 原生化的基礎(chǔ)設(shè)施的發(fā)展趨勢。