導讀：本文描述了阿里巴巴在容器管理領域的技術演進歷程憨栽，解讀了為什么 K8s 最終能夠大獲成功的原因，以及到今年 雙11 阿里巴巴內部的 K8s 應用情況床玻。內容著重描述了阿里巴巴基于 K8s 的云原生改造實踐過程的三大能力升級毁涉，在對應能力升級過程中沉淀的技術解決方案，以及通過這些能力升級所取得的業(yè)務價值锈死。

從 2015 年 Google 牽頭成立 CNCF 以來贫堰，云原生技術開始進入公眾的視線并取得快速的發(fā)展，到 2018 年包括 Google待牵、AWS其屏、Azure、Alibaba Cloud 等大型云計算供應商都加入了 CNCF缨该，云原生技術也從原來的應用容器化發(fā)展出包括容器偎行、Service Mesh、微服務贰拿、不可變基礎設施蛤袒、Serverless、FaaS 等眾多技術方向膨更，CFCF 旗下也囊括了越來多的開源項目妙真。

Kubernetes 作為 CNCF 的第一個項目從誕生之初就就令人矚目，Kubernetes 由 Google 工程師基于 Google 內部多年集群管理系統(tǒng) Borg 的設計經驗询一，結合云計算時代的基礎設施特點重新設計而得隐孽，旨在幫助企業(yè)解決大規(guī)模 IT 基礎設施的應用容器編排難題。

Google 在 2014 年 6 月開源 Kubernetes 以后健蕊，在 Redhat菱阵、Microsoft、Alibaba 等廠商和眾多開源愛好者共同的努力下缩功，成長為如今容器編排領域的事實標準晴及，極大的推動了云原生領域的發(fā)展。

今天為大家分享來自阿里云的 Kubernetes 大規(guī)模實踐經驗嫡锌，展現(xiàn)阿里云如何基于 Kubernetes 推動阿里巴巴應用運維技術棧走向云原生虑稼，如何推動 Kubernetes自身的技術進步，充分挖掘云原生時代的紅利助力阿里巴巴大幅降低 雙11 的 IT 成本势木。

容器在阿里巴巴的發(fā)展歷程

在 2011 年之前蛛倦，阿里巴巴使用 VM 虛擬化技術將一個物理機切分為 3 個虛擬機，用于部署淘寶服務啦桌，而隨著淘寶業(yè)務的飛速發(fā)展溯壶，基于 VM 的技術方案在靈活性上跟不上業(yè)務的步伐及皂。

因此，阿里巴巴在 2011 年就開始探索基于 Linux lxc 的容器技術且改，用于替代傳統(tǒng)基于 VM 的應用部署方案验烧，到 2013 年，研發(fā)了基于 Linux lxc 的 T4 容器和 AI 容器編排系統(tǒng)又跛。這在當時已是非常領先的技術方案碍拆，但自己研發(fā)的容器技術與基于 VM 時代的運維系統(tǒng)始終存在一些兼容性問題。

在 2013 年隨著 Docker 容器鏡像方案的出現(xiàn)慨蓝，阿里巴巴技術人員立即看到了基于容器 + Docker 鏡像技術的未來感混，開始大力投入到這一領域的研究當中，到 2015 年 Aliswarm菌仁、Zeus浩习、Hippo 等容器編排系統(tǒng)蓬勃發(fā)展，各自開疆擴土服務了阿里巴巴經濟體的一部分業(yè)務济丘。諸多的系統(tǒng)在解決了業(yè)務運維成本的同時，也帶來了一定的重復建設成本洽蛀，同時也導致了阿里巴巴內部的資源分布比較分散摹迷，無法統(tǒng)一調度多樣的業(yè)務類型發(fā)揮出不同業(yè)務錯峰使用資源的優(yōu)勢。

