K8s 集群節(jié)點(diǎn)在線率達(dá)到 99.9% 以上，擴(kuò)容效率提升 50%，我們做了這 3 個(gè)深度改造

點(diǎn)擊下載《不一樣的 雙11 技術(shù)：阿里巴巴經(jīng)濟(jì)體云原生實(shí)踐》

cdn.com/2d3f2c0a733aa3bc75c82319f10a13c2f82b3771.jpeg">

本文節(jié)選自《不一樣的 雙11 技術(shù)：阿里巴巴經(jīng)濟(jì)體云原生實(shí)踐》一書，點(diǎn)擊上方圖片即可下載！

作者 | 張振（守辰）阿里云云原生應(yīng)用平臺(tái)高級(jí)技術(shù)專家

導(dǎo)讀：2019 年阿里巴巴核心系統(tǒng) 100% 以云原生方式上云，完美地支撐了 雙11 大促。這次上云的姿勢很不一般，不僅是擁抱了 Kubernetes，而且還以擁抱 Kubernetes 為契機(jī)進(jìn)行了一系列對運(yùn)維體系的深度改造。

Kubernetes?作為云原生的最佳實(shí)踐，已經(jīng)成為了事實(shí)上的容器編排引擎標(biāo)準(zhǔn)，Kubernetes 在阿里巴巴集團(tuán)落地主要經(jīng)歷了四個(gè)階段：

• 研發(fā)和探索：2017 年下半年阿里巴巴集團(tuán)開始嘗試使用?Kubernetes api 來改造內(nèi)部自研平臺(tái)，并開始了對應(yīng)用交付鏈路的改造，以適配?Kubernetes；
• 初步灰度： ?2018 年下半年阿里巴巴集團(tuán)和螞蟻金服共同投入 Kubernetes 技術(shù)生態(tài)的研發(fā)，力求通過 Kubernetes 替換內(nèi)部自研平臺(tái)，實(shí)現(xiàn)了小規(guī)模的驗(yàn)證，支撐了當(dāng)年部分 雙11 的流量；
• 云化灰度： ?2019 年初阿里巴巴經(jīng)濟(jì)體開始進(jìn)行全面上云改造，阿里巴巴集團(tuán)通過重新設(shè)計(jì) Kubernetes 落地方案，適配云化環(huán)境，改造落后運(yùn)維習(xí)慣，在 618 前完成了云化機(jī)房的小規(guī)模驗(yàn)證；
• 規(guī)?；涞兀?019 年 618 之后，阿里巴巴集團(tuán)內(nèi)部開始全面推動(dòng) Kubernetes 落地，在大促之前完成了全部核心應(yīng)用運(yùn)行在 Kubernetes 的目標(biāo)，并完美支撐了 雙11 大考。

在這幾年的實(shí)踐中，一個(gè)問題始終縈繞在各個(gè)架構(gòu)師的頭腦中： 在阿里巴巴這么大體量、這么復(fù)雜的業(yè)務(wù)下， 遺留了大量傳統(tǒng)的運(yùn)維習(xí)慣以及支撐這些習(xí)慣的運(yùn)維體系，落地 Kubernetes?到底要堅(jiān)持什么？要妥協(xié)什么？要改變什么？

本文將分享阿里巴巴這幾年對于這些問題的思考。答案很明顯：擁抱 Kubernetes?本身并不是目的，而是通過擁抱 Kubernetes?撬動(dòng)業(yè)務(wù)的云原生改造，通過 Kubernetes?的能力，治理傳統(tǒng)運(yùn)維體系下的沉疴頑疾，釋放云彈性的能力，為業(yè)務(wù)的應(yīng)用交付解綁提速。

在阿里巴巴的 Kubernetes?落地實(shí)踐中，關(guān)注了下面幾個(gè)關(guān)鍵的云原生改造：

面向終態(tài)改造

在阿里巴巴傳統(tǒng)的運(yùn)維體系下，應(yīng)用的變更都是 PaaS?通過創(chuàng)建操作工單，發(fā)起工作流，繼而對容器平臺(tái)發(fā)起一個(gè)個(gè)的變更來完成的。

