作者：
曾凡松 阿里云云原生應(yīng)用平臺(tái)高級(jí)技術(shù)專家
張振 阿里云云原生應(yīng)用平臺(tái)高級(jí)技術(shù)專家

導(dǎo)讀：本文描述了阿里巴巴在容器管理領(lǐng)域的技術(shù)演進(jìn)歷程，解讀了為什么 K8s 最終能夠大獲成功的原因，以及到今年 雙11 阿里巴巴內(nèi)部的 K8s 應(yīng)用情況。內(nèi)容著重描述了阿里巴巴基于 K8s 的云原生改造實(shí)踐過程的三大能力升級(jí)，在對(duì)應(yīng)能力升級(jí)過程中沉淀的技術(shù)解決方案，以及通過這些能力升級(jí)所取得的業(yè)務(wù)價(jià)值。

從 2015 年 Google 牽頭成立 CNCF 以來，云原生技術(shù)開始進(jìn)入公眾的視線并取得快速的發(fā)展，到 2018 年包括 Google、AWS、Azure、Alibaba Cloud 等大型云計(jì)算供應(yīng)商都加入了 CNCF，云原生技術(shù)也從原來的應(yīng)用容器化發(fā)展出包括容器、Service Mesh、微服務(wù)、不可變基礎(chǔ)設(shè)施、Serverless、FaaS 等眾多技術(shù)方向，CFCF 旗下也囊括了越來多的開源項(xiàng)目。

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

Google 在 2014 年 6 月開源 Kubernetes 以后，在 Redhat、Microsoft、Alibaba 等廠商和眾多開源愛好者共同的努力下，成長為如今容器編排領(lǐng)域的事實(shí)標(biāo)準(zhǔn)，極大的推動(dòng)了云原生領(lǐng)域的發(fā)展。

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

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

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

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

在 2013 年隨著 Docker 容器鏡像方案的出現(xiàn)，阿里巴巴技術(shù)人員立即看到了基于容器 + Docker 鏡像技術(shù)的未來，開始大力投入到這一領(lǐng)域的研究當(dāng)中，到 2015 年 Aliswarm、Zeus、Hippo 等容器編排系統(tǒng)蓬勃發(fā)展，各自開疆?dāng)U土服務(wù)了阿里巴巴經(jīng)濟(jì)體的一部分業(yè)務(wù)。諸多的系統(tǒng)在解決了業(yè)務(wù)運(yùn)維成本的同時(shí)，也帶來了一定的重復(fù)建設(shè)成本，同時(shí)也導(dǎo)致了阿里巴巴內(nèi)部的資源分布比較分散，無法統(tǒng)一調(diào)度多樣的業(yè)務(wù)類型發(fā)揮出不同業(yè)務(wù)錯(cuò)峰使用資源的優(yōu)勢(shì)。

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

隨著云原生技術(shù)的高速發(fā)展，阿里巴巴也看到了云原生技術(shù)的潛力，以及未來企業(yè) IT 全面上云的必然趨勢(shì)，從 2018 年開始轉(zhuǎn)型到 Kubernetes 技術(shù)，通過 Kubernetes 擴(kuò)展能力將 Sigma 積累多年的調(diào)度能力通過 Kubernetes 的方式提供出來。

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

#為什么 K8s 在阿里能成功

Kubernetes 在眾多的技術(shù)中脫穎而出，概括起來可以歸納為以下三個(gè)方面。

• 首先是其在誕生之初就為云時(shí)代而生，擁有超前的眼光和先進(jìn)的設(shè)計(jì)理念，加之最初由天才的 Google 工程師基于其內(nèi)部 Borg 多年的經(jīng)驗(yàn)設(shè)計(jì)而來，誕生之后就飛速發(fā)展；

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

阿里巴巴經(jīng)濟(jì)體擁有眾多的子公司，這些子公司在加入阿里巴巴大家庭時(shí)或多或少都會(huì)有一套自有的容器編排系統(tǒng)，在融入阿里巴巴的基礎(chǔ)設(shè)施過程中，Kubernetes 是最標(biāo)準(zhǔn)也最容易被經(jīng)濟(jì)體內(nèi)外的客戶所接受的一個(gè)方案。

• 其次，Kubernetes 倡導(dǎo)的申明式 API 的設(shè)計(jì)理念，也貼合了阿里巴巴在應(yīng)用運(yùn)維領(lǐng)域的經(jīng)驗(yàn)與教訓(xùn)；

