容器十年 ——一部軟件交付編年史

做者| 張磊，阿里雲容器平臺高級技術專家，CNCF Ambassador （CNCF 官方大使），Kubernetes 項目資深成員與維護者，曾就任於 Hyper、微軟研究院（MSR），如今負責 Kubernetes 技術及上下游相關工做。

2019年，全世界的開發人員都開始習慣用容器測試本身的軟件，用容器作線上發佈，開始對容器化的軟件構建和交付流程習覺得常。全世界的架構師們都在對「雲原生」侃侃而談，描繪多雲時代的應用治理方式，不經意間就把 「sidecar」 這種容器組織方式當作了默認選項。在「雲」已經成爲了大衆基礎設施的今天，咱們已經習慣了把「容器「當作現代軟件基礎設施的基本依賴。這就像咱們天天打開 Eclipse 編寫 Java 代碼同樣天然。

但往回倒數兩年， 整個容器生態都還在圍着 Docker 公司爭得不可開交，看起來徹底沒有定數。當時的國內不少公有云廠商，甚至都沒有正式的 Kubernetes 服務。在那個時候，要依託容器技術在雲上託管完整的軟件生命週期，能夠說是至關前沿的探索。誰能想到短短兩年以後，容器這個站在巨人肩膀上的設計，就真的成爲技術人員平常工做的一部分呢？

伴隨着容器技術普及到「千家萬戶」，咱們在這兩年期間所經歷的，是現代軟件交付形式的一次重要變革。

源起：屬於 Jails 們的時代

虛擬化容器技術（virtualized container）的歷史，其實能夠一直追溯上世紀 70 年代末。時間回到 1979 年，貝爾實驗室（ Bell Laboratories 正在爲 Unix V7 （Version 7 Unix）操做系統的發佈進行最後的開發和測試工做。

Ken Thompson(sitting) and Dennis Ritchie at PDP-11 ©wikipedia

在那個時候，Unix 操做系統仍是貝爾實驗室的內部項目，而運行 Unix 的機器則是長得像音響同樣的、名叫 PDP 系列的巨型盒子。在那個「軟件危機（The Software Crisis）」橫行的末期，開發和維護 Unix 這樣一套操做系統項目，即便對貝爾實驗室來講也絕非易事。更況且，那裏的程序員們還得一邊開發 Unix ，一邊開發 C 語言自己呢。

而在 Unix V7 的開發過程當中，系統級別軟件構建（Build）和測試（Test）的效率實際上是其中一個最爲棘手的難題。這裏的緣由也容易理解：當一個系統軟件編譯和安裝完成後，整個測試環境其實就被「污染」了。若是要進行下一次構建、安裝和測試，就必須從新搭建和配置整改測試環境。在有云計算能力的今天，咱們或許能夠經過虛擬機等方法來完整的復現一個集羣。但在那個一塊 64K 的內存條要賣 419 美圓的年代，「快速銷燬和重建基礎設施」的想法仍是有點「科幻」了。

因此，貝爾實驗室的聰明腦殼們開始構思一種在現有操做系統環境下「隔離」出一個可供軟件進行構建和測試的環境。更確切的說，就是我可否簡單的執行一些指令，就改變一個程序的「視圖」，讓它把當前目錄當作本身的根目錄呢？這樣，我每次只要在當前目錄裏放置一個完整操做系統文件系統部分，該軟件運行所需的全部依賴就完備了。

更爲重要的是，有了這個能力，開發者實際上就間接擁有了應用基礎設施「快速銷燬和重現」的能力，而不須要在環境搭好以後進入到環境裏去進行應用所需的依賴安裝和配置。這固然是由於，如今個人整個軟件運行的依賴，是以一個操做系統文件目錄的形式事先準備好的，而開發者只須要構建和測試應用的時候，切換應用「眼中」的根目錄到這個文件目錄便可。

因而，一個叫作 chroot（Change Root）的系統調用就此誕生了。

顧名思義，chroot 的做用是「重定向進程及其子進程的根目錄到一個文件系統上的新位置」，使得該進程再也看不到也無法接觸到這個位置上層的「世界」。因此這個被隔離出來的新環境就有一個很是形象的名字，叫作 Chroot Jail。

值得一提的是，這款孕育了 chroot 的 Unix V7 操做系統，成爲了貝爾實驗室 Unix 內部發行版的絕唱。在這一年底尾， Unix 操做系統正式被 AT&T 公司商業化，並被容許受權給外部使用，自此開啓了一代經典操做系統的傳奇之旅。

