為什么 K8s 在阿里能成功巴碗?| 問(wèn)頂中國(guó) IT 技術(shù)演進(jìn)

從 2015 年 Google 牽頭成立 CNCF 以來(lái)良价,云原生技術(shù)開(kāi)始進(jìn)入公眾的視線并取得快速的發(fā)展,到 2018 年包括 Google市咽、AWS施绎、Azure谷醉、Alibaba Cloud 等大型云計(jì)算供應(yīng)商都加入了 CNCF俱尼,云原生技術(shù)也從原來(lái)的應(yīng)用容器化發(fā)展出包括容器遇八、Service Mesh、微服務(wù)货矮、不可變基礎(chǔ)設(shè)施囚玫、Serverless抓督、FaaS 等眾多技術(shù)方向本昏,CFCF 旗下也囊括了越來(lái)多的開(kāi)源項(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 月開(kāi)源 Kubernetes 以后竭恬,在 Redhat痊硕、Microsoft岔绸、Alibaba 等廠商和眾多開(kāi)源愛(ài)好者共同的努力下挡鞍,成長(zhǎng)為如今容器編排領(lǐng)域的事實(shí)標(biāo)準(zhǔn),極大的推動(dòng)了云原生領(lǐng)域的發(fā)展翘县。

今天為大家分享來(lái)自阿里云的 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 年就開(kāi)始探索基于 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)始終存在一些兼容性問(wèn)題酒贬。

在 2013 年隨著 Docker 容器鏡像方案的出現(xiàn)同衣,阿里巴巴技術(shù)人員立即看到了基于容器 + Docker 鏡像技術(shù)的未來(lái)耐齐,開(kāi)始大力投入到這一領(lǐng)域的研究當(dāng)中埠况,到 2015 年 Aliswarm、Zeus夺衍、Hippo 等容器編排系統(tǒng)蓬勃發(fā)展沟沙,各自開(kāi)疆?dāng)U土服務(wù)了阿里巴巴經(jīng)濟(jì)體的一部分業(yè)務(wù)矛紫。諸多的系統(tǒng)在解決了業(yè)務(wù)運(yùn)維成本的同時(shí)颊咬,也帶來(lái)了一定的重復(fù)建設(shè)成本敞临,同時(shí)也導(dǎo)致了阿里巴巴內(nèi)部的資源分布比較分散挺尿,無(wú)法統(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ù)的潛力眷细,以及未來(lái)企業(yè) IT 全面上云的必然趨勢(shì),從 2018 年開(kāi)始轉(zhuǎn)型到 Kubernetes 技術(shù)校读,通過(guò) Kubernetes 擴(kuò)展能力將 Sigma 積累多年的調(diào)度能力通過(guò) Kubernetes 的方式提供出來(lái)祖能。

在 2019 年阿里巴巴宣布全面上云,阿里巴巴開(kāi)始全面擁抱 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 的順暢的購(gòu)物體驗(yàn)立下悍馬功勞赛惩。

為什么 K8s 在阿里能成功

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

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

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

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

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

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

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

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

在阿里巴巴內(nèi)部途戒,即有大量的無(wú)狀態(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)用過(guò)程中仍然會(huì)遇到非常多的實(shí)際問(wèn)題抹蚀。

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

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

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

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

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

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

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

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

在落地 K8s 的過(guò)程中,我們主要面臨著兩大難題:

  1. 其一阅虫,上層多樣的業(yè)務(wù)運(yùn)維平臺(tái)工猜;

為了支撐阿里巴巴內(nèi)部多樣的業(yè)務(wù)形態(tài)家制,在內(nèi)部發(fā)展出來(lái)了多個(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)過(guò)程中意推,如何牽引整個(gè)運(yùn)維體系升級(jí)的同時(shí)并保持多個(gè)業(yè)務(wù)的平臺(tái)及其上業(yè)務(wù)的穩(wěn)定性,這是一個(gè)巨大的工程儡毕。

  1. 其二永毅,隨著阿里巴巴經(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í)踐過(guò)程中,有一個(gè)問(wèn)題始終縈繞在工程師頭腦中堂湖,在阿里巴巴這么大體量状土、這么復(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è)問(wèn)題的一些思考拦焚,特別是經(jīng)過(guò)了今年的 雙11 考驗(yàn)后耕漱,這個(gè)問(wèn)題的答案基本上得到了工程師群里的集體認(rèn)可抬伺。

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

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

在傳統(tǒng)的運(yùn)維體系下钥屈,應(yīng)用的變更都是運(yùn)維通過(guò)創(chuàng)建操作工單發(fā)起工作流坝辫,繼而對(duì)容器平臺(tái)發(fā)起一個(gè)個(gè)的變更來(lái)完成的。比如升級(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)控開(kāi)管肯腕、鏡像拉取、容器啟停姊途、服務(wù)注冊(cè)、配置推送等等捷兰,如果一切正常該流程會(huì)按預(yù)期有序的進(jìn)行。

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

  1. 其一是重試帶來(lái)的效率問(wèn)題囊颅;

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

  1. 其二是失敗帶來(lái)的一致性問(wèn)題窑眯;

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

  1. 第三是應(yīng)用并發(fā)變更沖突問(wèn)題括眠。

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

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

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

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

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

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

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