當(dāng)應(yīng)用發(fā)布時(shí)， PaaS?會(huì)從數(shù)據(jù)庫中查到應(yīng)用所有相關(guān)的容器，并針對每個(gè)容器，向容器平臺(tái)發(fā)起修改容器鏡像的變更。每一個(gè)變更實(shí)際上也是一個(gè)工作流，涉及到鏡像的拉取、舊容器的停止和新容器的創(chuàng)建。工作流中一旦發(fā)生錯(cuò)誤或者超時(shí)，都需要 PaaS?進(jìn)行重試。一般而言，為了保證工單及時(shí)的完成，重試僅會(huì)執(zhí)行幾次，幾次重試失敗后，只能依靠人工處理。

當(dāng)應(yīng)用縮容時(shí)，PaaS?會(huì)根據(jù)運(yùn)維人員的輸入，指定容器列表進(jìn)行刪除，一旦其中有容器因?yàn)樗拗鳈C(jī)異常的情況下刪除失敗或者超時(shí)，PaaS?只能反復(fù)重試，為了保證工單的結(jié)束，在重試一定次數(shù)后只能認(rèn)為容器刪除成功。如果宿主機(jī)后續(xù)恢復(fù)正常，被“刪除”的容器很有可能依然運(yùn)行著。

傳統(tǒng)的面向過程的容器變更一直存在如下問題無法解決：

• 單個(gè)變更失敗無法保證最終成功

例如，一旦容器鏡像變更失敗，PaaS?無法保證容器鏡像的最終一致；一旦刪除容器失敗，
也無法保證容器最后真的被刪除干凈。兩個(gè)例子都需要通過巡檢來處理不一致的容器。而巡檢任務(wù)因?yàn)閳?zhí)行較少，其正確性和及時(shí)性都很難保證；

• 多個(gè)變更會(huì)發(fā)生沖突

例如應(yīng)用的發(fā)布和應(yīng)用的擴(kuò)容過程需要加鎖，否則會(huì)出現(xiàn)新擴(kuò)的容器鏡像未更新的情況。而一旦對變更進(jìn)行加鎖，變更的效率又會(huì)大幅下降。

Kubernetes?的能力提供了解決這個(gè)問題的機(jī)會(huì)。Kubernetes 的 workload?提供了聲明式的 API?來修改應(yīng)用的實(shí)例數(shù)和版本，workload?的控制器可以監(jiān)聽 pod?的實(shí)際情況，保證應(yīng)用 pod?的實(shí)例數(shù)量和版本符合終態(tài)，避免了并發(fā)擴(kuò)容和發(fā)布的沖突問題。Kubernetes 的 kubelet 會(huì)依據(jù) pod?的 spec，反復(fù)嘗試啟動(dòng) pod，直到 pod?符合 spec?描述的終態(tài)。重試由容器平臺(tái)內(nèi)部實(shí)現(xiàn)，不再和應(yīng)用的工單狀態(tài)綁定。

自愈能力改造

在阿里巴巴傳統(tǒng)的運(yùn)維體系下，容器平臺(tái)僅生產(chǎn)資源，應(yīng)用的啟動(dòng)以及服務(wù)發(fā)現(xiàn)是在容器啟動(dòng)后由 PaaS?系統(tǒng)來執(zhí)行的，這種分層的方法給了 PaaS?系統(tǒng)最大的自由，也在容器化后促進(jìn)了阿里巴巴第一波容器生態(tài)的繁榮。但是這種方式有一個(gè)嚴(yán)重的問題，即：
容器平臺(tái)無法獨(dú)立地去觸發(fā)容器的擴(kuò)縮容，需要和一個(gè)個(gè) PaaS?來做復(fù)雜的聯(lián)動(dòng)，上層 PaaS?也需要做很多重復(fù)的工作。這妨礙了容器平臺(tái)在宿主機(jī)發(fā)生故障、重啟、容器中進(jìn)程發(fā)生異常、卡住時(shí)的高效自愈修復(fù)，也讓彈性擴(kuò)縮容變得非常復(fù)雜。