而 Chroot 的誕生，也第一次爲世人打開了「進程隔離」的大門。

伴隨着這種機被更普遍的用戶接觸到， chroot 也逐漸成爲了開發測試環境配置和應用依賴管理的一個重要工具。而 「Jail」 這個用來描述進程被隔離環境的概念，也開始激發出這個技術領域更多的靈感。

在 2000 年，同屬 Unix 家族的 FreeBSD 操做系統發佈了"jail"命令，
宣佈了 FreeBSD Jails 隔離環境的正式發佈。相比於 Chroot Jail，FreeBSD Jails 把」隔離「這個概念擴展到了進程的完整視圖，隔離出了獨立進程環境和用戶體系，併爲 Jails 環境分配了獨立的 IP 地址。因此確切的說，儘管 chroot 開創了進程環境隔離的思想，但 FreeBSD Jails，其實才真正實現了進程的沙箱化。而這裏的關鍵在於，這種沙箱的實現，依靠的是操做系統級別的隔離與限制能力而非硬件虛擬化技術。

不過，不管是 FreeBSD Jails（Unix 平臺），仍是緊接着出現的 Oracle Solaris Containers（Solaris 平臺），都沒有能在更普遍的軟件開發和交付場景中扮演到更重要的角色。在這段屬於 Jails 們的時代，進程沙箱技術由於「雲」的概念還沒有普及，始終被侷限在了小衆而有限的世界裏。

發展：雲，與應用容器

事實上，在 Jails 大行其道的這幾年間，一樣在迅速發展的 Linux 陣營上也陸續出現多個相似的沙箱技術好比 Linux VServer 和 Open VZ（未進入內核主幹）。但跟 Jails 的發展路徑比較相似，這些沙箱技術最後也都淪爲了小衆功能。咱們再次看到了，進程沙箱技術的發展過程當中「雲」的角色缺失所帶來的影響，其實仍是很是巨大的。而既然說到「雲」，咱們就不得不提到基礎設施領域的翹楚：Google。

Google 在雲計算背後最核心的基礎設施領域的強大影響力，是被業界公認的一個事實，不管是當初震驚世界的三大論文，仍是像 Borg/Omega 等領先業界多年的內部基礎設施項目，都在這個領域扮演者重要的啓迪者角色。然而，放眼當今的雲計算市場， 僅僅比 Google 雲計算髮布早一年多的 AWS 倒是「雲」這個產業毫無爭議的領導者。而往往談到這裏的緣由，你們都會提到一個充滿了爭議的項目：GAE。

GAE 對於中國的某幾代技術人員來講，能夠說是一個揮之不去的記憶。然而，即便是這批 GAE 的忠實用戶，恐怕也很難理解這個服務居然就是 Google 當年決定用來對抗 AWS 的核心雲產品了。事實上，GAE 自己與其說是 PaaS，倒不如說是簡化版的 Serverless。在 2008 年，在絕大多數人還徹底不知道雲計算爲什麼物的狀況下，這樣的產品要想取得成功拿下企業用戶，確實有些困難。

不過，在這裏咱們想要討論的並非 Google 的雲戰略，而是爲何從技術的角度上，Google 也認爲 GAE 這樣的應用託管服務就是雲計算呢？

這裏的一個重要緣由可能不少人都瞭解過，那就是 Google 的基礎設施技術棧實際上是一個標準容器技術棧，而不是一個虛擬機技術棧。更爲重要的是，在 Google 的這套體系下，得益於 Borg 項目提供的獨有的應用編排與管理能力，容器再也不是一個簡單的隔離進程的沙箱，而成爲了對應用自己的一種封裝方式。依託於這種輕量級的應用封裝，Google 的基礎設施能夠說是一個自然以應用爲中心的託管架構和編程框架，這也是不少前 Googler 調侃「離開了 Borg 都不知道怎麼寫代碼」的真實含義。這樣一種架構和形態，映射到外部的雲服務成爲 GAE 這樣的一個 PaaS/Serverless 產品，也就容易理解了。

而 Google 這套容器化基礎設施的規模化應用與成熟，能夠追溯到 2004~2007 年之間，而這其中一個最爲關鍵的節點，正是一種名叫 Process Container 技術的發佈。