正是在這樣的背景下郊供，Sigma 系統(tǒng)應運而出并在 2017 年統(tǒng)一了阿里巴巴的資源池峡碉，統(tǒng)一調度阿里巴巴所有的核心業(yè)務，并第一次支持將在線服務與離線作業(yè)運行在同一個物理機上驮审，大幅提高數據中心的資源利用效率并降低了阿里巴巴的 IT 成本鲫寄。

隨著云原生技術的高速發(fā)展，阿里巴巴也看到了云原生技術的潛力疯淫，以及未來企業(yè) IT 全面上云的必然趨勢地来，從 2018 年開始轉型到 Kubernetes 技術，通過 Kubernetes 擴展能力將Sigma 積累多年的調度能力通過 Kubernetes 的方式提供出來熙掺。

在 2019 年阿里巴巴宣布全面上云未斑，阿里巴巴開始全面擁抱 Kubernetes，并將 Sigma 調度系統(tǒng)全面的遷移到基于 Kubernetes 的調度系統(tǒng)币绩，該系統(tǒng)也正是支持了今年最大規(guī)模 雙11 電商交易系統(tǒng)的底層基礎設施蜡秽，穩(wěn)定的支持了大促前后數百次的應用變更并提供極速的應用發(fā)布與擴容體驗，為 雙11 的順暢的購物體驗立下汗馬功勞缆镣。

為什么 K8s 在阿里能成功

Kubernetes 在眾多的技術中脫穎而出芽突，概括起來可以歸納為以下三個方面。

首先是其在誕生之初就為云時代而生董瞻，擁有超前的眼光和先進的設計理念寞蚌，加之最初由天才的 Google 工程師基于其內部 Borg 多年的經驗設計而來，誕生之后就飛速發(fā)展；

后來隨著 RedHat睬澡、IBM固额、微軟、Vmware煞聪、阿里云等來自全球的優(yōu)秀工程師大力投入斗躏，打造了繁榮的社區(qū)和生態(tài)系統(tǒng)，成為企業(yè)容器編排系統(tǒng)的首選昔脯。

阿里巴巴經濟體擁有眾多的子公司啄糙，這些子公司在加入阿里巴巴大家庭時或多或少都會有一套自有的容器編排系統(tǒng)，在融入阿里巴巴的基礎設施過程中云稚，Kubernetes 是最標準也最容易被經濟體內外的客戶所接受的一個方案隧饼。

其次，Kubernetes 倡導的申明式 API 的設計理念静陈，也貼合了阿里巴巴在應用運維領域的經驗與教訓燕雁；

傳統(tǒng)的運維系統(tǒng)通常是基于過程式的設計，而過程式的運維系統(tǒng)在較長的系統(tǒng)調用鏈路下鲸拥，通常會出現(xiàn)因異常處理復雜而導致的系統(tǒng)效率低下拐格。

在大規(guī)模應用運維系統(tǒng)中復雜又繁多的狀態(tài)處理也是一個大難題，基于過程式的系統(tǒng)設計很難確保系統(tǒng)的一致性刑赶，針對這些邊界異常的處理通常又導致運維系統(tǒng)變得非常復雜捏浊，最終為異常兜底的只能依賴運維人員的人工操作∽策叮基本上可以認為基于過程式的運維系統(tǒng)難以應對超大規(guī)模的應用管理金踪，而 Kubernetes 提供的申明式 API 卻是解決應用運維狀態(tài)輪轉的一劑良藥，是提高運維技術棧整體鏈路效率的最佳實踐原則牵敷。

第三胡岔，Kubernetes 模塊化、可擴展的架構設計劣领，滿足阿里巴巴的定制化改造以支持眾多業(yè)務運維場景的需求姐军。

在阿里巴巴內部，即有大量的無狀態(tài)核心電商系統(tǒng)尖淘，也有大量的緩存奕锌、消息隊列等中間件有狀態(tài)系統(tǒng)，也包括大量帶有倒排索引數據的檢索系統(tǒng)村生，還有大量的 AI 計算任務惊暴，不同的應用類型對底層容器管理平臺的要求也有所不同。

