從 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è)方面季惯。
- 首先是其在誕生之初就為云時(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è)方案忍抽。
- 其次唆阿，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í)踐原則。
- 第三闷游，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ò)程中，我們主要面臨著兩大難題：
- 其一阅虫，上層多樣的業(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è)巨大的工程儡毕。
- 其二永毅，隨著阿里巴巴經(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)幻工。
- 其一是重試帶來(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)溺森。
- 其二是失敗帶來(lái)的一致性問(wèn)題窑眯；
對(duì)于發(fā)布異常的容器磅甩，在工單結(jié)束之后通常只能通過(guò)外圍鏈路巡檢的方式來(lái)治理姥卢，而事實(shí)上通常的巡檢是依賴運(yùn)維人員手工操作的，帶來(lái)了極大的人工成本和不確定性却妨。
- 第三是應(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)注與交流！