在?Kubernetes?中通過容器的命令以及生命周期鉤子，可以將 PaaS?啟動(dòng)應(yīng)用以及檢查應(yīng)用啟動(dòng)狀態(tài)的流程內(nèi)置在了 pod?中；另外，通過創(chuàng)建 service?對象，可以將容器和對應(yīng)的服務(wù)發(fā)現(xiàn)機(jī)制關(guān)聯(lián)起來，從而實(shí)現(xiàn)容器、應(yīng)用、服務(wù)生命周期的統(tǒng)一。容器平臺(tái)不再僅僅生產(chǎn)資源，而是交付可以直接為業(yè)務(wù)使用的服務(wù)。這極大地簡化了上云之后故障自愈以及自動(dòng)彈性擴(kuò)縮容能力的建設(shè)，
真正地發(fā)揮了云的彈性能力。

另外，在宿主機(jī)發(fā)生故障的情況下，PaaS?傳統(tǒng)上需要先對應(yīng)用進(jìn)行擴(kuò)容，然后才刪除宿主機(jī)上的容器。然而在大規(guī)模的集群下，我們發(fā)現(xiàn)往往會(huì)卡在應(yīng)用擴(kuò)容這步。應(yīng)用資源額度可能不夠，集群內(nèi)滿足應(yīng)用調(diào)度限制的空閑資源也可能不夠，無法擴(kuò)容就無法對宿主機(jī)上的容器進(jìn)行驅(qū)逐，進(jìn)而也無法對異常的宿主機(jī)進(jìn)行送修，久而久之，整個(gè)集群很容易就陷入故障機(jī)器一大堆，想修修不了、想騰騰不動(dòng)的困境之中。

在?Kubernetes?中對于故障機(jī)的處理要“簡單和粗暴”得多，不再要求對應(yīng)用先擴(kuò)容，而是直接把故障機(jī)上的容器進(jìn)行刪除，刪除后才由負(fù)載控制器進(jìn)行擴(kuò)容。這種方案乍一聽簡直膽大妄為，落地?Kubernetes?的時(shí)候很多 PaaS?的同學(xué)都非常排斥這種方法，認(rèn)為這會(huì)嚴(yán)重影響業(yè)務(wù)的穩(wěn)定性。事實(shí)上，絕大多數(shù)核心的業(yè)務(wù)應(yīng)用都維護(hù)著一定的冗余容量，以便全局的流量切換或者應(yīng)對突發(fā)的業(yè)務(wù)流量，臨時(shí)刪除一定量的容器根本不會(huì)造成業(yè)務(wù)的容量不足。

我們所面臨的關(guān)鍵問題是如何確定業(yè)務(wù)的可用容量，當(dāng)然這是個(gè)更難的問題，但對于自愈的場景完全不需要準(zhǔn)確的容量評估，只需要一個(gè)可以推動(dòng)自愈運(yùn)轉(zhuǎn)的悲觀估計(jì)就可以。在?Kubernetes?中可以通過 PodDisruptionBudget?來定量地描述對應(yīng)用的可遷移量，例如可以設(shè)置對應(yīng)用進(jìn)行驅(qū)逐的并發(fā)數(shù)量或者比例。這個(gè)值可以參考發(fā)布時(shí)的每批數(shù)量占比來設(shè)置。假如應(yīng)用發(fā)布一般分 10?批，那么可以設(shè)置 PodDisruptionBudget?中的 maxUnavailable?為 10%（對于比例，如果應(yīng)用只有 10?個(gè)以內(nèi)的實(shí)例，Kubernetes?還是認(rèn)為可以驅(qū)逐 1?個(gè)實(shí)例）。萬一應(yīng)用真的一個(gè)實(shí)例都不允許驅(qū)逐呢？那么對不起，這樣的應(yīng)用是需要改造之后才能享受上云的收益的。一般應(yīng)用可以通過改造自身架構(gòu)，或者通過 operator?來自動(dòng)化應(yīng)用的運(yùn)維操作，從而允許實(shí)例的遷移。<

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