因此趁桃，一個模塊化方便嵌入自定義應用管理策略辽话、易于擴展調度模型的設計顯得至關重要肄鸽，是能夠服務阿里內部眾多應用形態(tài)、提供統(tǒng)一容器管理基礎設施的關鍵油啤，Kubernetes 基本上提供了這些關鍵基礎能力典徘，雖然在實際應用過程中仍然會遇到非常多的實際問題。

阿里巴巴的 K8s 應用情況

在 2019 年 雙11益咬，阿里巴巴內部核心業(yè)務主要運行在神龍逮诲、ECS知残、ECI 三種資源類型的基礎設施之上吆鹤，而這些不同類型的基礎設施資源均通過 Kubernetes 統(tǒng)一管理列林，以容器的形態(tài)提供給上層應用使用司训，完成了核心業(yè)務的支撐。

有別于以往的 雙11铺董，今年核心電商業(yè)務應用大規(guī)模部署在神龍裸金屬服務器上遣铝。如果有關注過阿里云技術的發(fā)展爬橡，應該不會對神龍服務器感到陌生冻河，它是阿里云自主研發(fā)的新一代云服務器箍邮，通過“軟硬一體”的技術開創(chuàng)性的將云計算的虛擬化開銷分攤到低價硬件板卡上，徹底的釋放 CPU 的計算能力芋绸，第一次真正的做到了云計算虛擬化的“零”開銷媒殉。

容器也是一種輕量級的虛擬化方案，神龍+容器+Kubernetes 的結合正是云原生時代的最佳拍檔摔敛，支撐了今年最大規(guī)模的 雙11，也將是未來的主流技術形態(tài)全封。

阿里巴巴也在繼續(xù)使用 ECS 作為 Kubernetes 的底層資源供給马昙，ECS 作為傳統(tǒng)的云計算虛擬化方式支撐了部門集團內部業(yè)務，同時結合靈活性更好的彈性容器實例 ECI 用于應對業(yè)務突發(fā)的流量峰值刹悴，為業(yè)務帶來了云計算的彈性價值行楞，真正實現(xiàn)了按需申請、釋放資源的極致彈性能力土匀，降低了業(yè)務需要提前規(guī)劃資源所帶來的成本子房。

這些分布在海內外的數十萬個節(jié)點的資源，被數十個 Kubernetes 集群托管就轧，運行著阿里巴巴上萬個應用证杭，共計超過百萬的容器，其規(guī)模之大前所未有妒御。在今年的 雙11 中解愤，阿里巴巴內部最大的 Kubernetes 集群規(guī)模達到萬級；當然這并不是Kubernetes 的技術極限乎莉，而是我們考慮數據中心資源效率與基礎設施容災能力之間所取的平衡送讲，在將來如果有需要這個數字也可能變得更大奸笤。

基于 K8s 的云原生改造實踐

Kubernetes 作為云原生技術的代表，已經成為了容器編排領域的事實標準哼鬓，阿里巴巴自 2017 年開始探索监右，到 2018 年確認技術轉型到使用 Kubernetes 來管理生產的容器。

在落地 K8s 的過程中异希，我們主要面臨著兩大難題：

其一健盒，上層多樣的業(yè)務運維平臺；

為了支撐阿里巴巴內部多樣的業(yè)務形態(tài)宠互，在內部發(fā)展出來了多個典型的業(yè)務運維平臺味榛，每一個運維平臺的基礎設施、流程控制予跌、應用發(fā)布策或多或少都會存在一些差別搏色，缺少一個統(tǒng)一的應用運維標準。在調度與集群管理的技術演進過程中券册，如何牽引整個運維體系升級的同時并保持多個業(yè)務的平臺及其上業(yè)務的穩(wěn)定性频轿，這是一個巨大的工程。

