爲何 K8s 在阿里能成功？| 問底中國 IT 技術演進

時間 2020-07-21

原文原文鏈接

做者：
曾凡鬆阿里云云原生應用平臺高級技術專家
張振阿里云云原生應用平臺高級技術專家git

導讀：本文描述了阿里巴巴在容器管理領域的技術演進歷程，解讀了爲何 K8s 最終可以大獲成功的緣由，以及到今年雙11 阿里巴巴內部的 K8s 應用狀況。內容着重描述了阿里巴巴基於 K8s 的雲原生改造實踐過程的三大能力升級，在對應能力升級過程當中沉澱的技術解決方案，以及經過這些能力升級所取得的業務價值。

從 2015 年 Google 牽頭成立 CNCF 以來，雲原生技術開始進入公衆的視線並取得快速的發展，到 2018 年包括 Google、AWS、Azure、Alibaba Cloud 等大型雲計算供應商都加入了 CNCF，雲原生技術也從原來的應用容器化發展出包括容器、Service Mesh、微服務、不可變基礎設施、Serverless、FaaS 等衆多技術方向，CFCF 旗下也囊括了越來多的開源項目。github

Kubernetes 做爲 CNCF 的第一個項目從誕生之初就就使人矚目，Kubernetes 由 Google 工程師基於 Google 內部多年集羣管理系統 Borg 的設計經驗，結合雲計算時代的基礎設施特色從新設計而得，旨在幫助企業解決大規模 IT 基礎設施的應用容器編排難題。編程

Google 在 2014 年 6 月開源 Kubernetes 之後，在 Redhat、Microsoft、Alibaba 等廠商和衆多開源愛好者共同的努力下，成長爲現在容器編排領域的事實標準，極大的推進了雲原生領域的發展。緩存

今天爲你們分享來自阿里雲的 Kubernetes 大規模實踐經驗，展示阿里雲如何基於 Kubernetes 推進阿里巴巴應用運維技術棧走向雲原生，如何推進 Kubernetes自身的技術進步，充分挖掘雲原生時代的紅利助力阿里巴巴大幅下降雙11 的 IT 成本。服務器

容器在阿里巴巴的發展歷程

在 2011 年以前，阿里巴巴使用 VM 虛擬化技術將一個物理機切分爲 3 個虛擬機，用於部署淘寶服務，而隨着淘寶業務的飛速發展，基於 VM 的技術方案在靈活性上跟不上業務的步伐。網絡

所以，阿里巴巴在 2011 年就開始探索基於 Linux lxc 的容器技術，用於替代傳統基於 VM 的應用部署方案，到 2013 年，研發了基於 Linux lxc 的 T4 容器和 AI 容器編排系統。這在當時已經是很是領先的技術方案，但本身研發的容器技術與基於 VM 時代的運維繫統始終存在一些兼容性問題。架構

在 2013 年隨着 Docker 容器鏡像方案的出現，阿里巴巴技術人員當即看到了基於容器 + Docker 鏡像技術的將來，開始大力投入到這一領域的研究當中，到 2015 年 Aliswarm、Zeus、Hippo 等容器編排系統蓬勃發展，各自開疆擴土服務了阿里巴巴經濟體的一部分業務。諸多的系統在解決了業務運維成本的同時，也帶來了必定的重複建設成本，同時也致使了阿里巴巴內部的資源分佈比較分散，沒法統一調度多樣的業務類型發揮出不一樣業務錯峯使用資源的優點。併發

正是在這樣的背景下，Sigma 系統應運而出並在 2017 年統一了阿里巴巴的資源池，統一調度阿里巴巴全部的核心業務，並第一次支持將在線服務與離線做業運行在同一個物理機上，大幅提升數據中心的資源利用效率並下降了阿里巴巴的 IT 成本。框架

隨着雲原生技術的高速發展，阿里巴巴也看到了雲原生技術的潛力，以及將來企業 IT 全面上雲的必然趨勢，從 2018 年開始轉型到 Kubernetes 技術，經過 Kubernetes 擴展能力將 Sigma 積累多年的調度能力經過 Kubernetes 的方式提供出來。less