Docker?的出現(xiàn)提供了一種統(tǒng)一的應(yīng)用交付形式，通過把應(yīng)用的二進(jìn)制、配置、依賴統(tǒng)一在構(gòu)建過程中打到了鏡像中，
通過使用新的鏡像創(chuàng)建容器，并刪除掉舊容器就完成了應(yīng)用的變更。Docker?在交付應(yīng)用時(shí)和傳統(tǒng)基于軟件包或者腳本的交付方式有一個(gè)重大區(qū)別，就是強(qiáng)制了容器的不可變，想要變更容器只能通過新創(chuàng)建容器來完成，而每個(gè)新容器都是從應(yīng)用同一個(gè)鏡像創(chuàng)建而來，確保了一致性，從而避免了配置漂移，或者雪花服務(wù)器的問題。

Kubernetes 進(jìn)一步強(qiáng)化了不可變基礎(chǔ)設(shè)施的理念，在默認(rèn)的滾動(dòng)升級(jí)過程中不但不會(huì)變更容器，而且還不會(huì)變更pod。每次發(fā)布，都是通過創(chuàng)建新的?pod，并刪除舊的 pod?來完成，這不僅保證了應(yīng)用的鏡像統(tǒng)一，還保證了數(shù)據(jù)卷、資源規(guī)格以及系統(tǒng)參數(shù)配置都是和應(yīng)用模板的 spec?保持一致。

另外，不少應(yīng)用都有比較復(fù)雜的結(jié)構(gòu)，一個(gè)應(yīng)用實(shí)例可能同時(shí)包含多個(gè)團(tuán)隊(duì)獨(dú)立開發(fā)的組件。 比如一個(gè)應(yīng)用可能包括了業(yè)務(wù)相關(guān)的應(yīng)用程序服務(wù)器，也包括了基礎(chǔ)設(shè)施團(tuán)隊(duì)開發(fā)的日志采集進(jìn)程，甚至還包括了第三方的中間件組件。這些進(jìn)程、組件如果想要獨(dú)立發(fā)布就不能放在一個(gè)應(yīng)用鏡像中，為此?Kubernetes?提供了多容器 pod?的能力，可以在一個(gè) pod?中編排多個(gè)容器，想要發(fā)布單個(gè)組件，只需要修改對應(yīng)容器的鏡像即可。

不過，阿里巴巴傳統(tǒng)的容器形態(tài)是富容器，即應(yīng)用程序服務(wù)器，以及日志采集進(jìn)程等相關(guān)的組件都部署在一個(gè)大的系統(tǒng)容器中，這造成了日志采集等組件的資源消耗無法單獨(dú)限制，也無法方便地進(jìn)行獨(dú)立升級(jí)。因此，在阿里巴巴這次上云中，開始把系統(tǒng)容器中除業(yè)務(wù)應(yīng)用外的其他組件都拆分到獨(dú)立的 sidecar?容器，我們稱之為輕量化容器改造。改造后，一個(gè) pod?內(nèi)會(huì)包括一個(gè)運(yùn)行業(yè)務(wù)的主容器、一個(gè)運(yùn)行著各種基礎(chǔ)設(shè)施 agent?的運(yùn)維容器，以及服務(wù)網(wǎng)格等的sidecar容器。輕量化容器之后， 業(yè)務(wù)的主容器就能以比較低的開銷運(yùn)行業(yè)務(wù)服務(wù)，從而更方便進(jìn)行 serverless?的相關(guān)改造。

不過，Kubernetes 默認(rèn)的滾動(dòng)升級(jí)過程過于僵硬地執(zhí)行了不可變基礎(chǔ)設(shè)施的理念，導(dǎo)致對多容器 pod?的能力支持有嚴(yán)重的缺失。雖然可以在一個(gè) pod?中編排多個(gè)容器，但如果要發(fā)布 pod?中的一個(gè)容器，在實(shí)際執(zhí)行發(fā)布時(shí)，不僅會(huì)重建待發(fā)布的容器，還會(huì)把整個(gè) pod?都刪除，而后重調(diào)度、再重建。這意味著假如要升級(jí)基礎(chǔ)設(shè)施的日志采集組件，會(huì)導(dǎo)致其他組件，特別是業(yè)務(wù)的應(yīng)用服務(wù)器被一起刪除重啟，從而干擾到正常的業(yè)務(wù)運(yùn)行。因此，多個(gè)組件的變更依然沒有解耦。