為了提高應(yīng)用發(fā)布的效率和資源的確定性帘营,開(kāi)發(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ā)布的過(guò)程中預(yù)先下載并解壓即將要發(fā)布的容器鏡像,從而大幅提高應(yīng)用發(fā)布的效率驾讲。

在面向終態(tài)的應(yīng)用管理中,復(fù)雜的運(yùn)維過(guò)程被 K8s 內(nèi)部所實(shí)現(xiàn)时迫,K8s根據(jù)用戶的期望及現(xiàn)狀計(jì)算出需要執(zhí)行的動(dòng)作谓晌,并逐步的變更直到終態(tài)。面向終態(tài)帶來(lá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 中決策分散在眾多的模塊中,所帶來(lái)的問(wèn)題是系統(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)來(lái)完成的,這種分層的方法給了運(yùn)維系統(tǒng)最大的自由度学少,也在容器化后促進(jìn)了阿里巴巴的容器生態(tài)繁榮秧骑。

但是這種方式有一個(gè)嚴(yán)重的問(wèn)題,因?yàn)槿萜髡{(diào)度平臺(tái)無(wú)法自主地去觸發(fā)容器的擴(kuò)縮容阀坏,而需要和一個(gè)個(gè)運(yùn)維平臺(tái)來(lá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)過(guò)了細(xì)心的設(shè)計(jì)與大量的投入其工作效率也不高,嚴(yán)重妨礙宿主機(jī)發(fā)生故障沸移、重啟,容器中進(jìn)程發(fā)生崩潰网沾、卡住等異常時(shí)的自愈修復(fù)效率蕊爵,同時(shí)也讓?xiě)?yīng)用彈性伸縮的實(shí)現(xiàn)變得非常的復(fù)雜和低效攒射。

我們解決這一問(wèn)題的思路是通過(guò) K8s 中提供了容器命令以及生命周期鉤子,將啟動(dòng)應(yīng)用以及檢查應(yīng)用啟動(dòng)狀態(tài)這一正個(gè)流程內(nèi)置到 pod 中饲齐,包括與監(jiān)控鸦概、VIP、服務(wù)中心先慷、配置中心等基礎(chǔ)設(shè)施的交互咨察,通過(guò) 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 框架容器以及客戶端代碼組成齐饮,通過(guò)對(duì)通用的控制器能力的抽象,包括:事件通知沈矿、灰度管理咬腋、版本控制、緩存陵像、命令管道等能力的封裝集成寇壳,支持多語(yǔ)言編寫(xiě)operator,使得開(kāi)發(fā)者無(wú)需要理解 K8s 的眾多的接口細(xì)節(jié)及錯(cuò)誤處理泞歉,從而降低了基于 operator 的自動(dòng)化運(yùn)維能力的開(kāi)發(fā)難度匿辩,使得越來(lái)越多的運(yùn)維能力通過(guò)operator 的方式沉淀到 K8s 生態(tài)體系中來(lái),讓更多的有狀態(tài)應(yīng)用能夠自動(dòng)化地部署挺庞,提高整個(gè)運(yùn)維體系的運(yùn)轉(zhuǎn)效率稼病。

通過(guò)這種方式,構(gòu)建了整個(gè)機(jī)器故障自愈的體系援制,高效的串聯(lián)起包括機(jī)器鎖定芍瑞、應(yīng)用驅(qū)逐、機(jī)器線下寻歧、異常修復(fù)等流程秩仆,確保了集群宿主機(jī)的在線率以及業(yè)務(wù)的可用性。未來(lái)噪珊,我們期望通過(guò)將 operator 編寫(xiě)標(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)用交付的形式,通過(guò)把應(yīng)用的二進(jìn)制空繁、配置朱庆、依賴文件在構(gòu)建過(guò)程中打到一個(gè)鏡像中,從而確保了應(yīng)用被一次構(gòu)建出來(lái)之后在多個(gè)環(huán)境中交付的確定性傲诵,避免了環(huán)境不一致帶來(lái)的諸多問(wèn)題箱硕。

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