在 2019 年阿里巴巴宣佈全面上雲，阿里巴巴開始全面擁抱 Kubernetes，並將 Sigma 調度系統全面的遷移到基於 Kubernetes 的調度系統，該系統也正是支持了今年最大規模雙11 電商交易系統的底層基礎設施，穩定的支持了大促先後數百次的應用變動並提供極速的應用發佈與擴容體驗，爲雙11 的順暢的購物體驗立下悍馬功勞。

爲何 K8s 在阿里能成功

Kubernetes 在衆多的技術中脫穎而出，歸納起來能夠概括爲如下三個方面。

首先是其在誕生之初就爲雲時代而生，擁有超前的眼光和先進的設計理念，加之最初由天才的 Google 工程師基於其內部 Borg 多年的經驗設計而來，誕生以後就飛速發展；

後來隨着 RedHat、IBM、微軟、Vmware、阿里雲等來自全球的優秀工程師大力投入，打造了繁榮的社區和生態系統，成爲企業容器編排系統的首選。

阿里巴巴經濟體擁有衆多的子公司，這些子公司在加入阿里巴巴你們庭時或多或少都會有一套自有的容器編排系統，在融入阿里巴巴的基礎設施過程當中，Kubernetes 是最標準也最容易被經濟體內外的客戶所接受的一個方案。

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

傳統的運維繫統一般是基於過程式的設計，而過程式的運維繫統在較長的系統調用鏈路下，一般會出現因異常處理複雜而致使的系統效率低下。

在大規模應用運維繫統中複雜又繁多的狀態處理也是一個大難題，基於過程式的系統設計很難確保系統的一致性，針對這些邊界異常的處理一般又致使運維繫統變得很是複雜，最終爲異常兜底的只能依賴運維人員的人工操做。基本上能夠認爲基於過程式的運維繫統難以應對超大規模的應用管理，而 Kubernetes 提供的申明式 API 倒是解決應用運維狀態輪轉的一劑良藥，是提升運維技術棧總體鏈路效率的最佳實踐原則。

第三，Kubernetes 模塊化、可擴展的架構設計，知足阿里巴巴的定製化改造以支持衆多業務運維場景的需求。

在阿里巴巴內部，即有大量的無狀態核心電商系統，也有大量的緩存、消息隊列等中間件有狀態系統，也包括大量帶有倒排索引數據的檢索系統，還有大量的 AI 計算任務，不用的應用類型對底層容器管理平臺的要求也有所不一樣。

所以，一個模塊化方便遷入自定義應用管理策略、易於擴展調度模型的設計顯得相當重要，是可以服務阿里內部衆多應用形態、提供統一容器管理基礎設施的關鍵，Kubernetes 基本上提供了這些關鍵基礎能力，雖然在實際應用過程當中仍然會遇到很是多的實際問題。

阿里巴巴的 K8s 應用狀況

在 2019 年雙11，阿里巴巴內部核心業務主要運行在神龍、ECS、ECI 三種資源類型的基礎設施之上，而這些不一樣類型的基礎設施資源均經過 Kubernetes 統一管理，以容器的形態提供給上層應用使用，完成了核心業務的支撐。

有別於以往的雙11，今年核心電商業務應用大規模部署在神龍裸金屬服務器上。若是有關注過阿里雲技術的發展，應該不會對神龍服務器感到陌生，它是阿里雲自主研發的新一代雲服務器，經過「軟硬一體」的技術開創性的將雲計算的虛擬化開銷分攤到低價硬件板卡上，完全的釋放 CPU 的計算能力，第一次真正的作到了雲計算虛擬化的「零」開銷。

容器也是一種輕量級的虛擬化方案，神龍+容器+Kubernetes 的結合正是雲原生時代的最佳拍檔，支撐了今年最大規模的雙11，也將是將來的主流技術形態。

阿里巴巴也在繼續使用 ECS 做爲 Kubernetes 的底層資源供給，ECS 做爲傳統的雲計算虛擬化方式支撐了部門集團內部業務，同時結合靈活性更好的彈性容器實例 ECI 用於應對業務突發的流量峯值，爲業務帶來了雲計算的彈性價值，真正實現了按需申請、釋放資源的極致彈性能力，下降了業務須要提早規劃資源所帶來的成本。