Process Container 的目的很是直白，它但願可以像虛擬化技術那樣給進程提供操做系統級別的資源限制、優先級控制、資源審計能力和進程控制能力，這與前面提到的沙箱技術的目標實際上是一致的。這種能力，是前面提到的 Google 內部基礎設施得以實現的基本訴求和基礎依賴，同時也成爲了 Google 眼中「容器」技術的雛形。帶着這樣的設思路，Process Container 在 2006 年由 Google 的工程師正式推出後，第二年就進入了 Linux 內核主幹。

不過，因爲 Container 這個術語在 Linux 內核中另有它用，Process Container 在 Linux 中被正式更名叫做：Cgroups。Cgroups 技術的出現和成熟，標誌在 Linux 陣營中「容器」的概念開始被從新審視和實現。更重要的是，這一次「容器」這個概念的倡導者變成了 Google：一個正在大規模使用容器技術定義世界級基礎設施的開拓者。

在 2008 年，經過將 Cgroups 的資源管理能力和 Linux Namespace 的視圖隔離能力組合在一塊兒，LXC（Linux Container）這樣的完整的容器技術出如今了 Linux 內核當中。儘管 LXC 提供給用戶的能力跟前面提到的各類 Jails 以及 OpenVZ 等早期 Linux 沙箱技術是很是類似的，但伴隨着 Linux 操做系統開始迅速佔領商用服務器市場的契機，LXC 的境遇比前面的這些前輩要好上很多。

而更爲重要的是，2008 年以後 AWS ，Microsoft 等巨頭們持續不斷的開始在公有云市場上進行發力，很快就催生出了一個全新的、名叫 PaaS 的新興產業。

老牌雲計算廠商在 IaaS 層的先發優點以及這一部分的技術壁壘，使得愈來愈多受到公有云影響的技術廠商以及雲計算的後來者，開始思考如何在 IaaS 之上構建新的技術與商業價值，同時避免走入 GAE 當年的歧途。在這樣的背景之下，一批以開源和開放爲主要特色的平臺級項目應運而生，將 「PaaS」 這個本來虛無縹緲的概念第一次實現和落地。這些 PaaS 項目的定位是應用託管服務，而不一樣於 GAE 等公有云託管服務 ，這些開放 PaaS 項目但願構建的則是徹底獨立於 IaaS 層的一套應用管理生態，目標是藉助 PaaS 離開發者足夠近的優點鎖定雲乃至全部數據中心的更上層入口。這樣的定位，實際上就意味着 PaaS 項目必須可以不依賴 IaaS 層虛擬機技術，就可以將用戶提交的應用進行封裝，而後快速的部署到下層基礎設施上。而這其中，開源、中立，同時又輕量、敏捷的 Linux 容器技術，天然就成爲了 PaaS 進行託管和部署應用的最佳選擇。

在 2009 年，VMware 公司在收購了 SpringSource 公司（Spring 框架的創始公司）以後，將 SpringSource 內部的一個 Java PaaS 項目的名字，套在了本身的一個內部 PaaS 頭上，而後於 2011 年宣佈了這個項目的開源。這個項目的名字，就叫作：Cloud Foundry。2009年，Cloud Foundry 項目的誕生，第一次對 PaaS 的概念完成了清晰而完整的定義。

這其中，「PaaS 項目經過對應用的直接管理、編排和調度讓開發者專一於業務邏輯而非基礎設施」，以及「PaaS 項目經過容器技術來封裝和啓動應用」等理念，也第一次出如今雲計算產業當中並獲得承認。值得一提的是，Cloud Foundry 用來操做和啓動容器的項目叫作：Warden，它最開始是一個 LXC 的封裝，後來重構成了直接對 Cgroups 以及 Linux Namespace 操做的架構。

Cloud Foundry 等 PaaS 項目的逐漸流行，與當初 Google 發佈 GAE 的初衷是徹底同樣的。說到底，這些服務都認爲應用的開發者不該該關注於虛擬機等底層基礎設施，而應該專一在編寫業務邏輯這件最有價值的事情上。這個理念，在愈來愈多的人得以經過雲的普及開始感覺到管理基礎設施的複雜性和高成本以後，才變得愈來愈有說服力。在這幅藍圖中，Linux 容器已經跳出了進程沙箱的侷限性，開始扮演的「應用容器」的角色。在這個新的舞臺上， 容器和應用終於畫上了等號，這才最終使得平臺層系統可以實現應用的全生命週期託管。