其二烁焙，隨著阿里巴巴經濟體全面上云戰(zhàn)略的實施航邢，整個底層基礎設施包括存儲、網絡骄蝇、基礎運維軟件的技術演進也非常迅速膳殷。調度與集群管理需要在支持好基礎設施快速演進的同時，迭代自身的技術架構九火，并同時保證業(yè)務的穩(wěn)定性赚窃。

基于 K8s 的云原生技術改造正是在這樣的背景下誕生，發(fā)展到 2019 年 Kubernetes 在內部已大規(guī)模部署岔激，所有的核心業(yè)務也都已經運行在 K8s 集群管理中勒极。但在這幾年的實踐過程中，有一個問題始終縈繞在工程師頭腦中虑鼎，在阿里巴巴這么大體量辱匿、這么復雜的業(yè)務下，遺留了大量傳統(tǒng)的運維習慣以及支撐這些習慣的運維體系炫彩，在這樣的背景下落地Kubernetes （內部一個形象的比喻叫做給高速飛行的飛機更換發(fā)動機）到底是在堅持什么匾七，哪些地方可以妥協(xié)，哪些地方必須改變媒楼？

這一章節(jié)乐尊， 將為大家分享我們這幾年對這個問題的一些思考，特別是經過了今年的 雙11 考驗后划址，這個問題的答案基本上得到了工程師群里的集體認可扔嵌。

負責頂層設計的架構師終于可以喘一口氣：擁抱 Kubernetes 本身并不是目的限府，而通過擁抱 Kubernetes 撬動業(yè)務的云原生改造，通過 Kubernetes 的能力治理傳統(tǒng)運維體系下的沉埃頑疾痢缎，真正釋放云的彈性能力胁勺，為業(yè)務的應用交付解綁提速，才是這次技術變革的最大價值所在独旷。

面向終態(tài)升級

在傳統(tǒng)的運維體系下署穗，應用的變更都是運維通過創(chuàng)建操作工單發(fā)起工作流，繼而對容器平臺發(fā)起一個個的變更來完成的嵌洼。比如升級一個服務器的 3000 個實例案疲，工單會被提前計算并生成出多個批次的子任務，并逐個的調用容器平臺的接口完成變更應用的變更麻养。

為了確保應用發(fā)布工單的順利執(zhí)行褐啡，在每一個子工單內部，每一個容器的發(fā)布也是一個工作流鳖昌，包括監(jiān)控開關备畦、鏡像拉取、容器啟停许昨、服務注冊懂盐、配置推送等等，如果一切正常該流程會按預期有序的進行糕档。

在大規(guī)模應用發(fā)布的場景中莉恼，諸如宿主機宕機、磁盤異常速那、IO 異常类垫、網絡異常、內核異常等幾乎是必然存在的琅坡，如果發(fā)布流程中的某一個步驟出現(xiàn)了錯誤，通常情況下需要運維平臺按照一定的策略來重試残家，直到超過該批次的超時閾值榆俺，這將會帶來三個問題，下面逐一展開坞淮。

其一是重試帶來的效率問題茴晋；

每一個子任務的執(zhí)行時間將被任務內的長尾發(fā)布所拖累，假設將 3000 個容器分為 30 批次每批 100 個（僅為示意并非最佳實踐）回窘，每一批次內出現(xiàn)一個容器發(fā)布異常時诺擅，該批次的發(fā)布時間將被重試拉長。

其二是失敗帶來的一致性問題啡直；

對于發(fā)布異常的容器烁涌，在工單結束之后通常只能通過外圍鏈路巡檢的方式來治理苍碟，而事實上通常的巡檢是依賴運維人員手工操作的，帶來了極大的人工成本和不確定性撮执。

第三是應用并發(fā)變更沖突問題微峰。

如果在應用發(fā)布的過程中，同時提交了應用擴容的請求抒钱，由 3000 擴容到 3200 個實例蜓肆，擴容的 200 個實例應該采用舊版本還是新版本，采用舊版本擴容將面臨的問題是誰最終負責這 200 個舊版本實例的升級谋币，采用新版本擴容將面臨的是穩(wěn)定性問題仗扬，如果新版本存在問題新擴容的實例將產生較大的影響。