這些分佈在海內外的數十萬個節點的資源，被數十個 Kubernetes 集羣託管，運行着阿里巴巴上萬個應用，共計超過百萬的容器，其規模之大史無前例。在今年的雙11 中，阿里巴巴內部最大的 Kubernetes 集羣規模達到萬級；固然這並非Kubernetes 的技術極限，而是咱們考慮數據中心資源效率與基礎設施容災能力之間所取的平衡，在未來若是有須要這個數字也可能變得更大。

基於 K8s 的雲原生改造實踐

Kubernetes 做爲雲原生技術的表明，已經成爲了容器編排領域的事實標準，阿里巴巴自 2017 年開始探索，到 2018 年確認技術轉型到使用 Kubernetes 來管理生產的容器。

在落地 K8s 的過程當中，咱們主要面臨着兩大難題：

其一，上層多樣的業務運維平臺；

爲了支撐阿里巴巴內部多樣的業務形態，在內部發展出來了多個典型的業務運維平臺，每個運維平臺的基礎設施、流程控制、應用發佈策或多或少都會存在一些差異，缺乏一個統一的應用運維標準。在調度與集羣管理的技術演進過程當中，如何牽引整個運維體系升級的同時並保持多個業務的平臺及其上業務的穩定性，這是一個巨大的工程。

其二，隨着阿里巴巴經濟體全面上雲戰略的實施，整個底層基礎設施包括存儲、網絡、基礎運維軟件的技術演進也很是迅速。調度與集羣管理須要在支持好基礎設施快速演進的同時，迭代自身的技術架構，並同時保證業務的穩定性。

基於 K8s 的雲原生技術改造正是在這樣的背景下誕生，發展到 2019 年 Kubernetes 在內部已大規模部署，全部的核心業務也都已經運行在 K8s 集羣管理中。但在這幾年的實踐過程當中，有一個問題始終縈繞在工程師頭腦中，在阿里巴巴這麼大致量、這麼複雜的業務下，遺留了大量傳統的運維習慣以及支撐這些習慣的運維體系，在這樣的背景下落地Kubernetes （內部一個形象的比喻叫作給高速飛行的飛機更換髮動機）究竟是在堅持什麼，哪些地方能夠妥協，哪些地方必須改變？

這一章節，將爲你們分享咱們這幾年對這個問題的一些思考，特別是通過了今年的雙11 考驗後，這個問題的答案基本上獲得了工程師羣裏的集體承認。

負責頂層設計的架構師終於能夠喘一口氣：擁抱 Kubernetes 自己並非目的，而經過擁抱 Kubernetes 翹動業務的雲原生改造，經過 Kubernetes 的能力治理傳統運維體系下的沉痾頑疾，真正釋放雲的彈性能力，爲業務的應用交付解綁提速，纔是此次技術變革的最大價值所在。

面向終態升級

在傳統的運維體系下，應用的變動都是運維經過建立操做工單發起工做流，繼而對容器平臺發起一個個的變動來完成的。好比升級一個服務下的 3000 個實例，工單會被提早計算並生成出多個批次的子任務，並逐個的調用容器平臺的接口完成變動應用的變動。

爲了確保應用發佈工單的順利執行，在每個子工單內部，每個容器的發佈也是一個工做流，包括監控開管、鏡像拉取、容器啓停、服務註冊、配置推送等等，若是一切正常該流程會按預期有序的進行。

在大規模應用發佈的場景中，諸如宿主機宕機、磁盤異常、IO 異常、網絡異常、內核異常等幾乎是必然存在的，若是發佈流程中的某一個步驟出現了錯誤，一般狀況下須要運維平臺按照必定的策略來重試，直到超過該批次的超時閾值，這將會帶來三個問題，下面逐一展開。

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

每個子任務的執行時間將被任務內的長尾發佈所拖累，假設將 3000 個容器分爲 30 批次每批 100 個（僅爲示意並不是最佳實踐），每一批次內出現一個容器發佈異常時，該批次的發佈時間將被重試拉長。

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

對於發佈異常的容器，在工單結束以後一般只能經過外圍鏈路巡檢的方式來治理，而事實上一般的巡檢是依賴運維人員手工操做的，帶來了極大的人工成本和不肯定性。

第三是應用併發變動衝突問題。