按照這個劇本，容器技術以及雲計算的發展，理應向着 PaaS 的和以應用爲中心的方向繼續演進下去。若是不是有一家叫作 Docker 的公司出現的話。

容器：改寫的軟件交付的歷程

若是不是親歷者的話，你很難想象 PaaS 乃至雲計算產業的發展，會如何由於 2013 年一個創業公司開源項目的發佈而被完全改變。但這件事情自己，確實是過去 5 年間整個雲計算產業變革的真實縮影。

Docker 項目的發佈，以及它與 PaaS 的關係，想必咱們已經無需在作贅述。一個「降維打擊」，就足以給當初業界的爭論不休畫上一個乾淨利落的句號。

咱們都知道， Docker 項目發佈時，無非也是 LXC 的一個使用者，它建立和使用應用容器的邏輯跟 Warden 等沒有本質不一樣。不過，咱們如今也知道，真正讓 PaaS 項目無所適從的，是 Docker 項目最厲害的殺手鐗：容器鏡像。

關於如何封裝應用，這自己不是開發者所關心的事情，因此 PaaS 項目有着無數的發揮空間。但到這如何定義應用這個問題，就是跟每一位技術人員息息相關了。在那個時候，Cloud Foundry 給出的方法是 Buildpack，它是一個應用可運行文件（好比 WAR 包）的封裝，而後在裏面內置了 Cloud Foundry 能夠識別的啓動和中止腳本，以及配置信息。

然而，Docker 項目經過容器鏡像，直接將一個應用運行所需的完整環境，即：整個操做系統的文件系統也打包了進去。這種思路，可算是解決了困擾 PaaS 用戶已久的一致性問題，製做一個「一次發佈、隨處運行」的 Docker 鏡像的意義，一會兒就比製做一個連開發和測試環境都沒法統一的 Buildpack 高明瞭太多。

更爲重要的是，Docker 項目還在容器鏡像的製做上引入了「層」的概念，這種基於「層」（也就是「commit」 ) 進行 build，push，update 的思路，顯然是借鑑了 Git 的思想。因此這個作法的好處也跟 Github 一模一樣：製做 Docker 鏡像再也不是一個枯燥而乏味的事情，由於經過 DockerHub 這樣的鏡像託管倉庫，你和你的軟件馬上就能夠參與到全世界軟件分發的流程當中。

至此，你就應該明白，Docker 項目實際上解決的確實是一個更高維度的問題：軟件究竟應該經過什麼樣的方式進行交付？更重要的是，一旦當軟件的交付方式定義的如此清晰而且完備的時候，利用這個定義在去作一個託管軟件的平臺好比 PaaS，就變得很是簡單而明瞭了。這也是爲何 Docker 項目會屢次表示本身只是「站在巨人肩膀上」的根本緣由：沒有最近十年 Linux 容器等技術的提出與完善，要經過一個開源項目來定義而且統一軟件的交付歷程，恐怕如癡人說夢。

雲，應用，與雲原生

時至今日，容器鏡像已經成爲了現代軟件交付與分發的事實標準。然而， Docker 公司卻並無在這個領域取得一樣的領導地位。這裏的緣由相比你們已經瞭然於心：在容器技術取得巨大的成功以後，Docker 公司在接下來的「編排之爭」中犯下了錯誤。事實上，Docker 公司憑藉「容器鏡像」這個巧妙的創新已經成功解決了「應用交付」所面臨的最關鍵的技術問題。但在如何定義和管理應用這個更爲上層的問題上，容器技術並非「銀彈」。在「應用」這個與開發者息息相關的領域裏，歷來就少不了複雜性和靈活性的訴求，而容器技術又自然要求應用的「微服務化」和「單一職責化」，這對於絕大多數真實企業用戶來講都是很是困難的。而這部分用戶，又恰恰是雲計算產業的關鍵所在。

而相比於 Docker 體系以「單一容器」爲核心的應用定義方式，Kubernetes 項目則提出了一整套容器化設計模式和對應的控制模型，從而明確瞭如何真正以容器爲核心構建可以真正跟開發者對接起來的應用交付和開發範式。而 Docker 公司、Mesosphere 公司 以及 Kubernetes 項目在「應用」這一層上的不一樣理解和頂層設計，其實就是所謂「編排之爭」的核心所在。