正是因為這些復雜的問題導致多數運維系統(tǒng)拒絕了并發(fā)的應用變更蕾额，導致并發(fā)操作效率非常低下早芭。

K8s 為應用管理所提供的申明式 API 的設計理念同時解決了解決了這三個問題，用戶只需要描述期望的最終狀態(tài)以及達成期望狀態(tài)的過程中需要遵守的限制條件凡简，達成終態(tài)所需要執(zhí)行的復雜操作全部交由 K8s 的來完成逼友。

在應用發(fā)布過程中，通常情況下 K8s 通過控制并發(fā)度及最大不可用實例數來約束應用發(fā)布對服務的影響秤涩，對于發(fā)布過程中失敗的實例通過最終一致的方式在系統(tǒng)內部解決帜乞。正是基于這一設計，用戶發(fā)起服務變更時只是更新了應用的預期狀態(tài)筐眷，并不需要等待任何任務的結束黎烈，一并解決了應用發(fā)布效率、線上配置的一致性和并發(fā)變更沖突效率的問題匀谣。

基于面向終態(tài)的理念管理應用照棋，我們開發(fā) Advanced StatefulSet 的應用管理工作模型，顧名思義它基于 Kubernetes 官方的 StatefulSet 擴展而來武翎。

在官方的工作模型中烈炭，應用通過滾動的方式完成版本升級，也就是創(chuàng)建新的 Pod 同時刪除舊版本的 Pod宝恶，直到整個應用切換為新的版本符隙。

這種方式簡單直接，但存在效率的問題垫毙，比如所有應用的 Pod 需要重新的調度霹疫，這在大規(guī)模應用發(fā)布場景將給調度器帶來很大的壓力；同時综芥，因為新版本 Pod 為全新創(chuàng)建丽蝎，需要重新分配 IP 并掛載遠程卷，這對云計算網絡膀藐、存儲基礎設施也將是很大的挑戰(zhàn)屠阻；再者红省，因為容器是被全新調度出來的，在機器上需要重新下載新的應用鏡像栏笆，這將大幅降低應用發(fā)布的效率类腮。

為了提高應用發(fā)布的效率和資源的確定性，開發(fā)了這一工作負載模型蛉加，它支持原地發(fā)布應用蚜枢，應用發(fā)布前后應用所在的位置保持不變，同時支持了并發(fā)更新针饥、容錯暫停等豐富的發(fā)布策略厂抽，高效的滿足了阿里巴巴內部電商應用的發(fā)布需求。因為應用發(fā)布前后位置不變丁眼，因此我們可以在灰度發(fā)布的過程中預先下載并解壓即將要發(fā)布的容器鏡像筷凤，從而大幅提高應用發(fā)布的效率。

在面向終態(tài)的應用管理中苞七，復雜的運維過程被 K8s 內部所實現(xiàn)藐守，K8s根據用戶的期望及現(xiàn)狀計算出需要執(zhí)行的動作，并逐步的變更直到終態(tài)蹂风。面向終態(tài)帶來了卓越的運維效率提升卢厂，但同時也為系統(tǒng)工程架構提出了更高的要求。

我們知道在 K8s 內部是一個模塊化惠啄、分布式的系統(tǒng)慎恒，通往終態(tài)的運維決策分散在內部的多個模塊中，這些模塊都有可能對容器發(fā)起一些運維動作撵渡，比如控制器融柬、運維 Operator、重調度器甚至是 kubelet趋距。在高度自動化的系統(tǒng)中粒氧，一旦出現(xiàn)預期外的異常，其殺傷力可能會對其上運行的業(yè)務造成災難性的后果节腐，加之 K8s 中決策分散在眾多的模塊中靠欢，所帶來的問題是系統(tǒng)風險的控制變得更加困難，對這個系統(tǒng)設計的質量有很高的要求铜跑。