傳統(tǒng)的運(yùn)維系統(tǒng)通常是基于過程式的設(shè)計(jì)，而過程式的運(yùn)維系統(tǒng)在較長的系統(tǒng)調(diào)用鏈路下，通常會(huì)出現(xiàn)因異常處理復(fù)雜而導(dǎo)致的系統(tǒng)效率低下。

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

• 第三，Kubernetes 模塊化、可擴(kuò)展的架構(gòu)設(shè)計(jì)，滿足阿里巴巴的定制化改造以支持眾多業(yè)務(wù)運(yùn)維場(chǎng)景的需求。

在阿里巴巴內(nèi)部，即有大量的無狀態(tài)核心電商系統(tǒng)，也有大量的緩存、消息隊(duì)列等中間件有狀態(tài)系統(tǒng)，也包括大量帶有倒排索引數(shù)據(jù)的檢索系統(tǒng)，還有大量的 AI 計(jì)算任務(wù)，不用的應(yīng)用類型對(duì)底層容器管理平臺(tái)的要求也有所不同。

因此，一個(gè)模塊化方便遷入自定義應(yīng)用管理策略、易于擴(kuò)展調(diào)度模型的設(shè)計(jì)顯得至關(guān)重要，是能夠服務(wù)阿里內(nèi)部眾多應(yīng)用形態(tài)、提供統(tǒng)一容器管理基礎(chǔ)設(shè)施的關(guān)鍵，Kubernetes 基本上提供了這些關(guān)鍵基礎(chǔ)能力，雖然在實(shí)際應(yīng)用過程中仍然會(huì)遇到非常多的實(shí)際問題。

阿里巴巴的 K8s 應(yīng)用情況

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

有別于以往的 雙11，今年核心電商業(yè)務(wù)應(yīng)用大規(guī)模部署在神龍裸金屬服務(wù)器上。如果有關(guān)注過阿里云技術(shù)的發(fā)展，應(yīng)該不會(huì)對(duì)神龍服務(wù)器感到陌生，它是阿里云自主研發(fā)的新一代云服務(wù)器，通過“軟硬一體”的技術(shù)開創(chuàng)性的將云計(jì)算的虛擬化開銷分?jǐn)偟降蛢r(jià)硬件板卡上，徹底的釋放 CPU 的計(jì)算能力，第一次真正的做到了云計(jì)算虛擬化的“零”開銷。

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

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

這些分布在海內(nèi)外的數(shù)十萬個(gè)節(jié)點(diǎn)的資源，被數(shù)十個(gè) Kubernetes 集群托管，運(yùn)行著阿里巴巴上萬個(gè)應(yīng)用，共計(jì)超過百萬的容器，其規(guī)模之大前所未有。在今年的 雙11 中，阿里巴巴內(nèi)部最大的 Kubernetes 集群規(guī)模達(dá)到萬級(jí)；當(dāng)然這并不是Kubernetes 的技術(shù)極限，而是我們考慮數(shù)據(jù)中心資源效率與基礎(chǔ)設(shè)施容災(zāi)能力之間所取的平衡，在將來如果有需要這個(gè)數(shù)字也可能變得更大。

基于 K8s 的云原生改造實(shí)踐

Kubernetes 作為云原生技術(shù)的代表，已經(jīng)成為了容器編排領(lǐng)域的事實(shí)標(biāo)準(zhǔn)，阿里巴巴自 2017 年開始探索，到 2018 年確認(rèn)技術(shù)轉(zhuǎn)型到使用 Kubernetes 來管理生產(chǎn)的容器。

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

• 其一，上層多樣的業(yè)務(wù)運(yùn)維平臺(tái)；

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

• 其二，隨著阿里巴巴經(jīng)濟(jì)體全面上云戰(zhàn)略的實(shí)施，整個(gè)底層基礎(chǔ)設(shè)施包括存儲(chǔ)、網(wǎng)絡(luò)、基礎(chǔ)運(yùn)維軟件的技術(shù)演進(jìn)也非常迅速。調(diào)度與集群管理需要在支持好基礎(chǔ)設(shè)施快速演進(jìn)的同時(shí)，迭代自身的技術(shù)架構(gòu)，并同時(shí)保證業(yè)務(wù)的穩(wěn)定性。

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

這一章節(jié)， 將為大家分享我們這幾年對(duì)這個(gè)問題的一些思考，特別是經(jīng)過了今年的 雙11 考驗(yàn)后，這個(gè)問題的答案基本上得到了工程師群里的集體認(rèn)可。