這里有一個(gè)概念需要澄清勤晚,并不是使用 K8s 就等于踐行了不可變基礎(chǔ)設(shè)施的理念,而是必須要確保應(yīng)用運(yùn)維通過(guò)鏡像升級(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 來(lái)管理應(yīng)用,而基礎(chǔ)設(shè)施容器則由基礎(chǔ)設(shè)施運(yùn)維負(fù)責(zé)样勃,其發(fā)布策略與應(yīng)用本身也存在一些差別性芬。

為了解決這個(gè)問(wèn)題,我們開(kāi)發(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 中抽離出來(lái)后,應(yīng)用管理員不再關(guān)心基礎(chǔ)容器的啟動(dòng)參數(shù)瞎惫,而是交由基礎(chǔ)設(shè)施運(yùn)維人員通過(guò)配置 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é)與展望

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

我們一直在思考于游,通過(guò)什么樣的方式能夠?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)用交付問(wèn)題实辑。同時(shí),OAM 以標(biāo)準(zhǔn)化的方式溝通和連接應(yīng)用開(kāi)發(fā)者摄乒、運(yùn)維人員婿奔、應(yīng)用基礎(chǔ)設(shè)施,讓云原生應(yīng)用交付和管理流程更加連貫、一致如叼。

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

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

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末之斯,一起剝皮案震驚了整個(gè)濱河市遣铝,隨后出現(xiàn)的幾起案子莉擒,更是在濱河造成了極大的恐慌啰劲,老刑警劉巖檀何,帶你破解...
    沈念sama閱讀 216,843評(píng)論 6 502
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場(chǎng)離奇詭異栓辜,居然都是意外死亡藕甩,警方通過(guò)查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,538評(píng)論 3 392
  • 文/潘曉璐 我一進(jìn)店門(mén)狭莱,熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái)腋妙,“玉大人讯榕,你說(shuō)我怎么就攤上這事∮奁ǎ” “怎么了?”我有些...
    開(kāi)封第一講書(shū)人閱讀 163,187評(píng)論 0 353
  • 文/不壞的土叔 我叫張陵送浊,是天一觀的道長(zhǎng)袭景。 經(jīng)常有香客問(wèn)我碍岔,道長(zhǎng),這世上最難降的妖魔是什么蔼啦? 我笑而不...
    開(kāi)封第一講書(shū)人閱讀 58,264評(píng)論 1 292
  • 正文 為了忘掉前任,我火速辦了婚禮饥侵,結(jié)果婚禮上衣屏,老公的妹妹穿的比我還像新娘。我一直安慰自己膨疏,他們只是感情好钻弄,可當(dāng)我...
    茶點(diǎn)故事閱讀 67,289評(píng)論 6 390
  • 文/花漫 我一把揭開(kāi)白布。 她就那樣靜靜地躺著饲帅,像睡著了一般灶泵。 火紅的嫁衣襯著肌膚如雪对途。 梳的紋絲不亂的頭發(fā)上,一...
    開(kāi)封第一講書(shū)人閱讀 51,231評(píng)論 1 299
  • 那天深纲,我揣著相機(jī)與錄音劲妙,去河邊找鬼儒喊。 笑死,一個(gè)胖子當(dāng)著我的面吹牛侨颈,可吹牛的內(nèi)容都是我干的芯义。 我是一名探鬼主播,決...
    沈念sama閱讀 40,116評(píng)論 3 418
  • 文/蒼蘭香墨 我猛地睜開(kāi)眼耘分,長(zhǎng)吁一口氣:“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼!你這毒婦竟也來(lái)了央渣?” 一聲冷哼從身側(cè)響起渴频,我...
    開(kāi)封第一講書(shū)人閱讀 38,945評(píng)論 0 275
  • 序言:老撾萬(wàn)榮一對(duì)情侶失蹤,失蹤者是張志新(化名)和其女友劉穎拔第,沒(méi)想到半個(gè)月后场钉,有當(dāng)?shù)厝嗽跇?shù)林里發(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 45,367評(píng)論 1 313
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡春叫,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 37,581評(píng)論 2 333
  • 正文 我和宋清朗相戀三年暂殖,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了当纱。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片坡氯。...
    茶點(diǎn)故事閱讀 39,754評(píng)論 1 348
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡,死狀恐怖手形,靈堂內(nèi)的尸體忽然破棺而出悯恍,到底是詐尸還是另有隱情,我是刑警寧澤瞬欧,帶...
    沈念sama閱讀 35,458評(píng)論 5 344
  • 正文 年R本政府宣布罢防,位于F島的核電站,受9級(jí)特大地震影響野建,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜贬墩,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,068評(píng)論 3 327
  • 文/蒙蒙 一陶舞、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧唠粥,春花似錦停做、人聲如沸。這莊子的主人今日做“春日...
    開(kāi)封第一講書(shū)人閱讀 31,692評(píng)論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)。三九已至钠右,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間忘蟹,已是汗流浹背媚值。 一陣腳步聲響...
    開(kāi)封第一講書(shū)人閱讀 32,842評(píng)論 1 269
  • 我被黑心中介騙來(lái)泰國(guó)打工, 沒(méi)想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留垃你,地道東北人。 一個(gè)月前我還...
    沈念sama閱讀 47,797評(píng)論 2 369
  • 正文 我出身青樓少辣,卻偏偏與公主長(zhǎng)得像羡蛾,于是被迫代替她去往敵國(guó)和親。 傳聞我的和親對(duì)象是個(gè)殘疾皇子忙干,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 44,654評(píng)論 2 354

推薦閱讀更多精彩內(nèi)容