為了控制整個系統(tǒng)的風險，如上圖所示骡澈，我們在 K8s 系統(tǒng)的關鍵位置對關鍵行為行為進行了埋點锅纺，針對性的制定了限流及熔斷的策略，使得整個系統(tǒng)即使在出現(xiàn)極端錯誤的場景下肋殴，也能夠最大化的保護其上運行的業(yè)務囤锉。

自愈能力升級

在阿里巴巴傳統(tǒng)的運維體系下坦弟，容器平臺僅生產資源，應用的啟動以及服務發(fā)現(xiàn)是在容器啟動后由運維平臺系統(tǒng)來完成的官地，這種分層的方法給了運維系統(tǒng)最大的自由度酿傍，也在容器化后促進了阿里巴巴的容器生態(tài)繁榮。

但是這種方式有一個嚴重的問題驱入，因為容器調度平臺無法自主地去觸發(fā)容器的擴縮容赤炒，而需要和一個個運維平臺來做復雜的聯(lián)動，上層運維系統(tǒng)也因為需要感知到底層基礎設施的信息亏较，從而導致進行了很多重復建設的工作莺褒。

在工程實踐上，這些復雜性使得即使經過了細心的設計與大量的投入其工作效率也不高雪情，嚴重妨礙宿主機發(fā)生故障遵岩、重啟，容器中進程發(fā)生崩潰巡通、卡住等異常時的自愈修復效率尘执，同時也讓應用彈性伸縮的實現(xiàn)變得非常的復雜和低效。

我們解決這一問題的思路是通過 K8s 中提供了容器命令以及生命周期鉤子宴凉，將啟動應用以及檢查應用啟動狀態(tài)這一整個流程內置到 pod 中誊锭，包括與監(jiān)控、VIP跪解、服務中心炉旷、配置中心等基礎設施的交互，通過 Pod 實現(xiàn)容器與應用實例的生命周期統(tǒng)一叉讥。

容器平臺不再是僅生產資源窘行，而是交付可以直接為業(yè)務使用的服務，從而使得可以在 K8s 系統(tǒng)內部完成故障自愈閉環(huán)图仓，極大地簡化了應用故障自愈以及自動彈性擴縮容能力的建設罐盔。提高系統(tǒng)自愈的效率，實際上也是幫助業(yè)務獲得更好的運行時穩(wěn)定性和應用運維效率救崔。

在完成了容器與應用實例的生命周期統(tǒng)一之后惶看，我們正在打造一個統(tǒng)一控制器編程框架：Operator Platform。

Operator Platform 由中心的控制組件與一個 sidecar 框架容器以及客戶端代碼組成六孵，通過對通用的控制器能力的抽象纬黎，包括：事件通知、灰度管理劫窒、版本控制本今、緩存、命令管道等能力的封裝集成，支持多語言編寫operator冠息，使得開發(fā)者無需要理解 K8s 的眾多的接口細節(jié)及錯誤處理挪凑，從而降低了基于 operator 的自動化運維能力的開發(fā)難度，使得越來越多的運維能力通過operator 的方式沉淀到 K8s 生態(tài)體系中來逛艰，讓更多的有狀態(tài)應用能夠自動化地部署躏碳，提高整個運維體系的運轉效率。

通過這種方式散怖，構建了整個機器故障自愈的體系菇绵，高效的串聯(lián)起包括機器鎖定、應用驅逐杭抠、機器線下脸甘、異常修復等流程，確保了集群宿主機的在線率以及業(yè)務的可用性偏灿。未來丹诀，我們期望通過將 operator 編寫標準化的方式去推動多個運維平臺的基礎運維能力能夠被最大化的復用，減少重復建設的成本翁垂。

不可變基礎設施

第三個重要的能力升級是對不可變基礎設施的升級铆遭。