若是在應用發佈的過程當中，同時提交了應用擴容的請求，由 3000 擴容到 3200 個實例，擴容的 200 個實例應該採用舊版本仍是新版本，採用舊版本擴容將面臨的問題是誰最終負責這 200 箇舊版本實例的升級，採用新版本擴容將面臨的是穩定性問題，若是新版本存在問題新擴容的實例將產生較大的影響。

正是由於這些複雜的問題致使多數運維繫統拒絕了併發的應用變動，致使併發操做效率很是底下。

K8s 爲應用管理所提供的申明式 API 的設計理念同時解決了解決了這三個問題，用戶只須要描述指望的最終狀態以及達成指望狀態的過程當中須要遵照的限制條件，達成終態所須要執行的複雜操做所有交由 K8s 的來完成。

在應用發佈過程當中，一般狀況下 K8s 經過控制併發度及最大不可用實例數來約束應用發佈對服務的影響，對於發佈過程當中失敗的實例經過最終一致的方式在系統內部解決。正是基於這一設計，用戶發起服務變動時只是更新了應用的預期狀態，並不須要等待任何任務的結束，一併解決了應用發佈效率、線上配置的一致性和併發變動衝突效率的問題。

基於面向終態的理念管理應用，咱們開發 Advanced StatefulSet 的應用管理工做模型，顧名思義它基於 Kubernetes 官方的 StatefulSet 擴展而來。

在官方的工做模型中，應用經過滾動的方式完成版本升級，也就是建立新的 Pod 同時刪除舊版本的 Pod，直到整個應用切換爲新的版本。

這種方式簡單直接，但存在效率的問題，好比全部應用的 Pod 須要從新的調度，這在大規模應用發佈場景將給調度器帶來很大的壓力；同時，由於新版本 Pod 爲全新建立，須要從新分配 IP 並掛載遠程卷，這對雲計算網絡、存儲基礎設施也將是很大的挑戰；再者，由於容器是被全新調度出來的，在機器上須要從新下載新的應用鏡像，這將大幅下降應用發佈的效率。

爲了提升應用發佈的效率和資源的肯定性，開發了這一工做負載模型，它支持原地發佈應用，應用發佈先後應用所在的位置保持不變，同時支持了併發更新、容錯暫停等豐富的發佈策略，高效的知足了阿里巴巴內部電商應用的發佈需求。由於應用發佈先後位置不變，所以咱們能夠在灰度發佈的過程當中預先下載並解壓即將要發佈的容器鏡像，從而大幅提升應用發佈的效率。

在面向終態的應用管理中，複雜的運維過程被 K8s 內部所實現，K8s根據用戶的指望及現狀計算出須要執行的動做，並逐步的變動直到終態。面向終態帶來了卓越的運維效率提高，但同時也爲系統工程架構提出了更高的要求。

咱們知道在 K8s 內部是一個模塊化、分佈式的系統，通往終態的運維決策分散在內部的多個模塊中，這些模塊都有可能對容器發起一些運維動做，好比控制器、運維 Operator、重調度器甚至是 kubelet。在高度自動化的系統中，一旦出現預期外的異常，其殺傷力可能會對其上運行的業務形成災難性的後果，加之 K8s 中決策分散在衆多的模塊中，所帶來的問題是系統風險的控制變得更加困難，對這個系統設計的質量有很高的要求。

爲了控制整個系統的風險，如上圖所示，咱們在 K8s 系統的關鍵位置對關鍵行爲行爲進行了埋點，針對性的制定了限流及熔斷的策略，使得整個系統即便在出現極端錯誤的場景下，也可以最大化的保護其上運行的業務。

自愈能力升級

在阿里巴巴傳統的運維體系下，容器平臺僅生產資源，應用的啓動以及服務發現是在容器啓動後由運維平臺系統來完成的，這種分層的方法給了運維繫統最大的自由度，也在容器化後促進了阿里巴巴的容器生態繁榮。

可是這種方式有一個嚴重的問題，由於容器調度平臺沒法自主地去觸發容器的擴縮容，而須要和一個個運維平臺來作複雜的聯動，上層運維繫統也由於須要感知到底層基礎設施的信息，從而致使進行了不少重複建設的工做。