2017 年底，Google 在過去十年編織全世界最早進的容器化基礎設施的經驗，最終幫助 Kubernetes 項目取獲得了關鍵的領導地位，並將 CNCF 這個以「雲原生」爲關鍵詞的組織和生態推向了巔峯。

而最爲有意思的是， Google 公司在 Kubernetes 項目傾其全力注入的「靈魂」，既不是 Borg/Omega 多年來積累下來的大規模調度與資源管理能力，也不是「三大論文」這樣讓當年業界可望不可即的領先科技。Kubernetes 項目裏最能體現 Google 容器理念的設計，是「源自 Borg/Omega 體系的應用編排與管理能力」。

咱們知道，Kubernetes 是一個「重 API 層」 的項目，但咱們還應該理解的是，Kubernetes 是一個「以 API 爲中心」的項目。圍繞着這套聲明式 API，Kubernetes 的容器設計模式，控制器模型，以及異常複雜的 apiserver 實現與擴展機制纔有了意義。而這些看似繁雜的設計與實現背後，實際上只服務於一個目的，那就是：如何讓用戶在管理應用的時候能最大程度的發揮容器和雲的價值。

本着這個目的，Kubernetes 纔會把容器進行組合，用 Pod 的概念來模擬進程組的行爲。纔會堅持用聲明式 API 加控制器模型來進行應用編排，用 API 資源對象的建立與更新（PATCH）來驅動整個系統的持續運轉。更確切的說，有了 Pod 和容器設計模式，咱們的應用基礎設施纔可以與應用（而不是容器）進行交互和響應的能力，實現了「雲」與「應用」的直接對接。而有了聲明式 API，咱們的應用基礎而設施才能真正同下層資源、調度、編排、網絡、存儲等雲的細節與邏輯解耦。咱們如今，能夠把這些設計稱爲「雲原生的應用管理思想」，這是咱們「讓開發者專一於業務邏輯」、「最大程度發揮雲的價值」的關鍵路徑。

因此說，Kubernetes 項目一直在作的，實際上是在進一步清晰和明確「應用交付」這個亙古不變的話題。只不過，相比於交付一個容器和容器鏡像， Kubernetes 項目正在嘗試明確的定義雲時代「應用」的概念。在這裏，應用是一組容器的有機組合，同時也包括了應用運行所需的網絡、存儲的需求的描述。而像這樣一個「描述」應用的 YAML 文件，放在 etcd 裏存起來，而後經過控制器模型驅動整個基礎設施的狀態不斷地向用戶聲明的狀態逼近，就是 Kubernetes 的核心工做原理了。

將來：應用交付的革命不會中止

說到這裏，咱們已經回到了 2019 年這個軟件交付已經被 Kubernetes 和容器從新定義的時間點。

在這個時間點上，Kubernetes 項目正在繼續嘗試將應用的定義、管理和交付推向一個全新的高度。咱們其實已經看到了現有模型的一些問題與不足之處，尤爲是聲明式 API 如何更好的與用戶的體驗達成一致。在這個事情上，Kubernetes 項目還有很多路要走，但也在快速前行。

咱們也可以看到，整個雲計算生態正在嘗試從新思考 PaaS 的故事。Google Cloud Next 2019 上發佈的 Cloud Run，其實已經間接宣告了 GAE 正憑藉 Kubernetes 和 Knative 的標準 API 「浴火重生」。而另外一個典型的例子，則是愈來愈多不少應用被更「極端」的抽象成了 Function，以便徹底託管於與基礎設施無關的環境（FaaS）中。若是說容器是完整的應用環境封裝從而將應用交付的自由交還給開發者，那麼 Function 則是剝離了應用與環境的關係，將應用交付的權利交給了 FaaS 平臺。咱們不難看到，雲計算在向 PaaS 的發展過程當中被 Docker 「攪局」以後，又開始帶着「容器」這個全新的思路向 「PaaS」 不斷收斂。只不過這一次，PaaS 可能會換一個新的名字叫作：Serverless。

咱們還可以看到，雲的邊界正在被技術和開源迅速的抹平。愈來愈多的軟件和框架從設計上就再也不會跟某雲產生直接綁定。畢竟，你沒辦法撫平用戶對商業競爭擔心和焦慮，也不可能阻止愈來愈多的用戶把 Kubernetes 部署在全世界的全部雲上和數據中內心。咱們經常把雲比做「水、電、煤」，並勸誡開發者不該該關心「發電」和「燒煤」的事情。但實際上，開發者不只不關心這些事情，他們恐怕連「水、電、煤」是哪來的都不想知道。在將來的雲的世界裏，開發者徹底無差異的交付本身的應用到世界任何一個地方，頗有可能會像如今咱們會把電腦插頭插在房間裏任何一個插孔裏那樣天然。這也是爲何，咱們看到愈來愈多的開發者在討論「雲原生」。