我知道 Docker 提供了一種統(tǒng)一的應用交付的形式，通過把應用的二進制沿猜、配置枚荣、依賴文件在構建過程中打到一個鏡像中，從而確保了應用被一次構建出來之后在多個環(huán)境中交付的確定性啼肩，避免了環(huán)境不一致帶來的諸多問題橄妆。

而 K8s 更進一步，通過將不同用途的 Docker 容器組裝在一起成為一個 pod祈坠，通常情況下在升級 pod 時需要整個的銷毀重建害碾，從而確保應用鏡像、卷赦拘、資源規(guī)格的一致性慌随。在落地 K8s 的過程中，堅持了不可變基礎設施的設計理念躺同，通過 K8s pod 將原本運行在一個富容器中的應用與運維基礎組件分離到不同的容器中阁猜，并通過升級容器鏡像的方式完成應用的升級。

這里有一個概念需要澄清蹋艺，并不是使用 K8s 就等于踐行了不可變基礎設施的理念剃袍，而是必須要確保應用運維通過鏡像升級而不是動態(tài)發(fā)布文件的方式完成，而事實上因為一些歷史原因捎谨，這一用法在行業(yè)中普遍存在笛园。

當然隘击，與 K8s 有所不同的是，我們并未強制堅持 pod 的不可變而是取了一個折中的方式研铆，即堅持容器不可變。

原因是我們將應用容器與運維基礎設施容器分離之后州叠，運維容器作為應用容器的 sidecar 容器棵红，其擁有著不同的版本迭代策略。應用容器由應用運維人員負責發(fā)布咧栗，其策略因應用的不同而不同逆甜，比如電商應用使用 StatefulSet 而本地生活使用 Deployment 來管理應用，而基礎設施容器則由基礎設施運維負責致板，其發(fā)布策略與應用本身也存在一些差別交煞。

為了解決這個問題，我們開發(fā)了一個叫做 SidecarSet 的基礎設施容器管理模型斟或，它使用同一個集合統(tǒng)一管理多個應用的運維容器素征，將基礎設施的變更與應用容器的變更進行分離，從而支持基礎設施的快速演進萝挤。將基礎設施容器定義從應用 pod 中抽離出來后御毅，應用管理員不再關心基礎容器的啟動參數，而是交由基礎設施運維人員通過配置 SidecarSet 自動為應用注入運維容器怜珍，簡化了應用運維的復雜性端蛆。

可以看到，這種關注點分離的設計酥泛，同時簡化了應用運維與基礎設施運維的負擔今豆。

總結與展望

阿里云通過落地 K8s 推動阿里巴巴運維體系走向云原生，在應用容器發(fā)布管理效率柔袁、服務穩(wěn)定性以及企業(yè) IT 成本方面取得了很大的突破呆躲。

我們一直在思考，通過什么樣的方式能夠將阿里巴巴的應用管理經驗輸出到更多的場景瘦馍，解決更多客戶面臨的應用管理難題歼秽，在企業(yè)全面云化這樣的趨勢下，如何解決企業(yè)在公有云情组、私有云燥筷、混合云以及多云場景的應用管理復雜性。

正是在這樣的背景下院崇，阿里云與微軟在 2019 年 11 月聯(lián)合推出了一款用于構建和交付云原生應用的標準規(guī)范肆氓，即 Open Application Model（簡稱 OAM）。

OAM 提出了一種通用的模型底瓣，讓各平臺可以在統(tǒng)一的高層抽象上透出應用部署和運維能力谢揪，解決跨平臺的應用交付問題蕉陋。同時，OAM 以標準化的方式溝通和連接應用開發(fā)者拨扶、運維人員凳鬓、應用基礎設施，讓云原生應用交付和管理流程更加連貫患民、一致缩举。

通過應用交付標準化的方法，我們期望未來在云上部署一個應用匹颤，就像手機在應用商店中安裝一個淘寶一樣便捷與高效仅孩。