負(fù)責(zé)頂層設(shè)計(jì)的架構(gòu)師終于可以喘一口氣：擁抱 Kubernetes 本身并不是目的，而通過擁抱 Kubernetes 翹動(dòng)業(yè)務(wù)的云原生改造，通過 Kubernetes 的能力治理傳統(tǒng)運(yùn)維體系下的沉疴頑疾，真正釋放云的彈性能力，為業(yè)務(wù)的應(yīng)用交付解綁提速，才是這次技術(shù)變革的最大價(jià)值所在。

面向終態(tài)升級(jí)

在傳統(tǒng)的運(yùn)維體系下，應(yīng)用的變更都是運(yùn)維通過創(chuàng)建操作工單發(fā)起工作流，繼而對(duì)容器平臺(tái)發(fā)起一個(gè)個(gè)的變更來完成的。比如升級(jí)一個(gè)服務(wù)下的 3000 個(gè)實(shí)例，工單會(huì)被提前計(jì)算并生成出多個(gè)批次的子任務(wù)，并逐個(gè)的調(diào)用容器平臺(tái)的接口完成變更應(yīng)用的變更。

為了確保應(yīng)用發(fā)布工單的順利執(zhí)行，在每一個(gè)子工單內(nèi)部，每一個(gè)容器的發(fā)布也是一個(gè)工作流，包括監(jiān)控開管、鏡像拉取、容器啟停、服務(wù)注冊(cè)、配置推送等等，如果一切正常該流程會(huì)按預(yù)期有序的進(jìn)行。

在大規(guī)模應(yīng)用發(fā)布的場(chǎng)景中，諸如宿主機(jī)宕機(jī)、磁盤異常、IO 異常、網(wǎng)絡(luò)異常、內(nèi)核異常等幾乎是必然存在的，如果發(fā)布流程中的某一個(gè)步驟出現(xiàn)了錯(cuò)誤，通常情況下需要運(yùn)維平臺(tái)按照一定的策略來重試，直到超過該批次的超時(shí)閾值，這將會(huì)帶來三個(gè)問題，下面逐一展開。

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

每一個(gè)子任務(wù)的執(zhí)行時(shí)間將被任務(wù)內(nèi)的長尾發(fā)布所拖累，假設(shè)將 3000 個(gè)容器分為 30 批次每批 100 個(gè)（僅為示意并非最佳實(shí)踐），每一批次內(nèi)出現(xiàn)一個(gè)容器發(fā)布異常時(shí)，該批次的發(fā)布時(shí)間將被重試?yán)L。

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

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

• 第三是應(yīng)用并發(fā)變更沖突問題。

如果在應(yīng)用發(fā)布的過程中，同時(shí)提交了應(yīng)用擴(kuò)容的請(qǐng)求，由 3000 擴(kuò)容到 3200 個(gè)實(shí)例，擴(kuò)容的 200 個(gè)實(shí)例應(yīng)該采用舊版本還是新版本，采用舊版本擴(kuò)容將面臨的問題是誰最終負(fù)責(zé)這 200 個(gè)舊版本實(shí)例的升級(jí)，采用新版本擴(kuò)容將面臨的是穩(wěn)定性問題，如果新版本存在問題新擴(kuò)容的實(shí)例將產(chǎn)生較大的影響。

正是因?yàn)檫@些復(fù)雜的問題導(dǎo)致多數(shù)運(yùn)維系統(tǒng)拒絕了并發(fā)的應(yīng)用變更，導(dǎo)致并發(fā)操作效率非常底下。

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

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

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

在官方的工作模型中，應(yīng)用通過滾動(dòng)的方式完成版本升級(jí)，也就是創(chuàng)建新的 Pod 同時(shí)刪除舊版本的 Pod，直到整個(gè)應(yīng)用切換為新的版本。

這種方式簡(jiǎn)單直接，但存在效率的問題，比如所有應(yīng)用的 Pod 需要重新的調(diào)度，這在大規(guī)模應(yīng)用發(fā)布場(chǎng)景將給調(diào)度器帶來很大的壓力；同時(shí)，因?yàn)樾掳姹?Pod 為全新創(chuàng)建，需要重新分配 IP 并掛載遠(yuǎn)程卷，這對(duì)云計(jì)算網(wǎng)絡(luò)、存儲(chǔ)基礎(chǔ)設(shè)施也將是很大的挑戰(zhàn)；再者，因?yàn)槿萜魇潜蝗抡{(diào)度出來的，在機(jī)器上需要重新下載新的應(yīng)用鏡像，這將大幅降低應(yīng)用發(fā)布的效率。

為了提高應(yīng)用發(fā)布的效率和資源的確定性，開發(fā)了這一工作負(fù)載模型，它支持原地發(fā)布應(yīng)用，應(yīng)用發(fā)布前后應(yīng)用所在的位置保持不變，同時(shí)支持了并發(fā)更新、容錯(cuò)暫停等豐富的發(fā)布策略，高效的滿足了阿里巴巴內(nèi)部電商應(yīng)用的發(fā)布需求。因?yàn)閼?yīng)用發(fā)布前后位置不變，因此我們可以在灰度發(fā)布的過程中預(yù)先下載并解壓即將要發(fā)布的容器鏡像，從而大幅提高應(yīng)用發(fā)布的效率。

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