對業(yè)務(wù)而言，假如 pod?中有本地緩存的組件，而每次業(yè)務(wù)的發(fā)布都會(huì)重啟緩存進(jìn)程，這會(huì)導(dǎo)致業(yè)務(wù)發(fā)布期間緩存的命中率大幅下降，影響性能甚至用戶的體驗(yàn)；另外，如果基礎(chǔ)設(shè)施、中間件等團(tuán)隊(duì)的組件升級(jí)都和業(yè)務(wù)的組件升級(jí)綁定在一起，這會(huì)給技術(shù)的迭代更新帶來巨大的阻礙。假設(shè)負(fù)責(zé)中間件的團(tuán)隊(duì)推出了新的 service mesh 版本， 而為了升級(jí) mesh 還需要央求一個(gè)個(gè)業(yè)務(wù)發(fā)布才能更新 mesh 組件，那么中間件的技術(shù)升級(jí)就會(huì)大大減速。

因此，相比 pod?層次的不可變，我們認(rèn)為堅(jiān)持容器級(jí)別的不可變原則，更能發(fā)揮?Kubernetes?多容器 pod?的技術(shù)優(yōu)勢。為此，我們建設(shè)了支持應(yīng)用發(fā)布時(shí)只原地修改 pod?中部分容器的能力，特別地建設(shè)了支持容器原地升級(jí)的工作負(fù)載控制器，并替換?Kubernetes?默認(rèn)的 deployment?和 statefulset?控制器作為內(nèi)部的主要工作負(fù)載。

另外，還建設(shè)了支持跨應(yīng)用進(jìn)行 sidecar?容器升級(jí)的 sidecarset， 方便進(jìn)行基礎(chǔ)設(shè)施以及中間件組件的升級(jí)。此外，通過支持原地升級(jí)還帶來了集群分布確定性、加速鏡像下載等的額外優(yōu)勢。這部分能力，我們已經(jīng)通過?OpenKruise 項(xiàng)目開源出來。OpenKruise 中的 Kruise 是 cruise的諧音，'K' for Kubernetes, 寓意 Kubernetes 上應(yīng)用的自動(dòng)巡航，滿載著阿里巴巴多年應(yīng)用部署管理經(jīng)驗(yàn)和阿里巴巴經(jīng)濟(jì)體云原生化歷程的最佳實(shí)踐。目前，OpenKruise 正在計(jì)劃發(fā)布更多的 Controller 來覆蓋更多的場景和功能，比如豐富的發(fā)布策略、金絲雀發(fā)布、藍(lán)綠發(fā)布、分批發(fā)布等等。

總結(jié)

今年我們實(shí)現(xiàn)了 Kubernetes 的規(guī)模化落地，經(jīng)受了 雙11 大促真實(shí)場景的考驗(yàn)。像阿里巴巴這樣有著大量存量應(yīng)用的場景，落地 K8s 并沒有捷徑，我們經(jīng)受住了快速規(guī)?；涞氐恼T惑，沒有選擇兼容和妥協(xié)落后的運(yùn)維習(xí)慣，而是選擇深蹲打好基礎(chǔ)、選擇深挖云原生價(jià)值。接下來，我們將繼續(xù)推動(dòng)更多應(yīng)用的云原生改造，特別是有狀態(tài)應(yīng)用的改造，讓有狀態(tài)應(yīng)用的部署和運(yùn)維更加高效；另外，還將推動(dòng)整個(gè)應(yīng)用交付鏈路的云原生改造，讓應(yīng)用交付更加高效和標(biāo)準(zhǔn)化。

本書亮點(diǎn)

• 雙11 超大規(guī)模 K8s 集群實(shí)踐中，遇到的問題及解決方法詳述
• 云原生化最佳組合：Kubernetes+容器+神龍，實(shí)現(xiàn)核心系統(tǒng) 100% 上云的技術(shù)細(xì)節(jié)
• 雙 11 Service Mesh 超大規(guī)模落地解決方案

“ 阿里巴巴云原生微信公眾號(hào)（ID：Alicloudnative）關(guān)注微服務(wù)、Serverless、容器、Service Mesh等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的技術(shù)公眾號(hào)?！?/p>

更多相關(guān)信息，關(guān)注“阿里巴巴云原生”。