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

張磊

阿里雲容器平臺高階技術專家、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 開源地址

Cloud Native App Hub
https://developer.aliyun.com/hub
雲原生應用中心（Cloud Native App Hub），它首先為國內開發者提供了一個 Helm 應用中國映象站，方便使用者獲得雲原生應用資源，同時推進標準化應用打包格式，並可以一鍵將應用交付到K8s 叢集當中，大大簡化了面向多叢集交付雲原生應用的步驟；而OpenKruise/Kruise 專案致力於成為“雲原生應用自動化引擎”，解決大規模應用場景下的諸多運維痛點。OpenKruise 專案源自於阿里巴巴經濟體過去多年的大規模應用部署、釋出與管理的最佳實踐，從不同維度解決了 Kubernetes 之上應用的自動化問題，包括部署、升級、彈性擴縮容、QoS 調節、健康檢查，遷移修復等等。
在接下來，阿里雲容器平臺團隊還會以此為基礎，繼續同整個生態一起推進雲原生應用定義、K8s CRD 與 Operator 程式設計正規化、增強型 K8s 自動化外掛等一系列能夠讓雲原生應用在規模化多叢集場景下實現快速交付、更新和部署等技術的標準化與社群化。
我們期待與您一起共建，共同體迎接雲原生時代的來臨！