我們知道在 K8s 內(nèi)部是一個(gè)模塊化、分布式的系統(tǒng)，通往終態(tài)的運(yùn)維決策分散在內(nèi)部的多個(gè)模塊中，這些模塊都有可能對(duì)容器發(fā)起一些運(yùn)維動(dòng)作，比如控制器、運(yùn)維 Operator、重調(diào)度器甚至是 kubelet。在高度自動(dòng)化的系統(tǒng)中，一旦出現(xiàn)預(yù)期外的異常，其殺傷力可能會(huì)對(duì)其上運(yùn)行的業(yè)務(wù)造成災(zāi)難性的后果，加之 K8s 中決策分散在眾多的模塊中，所帶來的問題是系統(tǒng)風(fēng)險(xiǎn)的控制變得更加困難，對(duì)這個(gè)系統(tǒng)設(shè)計(jì)的質(zhì)量有很高的要求。

為了控制整個(gè)系統(tǒng)的風(fēng)險(xiǎn)，如上圖所示，我們?cè)?K8s 系統(tǒng)的關(guān)鍵位置對(duì)關(guān)鍵行為行為進(jìn)行了埋點(diǎn)，針對(duì)性的制定了限流及熔斷的策略，使得整個(gè)系統(tǒng)即使在出現(xiàn)極端錯(cuò)誤的場(chǎng)景下，也能夠最大化的保護(hù)其上運(yùn)行的業(yè)務(wù)。

自愈能力升級(jí)

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

但是這種方式有一個(gè)嚴(yán)重的問題，因?yàn)槿萜髡{(diào)度平臺(tái)無法自主地去觸發(fā)容器的擴(kuò)縮容，而需要和一個(gè)個(gè)運(yùn)維平臺(tái)來做復(fù)雜的聯(lián)動(dòng)，上層運(yùn)維系統(tǒng)也因?yàn)樾枰兄降讓踊A(chǔ)設(shè)施的信息，從而導(dǎo)致進(jìn)行了很多重復(fù)建設(shè)的工作。

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

我們解決這一問題的思路是通過 K8s 中提供了容器命令以及生命周期鉤子，將啟動(dòng)應(yīng)用以及檢查應(yīng)用啟動(dòng)狀態(tài)這一正個(gè)流程內(nèi)置到 pod 中，包括與監(jiān)控、VIP、服務(wù)中心、配置中心等基礎(chǔ)設(shè)施的交互，通過 Pod 實(shí)現(xiàn)容器與應(yīng)用實(shí)例的生命周期統(tǒng)一。

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

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

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

通過這種方式，構(gòu)建了整個(gè)機(jī)器故障自愈的體系，高效的串聯(lián)起包括機(jī)器鎖定、應(yīng)用驅(qū)逐、機(jī)器線下、異常修復(fù)等流程，確保了集群宿主機(jī)的在線率以及業(yè)務(wù)的可用性。未來，我們期望通過將 operator 編寫標(biāo)準(zhǔn)化的方式去推動(dòng)多個(gè)運(yùn)維平臺(tái)的基礎(chǔ)運(yùn)維能力能夠被最大化的復(fù)用，減少重復(fù)建設(shè)的成本。

不可變基礎(chǔ)設(shè)施

第三個(gè)重要的能力升級(jí)是對(duì)不可變基礎(chǔ)設(shè)施的升級(jí)。

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

而 K8s 更進(jìn)一步，通過將不同用途的 Docker 容器組裝在一起成為一個(gè) pod，通常情況下在升級(jí) pod 時(shí)需要整個(gè)的銷毀重建，從而確保應(yīng)用鏡像、卷、資源規(guī)格的一致性。在落地 K8s 的過程中，堅(jiān)持了不可變基礎(chǔ)設(shè)施的設(shè)計(jì)理念，通過 K8s pod 將原本運(yùn)行在一個(gè)富容器中的應(yīng)用與運(yùn)維基礎(chǔ)組件分離到不同的容器中，并通過升級(jí)容器鏡像的方式完成應(yīng)用的升級(jí)。

