作者：
曾凡松 阿裡雲雲原生應用平台進階技術專家
張振 阿裡雲雲原生應用平台進階技術專家
導讀：本文描述了阿裡巴巴在容器管理領域的技術演進曆程，解讀了為什麼 K8s 最終能夠大獲成功的原因，以及到今年 雙11 阿裡巴巴内部的 K8s 應用情況。内容着重描述了阿裡巴巴基于 K8s 的雲原生改造實踐過程的三大能力更新，在對應能力更新過程中沉澱的技術解決方案，以及通過這些能力更新所取得的業務價值。
從 2015 年 Google 牽頭成立 CNCF 以來，雲原生技術開始進入公衆的視線并取得快速的發展，到 2018 年包括 Google、AWS、Azure、Alibaba Cloud 等大型雲計算供應商都加入了 CNCF，雲原生技術也從原來的應用容器化發展出包括容器、Service Mesh、微服務、不可變基礎設施、Serverless、FaaS 等衆多技術方向，CFCF 旗下也囊括了越來多的開源項目。
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 的方式提供出來。
在 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 自動為應用注入運維容器，簡化了應用運維的複雜性。
可以看到，這種關注點分離的設計，同時簡化了應用運維與基礎設施運維的負擔。
總結與展望
阿裡雲通過落地 K8s 推動阿裡巴巴運維體系走向雲原生，在應用容器釋出管理效率、服務穩定性以及企業 IT 成本方面取得了很大的突破。
我們一直在思考，通過什麼樣的方式能夠将阿裡巴巴的應用管理經驗輸出到更多的場景，解決更多客戶面臨的應用管理難題，在企業全面雲化這樣的趨勢下，如何解決企業在公有雲、私有雲、混合雲以及多雲場景的應用管理複雜性。
正是在這樣的背景下，阿裡雲與微軟在 2019 年 11 月聯合推出了一款用于建構和傳遞雲原生應用的标準規範，即
Open Application Model（簡稱 OAM）。
OAM 提出了一種通用的模型，讓各平台可以在統一的高層抽象上透出應用部署和運維能力，解決跨平台的應用傳遞問題。同時，
OAM以标準化的方式溝通和連接配接應用開發者、運維人員、應用基礎設施，讓雲原生應用傳遞和管理流程更加連貫、一緻。
通過應用傳遞标準化的方法，我們期望未來在雲上部署一個應用，就像手機在應用商店中安裝一個淘寶一樣便捷與高效。
最後，本文提到的阿裡巴巴在雲原生改造上完成的相關能力更新，我們都已經或者即将開源到
OpenKruise 項目中，歡迎大家關注與交流！
參與方式：
- 釘釘掃碼進入 OAM 項目中文讨論群
（釘釘掃碼加入交流群）
雲原生實踐峰會即将開幕
“ 阿裡巴巴雲原生 關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”