咱們沒法預見將來，但代碼與技術演進的正在告訴咱們這樣一個事實：將來的軟件必定是生長於雲上的。這將會是「軟件交付」這個本質問題的不斷自我革命的終極走向，也是「雲原生」理念的最核心假設。而所謂「雲原生」，實際上就是在定義一條可以讓應用最大程度利用雲的能力、發揮雲的價值的最佳路徑。在這條路徑上，脫離了「應用」這個載體，「雲原生」就無從談起；容器技術，則是將這個理念落地、將軟件交付的革命持續進行下去的重要手段之一。

而至於 Kubernetes 項目，它的確是整個「雲原生」理念落地的核心與關鍵所在。但更爲重要的是，在此次關於「軟件」的技術革命中，Kubernetes 並不須要嘗試在 PaaS 領域裏分到一杯羹：它會成爲連通「雲」與「應用」的高速公路，以標準、高效的方式將「應用」快速交付到世界上任何一個位置。而這裏的交付目的地，既能夠是最終用戶，也能夠是 PaaS/Serverless 從而催生出更加多樣化的應用託管生態。「雲」的價值，必定會迴歸到應用自己。

一塊兒進入雲原生架構時代

在雲的趨勢下，愈來愈多的企業開始將業務與技術向「雲原生」演進。這個過程當中最爲艱難的挑戰其實來自於如何將應用和軟件向 Kubernetes 體系進行遷移、交付和持續發佈。而在此次技術變革的浪潮中，」雲原生應用交付「，已經成爲了 2019 年雲計算市場上最熱門的技術關鍵詞之一。

阿里巴巴從 2011 年開始經過容器實踐雲原生技術體系，在整個業界都尚未任何範例可供參考的大背境下，逐漸摸索出了一套比肩全球一線技術公司而且服務於整個阿里集團的容器化基礎設施架構。在這些數以萬計的集羣管理經驗當中，阿里容器平臺團隊探索並總結了四個讓交付更加智能與標準化的方法： Everything on Kubernetes，利用 K8s 來管理一切，包括 K8s 自身； 應用發佈回滾策略，按規則進行灰度發佈，固然也包括髮布 kubelet 自己；將環境進行鏡像切分，分爲模擬環境和生產環境；而且在監控側下足功夫，將Kubernetes 變得更白盒化和透明化，及早發現問題、預防問題、解決問題。

而近期，阿里雲容器平臺團隊也官宣了兩個社區項目：Cloud Native App Hub —— 面向全部開發者的 Kubernetes 應用管理中心，OpenKruise —— 源自全球頂級互聯網場景的 Kubernetes 自動化開源項目集。

OpenKruise 開源地址：https://github.com/openkruise/kruise

Cloud Native App Hub：https://developer.aliyun.com/hub

雲原生應用中心（Cloud Native App Hub），它首先爲國內開發者提供了一個 Helm 應用中國鏡像站，方便用戶得到雲原生應用資源，同時推動標準化應用打包格式，並能夠一鍵將應用交付到K8s 集羣當中，大大簡化了面向多集羣交付雲原生應用的步驟；而OpenKruise/Kruise 項目致力於成爲「雲原生應用自動化引擎」，解決大規模應用場景下的諸多運維痛點。OpenKruise 項目源自於阿里巴巴經濟體過去多年的大規模應用部署、發佈與管理的最佳實踐，從不一樣維度解決了 Kubernetes 之上應用的自動化問題，包括部署、升級、彈性擴縮容、QoS 調節、健康檢查，遷移修復等等。

在接下來，阿里雲容器平臺團隊還會以此爲基礎，繼續同整個生態一塊兒推動雲原生應用定義、K8s CRD 與 Operator 編程範式、加強型 K8s 自動化插件等一系列可以讓雲原生應用在規模化多集羣場景下實現快速交付、更新和部署等技術的標準化與社區化。

咱們期待與您一塊兒共建，共同體迎接雲原生時代的來臨！

---

本文做者：jessie筱姜

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。