在工程實踐上，這些複雜性使得即便通過了細心的設計與大量的投入其工做效率也不高，嚴重妨礙宿主機發生故障、重啓，容器中進程發生崩潰、卡住等異常時的自愈修復效率，同時也讓應用彈性伸縮的實現變得很是的複雜和低效。

咱們解決這一問題的思路是經過 K8s 中提供了容器命令以及生命週期鉤子，將啓動應用以及檢查應用啓動狀態這一正個流程內置到 pod 中，包括與監控、VIP、服務中心、配置中心等基礎設施的交互，經過 Pod 實現容器與應用實例的生命週期統一。

容器平臺再也不是僅生產資源，而是交付能夠直接爲業務使用的服務，從而使得能夠在 K8s 系統內部完成故障自愈閉環，極大地簡化了應用故障自愈以及自動彈性擴縮容能力的建設。提升系統自愈的效率，實際上也是幫助業務得到更好的運行時穩定性和應用運維效率。

在完成了容器與應用實例的生命週期統一以後，咱們正在打造一個統一控制器編程框架：Operator Platform。

Operator Platform 由中心的控制組件與一個 sidecar 框架容器以及客戶端代碼組成，經過對通用的控制器能力的抽象，包括：事件通知、灰度管理、版本控制、緩存、命令管道等能力的封裝集成，支持多語言編寫operator，使得開發者無須要理解 K8s 的衆多的接口細節及錯誤處理，從而下降了基於 operator 的自動化運維能力的開發難度，使得愈來愈多的運維能力經過operator 的方式沉澱到 K8s 生態體系中來，讓更多的有狀態應用可以自動化地部署，提升整個運維體系的運轉效率。

經過這種方式，構建了整個機器故障自愈的體系，高效的串聯起包括機器鎖定、應用驅逐、機器線下、異常修復等流程，確保了集羣宿主機的在線率以及業務的可用性。將來，咱們指望經過將 operator 編寫標準化的方式去推進多個運維平臺的基礎運維能力可以被最大化的複用，減小重複建設的成本。

不可變基礎設施

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

我知道 Docker 提供了一種統一的應用交付的形式，經過把應用的二進制、配置、依賴文件在構建過程當中打到一個鏡像中，從而確保了應用被一次構建出來以後在多個環境中交付的肯定性，避免了環境不一致帶來的諸多問題。

而 K8s 更進一步，經過將不一樣用途的 Docker 容器組裝在一塊兒成爲一個 pod，一般狀況下在升級 pod 時須要整個的銷燬重建，從而確保應用鏡像、卷、資源規格的一致性。在落地 K8s 的過程當中，堅持了不可變基礎設施的設計理念，經過 K8s pod 將本來運行在一個富容器中的應用與運維基礎組件分離到不一樣的容器中，並經過升級容器鏡像的方式完成應用的升級。

這裏有一個概念須要澄清，並非使用 K8s 就等於踐行了不可變基礎設施的理念，而是必需要確保應用運維經過鏡像升級而不是動態發佈文件的方式完成，而事實上由於一些歷史緣由，這一用法在行業中廣泛存在。

固然，與 K8s 有所不一樣的是，咱們並未強制堅持 pod 的不可變而是取了一個折中的方式，即堅持容器不可變。

緣由是咱們將應用容器與運維基礎設施容器分離以後，運維容器做爲應用容器的 sidecar 容器，其擁有着不一樣的版本迭代策略。應用容器由應用運維人員負責發佈，其策略因應用的不一樣而不一樣，好比電商應用使用 StatefulSet 而本地生活使用 Deployment 來管理應用，而基礎設施容器則由基礎設施運維負責，其發佈策略與應用自己也存在一些差異。

爲了解決這個問題，咱們開發了一個叫作 SidecarSet 的基礎設施容器管理模型，它使用同一個集合統一管理多個應用的運維容器，將基礎設施的變動與應用容器的變動進行分離，從而支持基礎設施的快速演進。將基礎設施容器定義從應用 pod 中抽離出來後，應用管理員再也不關心基礎容器的啓動參數，而是交由基礎設施運維人員經過配置 SidecarSet 自動爲應用注入運維容器，簡化了應用運維的複雜性。

能夠看到，這種關注點分離的設計，同時簡化了應用運維與基礎設施運維的負擔。