這里有一個(gè)概念需要澄清，并不是使用 K8s 就等于踐行了不可變基礎(chǔ)設(shè)施的理念，而是必須要確保應(yīng)用運(yùn)維通過鏡像升級(jí)而不是動(dòng)態(tài)發(fā)布文件的方式完成，而事實(shí)上因?yàn)橐恍v史原因，這一用法在行業(yè)中普遍存在。

當(dāng)然，與 K8s 有所不同的是，我們并未強(qiáng)制堅(jiān)持 pod 的不可變而是取了一個(gè)折中的方式，即堅(jiān)持容器不可變。

原因是我們將應(yīng)用容器與運(yùn)維基礎(chǔ)設(shè)施容器分離之后，運(yùn)維容器作為應(yīng)用容器的 sidecar 容器，其擁有著不同的版本迭代策略。應(yīng)用容器由應(yīng)用運(yùn)維人員負(fù)責(zé)發(fā)布，其策略因應(yīng)用的不同而不同，比如電商應(yīng)用使用 StatefulSet 而本地生活使用 Deployment 來管理應(yīng)用，而基礎(chǔ)設(shè)施容器則由基礎(chǔ)設(shè)施運(yùn)維負(fù)責(zé)，其發(fā)布策略與應(yīng)用本身也存在一些差別。

為了解決這個(gè)問題，我們開發(fā)了一個(gè)叫做 SidecarSet 的基礎(chǔ)設(shè)施容器管理模型，它使用同一個(gè)集合統(tǒng)一管理多個(gè)應(yīng)用的運(yùn)維容器，將基礎(chǔ)設(shè)施的變更與應(yīng)用容器的變更進(jìn)行分離，從而支持基礎(chǔ)設(shè)施的快速演進(jìn)。將基礎(chǔ)設(shè)施容器定義從應(yīng)用 pod 中抽離出來后，應(yīng)用管理員不再關(guān)心基礎(chǔ)容器的啟動(dòng)參數(shù)，而是交由基礎(chǔ)設(shè)施運(yùn)維人員通過配置 SidecarSet 自動(dòng)為應(yīng)用注入運(yùn)維容器，簡(jiǎn)化了應(yīng)用運(yùn)維的復(fù)雜性。

可以看到，這種關(guān)注點(diǎn)分離的設(shè)計(jì)，同時(shí)簡(jiǎn)化了應(yīng)用運(yùn)維與基礎(chǔ)設(shè)施運(yùn)維的負(fù)擔(dān)。

總結(jié)與展望

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

我們一直在思考，通過什么樣的方式能夠?qū)⒗锇桶偷膽?yīng)用管理經(jīng)驗(yàn)輸出到更多的場(chǎng)景，解決更多客戶面臨的應(yīng)用管理難題，在企業(yè)全面云化這樣的趨勢(shì)下，如何解決企業(yè)在公有云、私有云、混合云以及多云場(chǎng)景的應(yīng)用管理復(fù)雜性。

正是在這樣的背景下，阿里云與微軟在 2019 年 11 月聯(lián)合推出了一款用于構(gòu)建和交付云原生應(yīng)用的標(biāo)準(zhǔn)規(guī)范，即?Open Application Model（簡(jiǎn)稱 OAM）。

OAM 提出了一種通用的模型，讓各平臺(tái)可以在統(tǒng)一的高層抽象上透出應(yīng)用部署和運(yùn)維能力，解決跨平臺(tái)的應(yīng)用交付問題。同時(shí)，OAM 以標(biāo)準(zhǔn)化的方式溝通和連接應(yīng)用開發(fā)者、運(yùn)維人員、應(yīng)用基礎(chǔ)設(shè)施，讓云原生應(yīng)用交付和管理流程更加連貫、一致。

通過應(yīng)用交付標(biāo)準(zhǔn)化的方法，我們期望未來在云上部署一個(gè)應(yīng)用，就像手機(jī)在應(yīng)用商店中安裝一個(gè)淘寶一樣便捷與高效。

最后，本文提到的阿里巴巴在云原生改造上完成的相關(guān)能力升級(jí)，我們都已經(jīng)或者即將開源到OpenKruise 項(xiàng)目中，歡迎大家關(guān)注與交流！

參與方式：

• 釘釘掃碼進(jìn)入 OAM 項(xiàng)目中文討論群

（釘釘掃碼加入交流群）

• 通過?Gitter 直接參與討論
• OAM 開源實(shí)現(xiàn)地址
• star 一下

云原生實(shí)踐峰會(huì)即將開幕

“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的技術(shù)圈。”

總結(jié)

以上是生活随笔為你收集整理的为什么 K8s 在阿里能成功？| 问底中国 IT 技术演进的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。