5月31日，CSDN云原生系列在線峰會(huì)第6期“K8s大規(guī)模應(yīng)用和深度實(shí)踐峰會(huì)”正式舉辦，火山引擎資深云原生架構(gòu)師李玉光在活動(dòng)中為廣大觀眾解析了《字節(jié)跳動(dòng)大規(guī)模K8s集群管理實(shí)踐》。本文基于演講內(nèi)容整理。

字節(jié)跳動(dòng)云原生體系

字節(jié)跳動(dòng)內(nèi)部云原生技術(shù)的使用貫穿組織技術(shù)體系各層面，整體如下圖所示：

● 研發(fā)體系層：包括 CI/CD流水線、可觀測(cè)平臺(tái)、研發(fā)效能平臺(tái)、混沌工程平臺(tái)等；

● 服務(wù)平臺(tái)層：包括云原生框架體系、服務(wù)網(wǎng)格、無(wú)服務(wù)器計(jì)算以及邊緣計(jì)算等；

● 基礎(chǔ)設(shè)施層：包括容器管理平臺(tái)、計(jì)算存儲(chǔ)和網(wǎng)絡(luò)的 Paas平臺(tái)；

● SRE 體系：通過(guò) SRE 整體能力的建設(shè)把研發(fā)體系到基礎(chǔ)設(shè)施管理流程串聯(lián)起來(lái)；

● 云原生安全：涵蓋業(yè)務(wù)安全、身份安全、網(wǎng)絡(luò)安全等云原生安全能力。

這些能力的建設(shè)主要根據(jù)業(yè)務(wù)需求逐步推進(jìn)，演進(jìn)過(guò)程如下圖所示：

● 2015 – 2017 年：主要業(yè)務(wù)為今日頭條，面對(duì)各種新聞客戶端應(yīng)用的激烈競(jìng)爭(zhēng)，敏捷迭代盡快將產(chǎn)品的功能推向市場(chǎng)十分重要。為了提供快捷高效的應(yīng)用部署方案，公司在 2016 年啟動(dòng) TCE 平臺(tái)的建設(shè)。當(dāng)時(shí)TCE專注于服務(wù)的生命周期管理，如新建、升級(jí)、回滾、高可用、彈性擴(kuò)展的容器服務(wù)，如今TCE 發(fā)展成龐大的私有云平臺(tái)。

● 2018 年：?jiǎn)?dòng)了 Service Mesh 的原型開(kāi)發(fā)。當(dāng)時(shí)字節(jié)跳動(dòng)內(nèi)部多語(yǔ)言版本造成微服務(wù)治理框架不一樣，既無(wú)法做到統(tǒng)一管理，又會(huì)有很多重復(fù)造輪子的工作。為了統(tǒng)一公司內(nèi)的工具體系，同時(shí)啟動(dòng)了計(jì)算 PaaS 和存儲(chǔ) PaaS 的建設(shè)，開(kāi)始統(tǒng)一公司級(jí)別的 SRE 體系和監(jiān)控中心建設(shè)。

● 2019 年：公司級(jí)服務(wù)樹(shù)實(shí)現(xiàn)統(tǒng)一，后續(xù)可以基于服務(wù)維度出賬單，以應(yīng)用視角管理資源。Service Mesh 經(jīng)過(guò)開(kāi)發(fā)及試用階段，有了全量推廣。云基礎(chǔ)視角來(lái)看，抖音在 2018 至 2020 年間發(fā)展快速，成本不斷增加，服務(wù)器規(guī)模體量越來(lái)越大，團(tuán)隊(duì)關(guān)注重點(diǎn)轉(zhuǎn)向資源利用率的提升，推進(jìn)在離線混部架構(gòu)；為應(yīng)對(duì)大規(guī)模集群?jiǎn)栴}，第一代的集群聯(lián)邦解決方案實(shí)施。從 SRE 的視角來(lái)看，平臺(tái)集成了各種 PaaS 能力，包括數(shù)據(jù)、運(yùn)維、監(jiān)控等能力，構(gòu)建了統(tǒng)一的部署監(jiān)控、報(bào)警治理一體化的工具矩陣；“推廣搜”的物理機(jī)服務(wù)與在線微服務(wù)進(jìn)行全面融合，實(shí)現(xiàn)統(tǒng)一容器化調(diào)度并達(dá)到全量托管。

● 2020 年：由于業(yè)務(wù)天然依賴邊緣渲染，團(tuán)隊(duì)強(qiáng)化了邊緣計(jì)算能力；各種底層軟硬件也進(jìn)行了優(yōu)化，比如打造智能網(wǎng)卡、自研 DPU、優(yōu)化 SSD 控制器等；其次，為更好的在離線融合以及解決第一代集群聯(lián)邦的問(wèn)題，團(tuán)隊(duì)構(gòu)建了第二代的集群聯(lián)邦。繼續(xù)推進(jìn)在離線混部架構(gòu)，通過(guò)自研的融合調(diào)度器豐富了混部調(diào)度能力和資源管控，進(jìn)一步提升資源調(diào)度效率，實(shí)現(xiàn)了常態(tài)化混部。完成數(shù)據(jù)庫(kù)、緩存等存儲(chǔ)系統(tǒng)云原生化改造。在 SRE 體系上，由于已經(jīng)有了工具基礎(chǔ)，會(huì)關(guān)注如何更快速定位問(wèn)題，因此進(jìn)行了底層的容器監(jiān)控優(yōu)化，如利用 EBPF 實(shí)現(xiàn)內(nèi)核級(jí)別的監(jiān)控。同時(shí)對(duì)容器隔離進(jìn)行了優(yōu)化。

● 2021 年：除了針對(duì)微服務(wù)框架、服務(wù)治理、編排調(diào)度，監(jiān)控運(yùn)維等方面架構(gòu)的繼續(xù)優(yōu)化，最重要的是：云基礎(chǔ)產(chǎn)品開(kāi)始面向 ToB，火山引擎正式推出公有云服務(wù)。

截至2021年底，字節(jié)跳動(dòng)已經(jīng)建設(shè)了完善的云原生基礎(chǔ)設(shè)施：擁有 200 多個(gè)生產(chǎn)集群，共計(jì) 50 萬(wàn)節(jié)點(diǎn)，容器數(shù)超過(guò) 1000 萬(wàn)；擁有 10 萬(wàn)多在線微服務(wù)，平均每日變更數(shù)達(dá) 2 萬(wàn)次，離線任務(wù)數(shù)超過(guò) 1.4 億。

字節(jié)跳動(dòng)大規(guī)模K8s混合部署實(shí)踐

字節(jié)跳動(dòng)私有云平臺(tái) TCE 的底層使用 K8s 作為編排調(diào)度的系統(tǒng)，字節(jié)內(nèi)部幾乎所有無(wú)狀態(tài)服務(wù)都以容器的形式部署在 TCE 上，無(wú)狀態(tài)服務(wù)主要包括各種微服務(wù)和算法服務(wù)等。隨著業(yè)務(wù)的增長(zhǎng)，TCE 上接管的服務(wù)數(shù)量越來(lái)越多，集群規(guī)模越來(lái)越龐大，導(dǎo)致了資源成本的不斷增長(zhǎng)，因此必然要關(guān)注集群的整體資源利用率的問(wèn)題。

為了解決資源利用率的問(wèn)題，首先要對(duì)業(yè)務(wù)的流量特點(diǎn)進(jìn)行分析。

上圖所示，在線業(yè)務(wù)的一個(gè)特點(diǎn)是每天請(qǐng)求量有明顯波峰波谷；同時(shí)，業(yè)務(wù)會(huì)傾向于申請(qǐng)比實(shí)際需求更多的資源以確保服務(wù)的穩(wěn)定性，但這也會(huì)導(dǎo)致集群的整體資源利用率特別低，造成大量的資源浪費(fèi)。

解決思路

在線業(yè)務(wù)動(dòng)態(tài)超售

針對(duì)上述發(fā)現(xiàn)，實(shí)際做法是實(shí)現(xiàn)在線業(yè)務(wù)的動(dòng)態(tài)超售。動(dòng)態(tài)超售是指動(dòng)態(tài)控制和調(diào)整服務(wù)的資源申請(qǐng)量以減少冗余資源，服務(wù)級(jí)別動(dòng)態(tài)超售的目標(biāo)是在不影響業(yè)務(wù) QoS的前提下提升服務(wù)的資源利用率。實(shí)現(xiàn)方式主要包含：

● 資源控制：通過(guò) SysProbe 組件，收集實(shí)例級(jí)別的容器資源利用率 metrics 和 Pod 的 meta 信息，并將這些推送到 Spark 里面做聚合分析。之后每次服務(wù)上線，業(yè)務(wù)會(huì)通過(guò) TCE Platform 提交一個(gè) DeploymentRequest，包含了業(yè)務(wù)配置的資源申請(qǐng)，TCE U8S 組件會(huì)去查詢 SysProbe 提供的 API，根據(jù)每個(gè)應(yīng)用的歷史數(shù)據(jù)計(jì)算出其實(shí)際需求的資源并作出相應(yīng)的控制。

● 資源調(diào)整：集群里很多長(zhǎng)期不升級(jí)的服務(wù)占用了不少資源，而且資源利用率非常低，但是無(wú)法通過(guò)第一種方式對(duì)其調(diào)整。因此通過(guò) VPA Controller watch 所有的 deployment，一旦發(fā)現(xiàn)有長(zhǎng)期沒(méi)有更新的 deployment，就會(huì)主動(dòng)修改其 request 并進(jìn)行更新。

● 彈性伸縮：最后結(jié)合 POD 的彈性伸縮來(lái)回收流量低谷時(shí)期的資源，從而大幅提升資源利用率。

在離線業(yè)務(wù)混部

下一步需要考慮的是如何利用這部分在線業(yè)務(wù)節(jié)省下來(lái)的資源。因?yàn)樗性诰€業(yè)務(wù)的低谷時(shí)段幾乎都是吻合的，比如在凌晨之后，一般所有在線 APP 的使用頻率都會(huì)減少，因此不能通過(guò)擴(kuò)容在線業(yè)務(wù)的方式來(lái)消耗這部分資源。但是字節(jié)內(nèi)部存在很多離線任務(wù)需要大量的計(jì)算資源去進(jìn)行處理，例如視頻轉(zhuǎn)碼、模型訓(xùn)練等。這些離線任務(wù)對(duì)資源的需求與時(shí)間無(wú)關(guān)，天然適合使用在線閑置資源，開(kāi)啟在離線混部架構(gòu)，能夠把在線業(yè)務(wù)的閑置資源出讓給離線業(yè)務(wù)使用。

字節(jié)的大數(shù)據(jù)業(yè)務(wù)都是基于 Yarn 體系的，在線應(yīng)用和一些 AI 應(yīng)用部署在 K8s 上，最開(kāi)始的時(shí)候我們把 Node manager 做了一些修改之后和 Kubelet 一起部署在了 K8s 的 node 上。總體來(lái)說(shuō)，整個(gè)平臺(tái)是由以 K8s 核心控制面為主的在線編排調(diào)度系統(tǒng)，以 Yarn 為主的離線調(diào)度系統(tǒng)，以及Sysprobe 組件為中心 Hybrid controller 構(gòu)成。離線業(yè)務(wù)混部示意圖如下：

在離線業(yè)務(wù)混部要實(shí)現(xiàn)的效果是：在優(yōu)先滿足在線微服務(wù)的需求的前提下，把剩余資源盡可能多的供給離線業(yè)務(wù)使用，當(dāng)在線業(yè)務(wù)需要更多資源的時(shí)候，可以快速地調(diào)回離線側(cè)的資源。

從具體實(shí)現(xiàn)角度來(lái)說(shuō)，通過(guò) Sysprobe 系統(tǒng)監(jiān)控，獲取單機(jī)層面的各種容器的資源使用情況；通過(guò)機(jī)器學(xué)習(xí)算法，推導(dǎo)出該集群上可以出讓給離線側(cè)去使用的資源；將這些信息傳給 node manager ，動(dòng)態(tài)上報(bào)到中心的 RM 進(jìn)行資源的統(tǒng)一展示。Hybrid controller 主要是負(fù)責(zé)集群整體的容災(zāi)降級(jí)策略和水位控制相關(guān)的事務(wù)。

整個(gè)調(diào)度系統(tǒng)分為三個(gè)層面構(gòu)建：集群層面、節(jié)點(diǎn)層面和內(nèi)核層面，分別承擔(dān)了三種資源調(diào)度的角色。

● 集群層面：K8s Scheduler 和 Yarn 的 ResourceManager 負(fù)責(zé)完成集群層面的調(diào)度，把容器調(diào)度到合適的節(jié)點(diǎn)。

● 節(jié)點(diǎn)層面：但是當(dāng)節(jié)點(diǎn)層面在線業(yè)務(wù)發(fā)生 QoS 抖動(dòng)時(shí)，需要做出更快的響應(yīng)，此時(shí)分鐘級(jí)的調(diào)度響應(yīng)延遲通常是不能接受的。因此，系統(tǒng)在節(jié)點(diǎn)層面進(jìn)行處理，提供了 Sysprobe 的 QoS Controller 組件，動(dòng)態(tài)實(shí)時(shí)地調(diào)整節(jié)點(diǎn)的實(shí)際資源分配。當(dāng)在線業(yè)務(wù)發(fā)生 QoS 抖動(dòng)，需要更多資源時(shí)，能夠快速將離線資源回收回來(lái)，實(shí)現(xiàn)秒級(jí)響應(yīng)。

● 內(nèi)核層面：由于Sysprobe是處于用戶態(tài)的角色，通常也會(huì)受到單機(jī)層面高負(fù)載等異常情況的影響，因此需要在內(nèi)核級(jí)別，比如在 CPU 的調(diào)度器，IO 的調(diào)度器上做更深度的定制。這樣能夠?qū)崿F(xiàn)更強(qiáng)的系統(tǒng)層面的能力，更好地兼顧延遲敏感型的在線微服務(wù)和吞吐型離線任務(wù)對(duì)于計(jì)算資源和網(wǎng)絡(luò)帶寬資源的需求，達(dá)到整體效能的最大化。

由此，初步的在離線混部完成，但還有一些需要繼續(xù)優(yōu)化的內(nèi)容。比如對(duì)于系統(tǒng)而言，資源抽象還不夠完整，只有部分類型的離線業(yè)務(wù)利用了這些不穩(wěn)定的資源；系統(tǒng)各自獨(dú)立，在一個(gè) node 上既部署了 Kubelet 負(fù)責(zé)在線業(yè)務(wù)，又部署了 Node manager 負(fù)責(zé)離線任務(wù)，資源管理體系分離，上層平臺(tái)獨(dú)立建設(shè)，底層服務(wù)器供給運(yùn)維分開(kāi)，導(dǎo)致更大范圍的共池復(fù)用比較困難。

統(tǒng)一資源池，常態(tài)混部

為應(yīng)對(duì)上述挑戰(zhàn)，新的融合調(diào)度器被開(kāi)發(fā)出來(lái)。其能統(tǒng)一管理在離線資源，后續(xù)也能支持更多資源的管理和更多類型任務(wù)的調(diào)度，如下圖所示：

首先需要通過(guò) K8s 管理離線應(yīng)用，這就需要支持 Yarn 的 Gang scheduler以及其他調(diào)度算法。因此選擇去掉 Yarn 的 Slave 節(jié)點(diǎn)相關(guān)的管控邏輯，將其 Resource Manager Operator 化；相應(yīng)的調(diào)度邏輯下沉到自研 K8s 調(diào)度器 Godel Scheduler，只保留對(duì)應(yīng)的離線作業(yè)生命周期管理以及周邊功能，進(jìn)而實(shí)現(xiàn)離在線無(wú)縫遷移和并池的能力；將公司所有 Yarn 上的存量大數(shù)據(jù)業(yè)務(wù)無(wú)縫遷移至新的調(diào)度平臺(tái)，來(lái)實(shí)現(xiàn)在離線資源池的統(tǒng)一。最后，獲取了單集群的在離線統(tǒng)一調(diào)度能力后，就可以通過(guò)集群聯(lián)邦對(duì)多個(gè)集群的在離線資源進(jìn)行統(tǒng)一管理。

聯(lián)邦化：Global Scheduling 和 Quota

在 2019 年引入了第一代聯(lián)邦系統(tǒng)，實(shí)現(xiàn)了超大規(guī)模集群管理，提供了以下能力：

● 用戶體驗(yàn)：通過(guò)資源池化，SRE 團(tuán)隊(duì)不需要管理自己的集群節(jié)點(diǎn)，降低維護(hù)成本；集群版本升級(jí)在 mumber 集群層面實(shí)現(xiàn)，用戶無(wú)感知。

● 自動(dòng)容災(zāi)：集群或者機(jī)房故障時(shí)，自動(dòng)實(shí)現(xiàn)全量容器的遷移；

● 運(yùn)維效率：支持集群快速升級(jí)換代、上線下線；

● 多云多集群：自建 IDC 和公有云 IaaS 快速接入。

隨著更大范圍的離線和在線的融合需求，聯(lián)邦系統(tǒng)演進(jìn)到了第二代。第二代聯(lián)邦系統(tǒng)的升級(jí)主要體現(xiàn)在：

● 輕量級(jí)多集群管理：用戶看到的是單集群的視角，又能夠保證 member 集群層面的資源復(fù)用。實(shí)現(xiàn)了原生 Cluster 和 Namespace 范圍的資源訪問(wèn)隔離，以及 K8s原生對(duì)象和 CRD 對(duì)象的創(chuàng)建和訪問(wèn)的隔離。

● 聯(lián)邦化 Workload：能夠?qū)崿F(xiàn)全場(chǎng)景應(yīng)用聯(lián)邦化，一般社區(qū)的聯(lián)邦方案，通常只能接入有限的負(fù)載類型；而字節(jié)內(nèi)部實(shí)現(xiàn)了各種離線大數(shù)據(jù)場(chǎng)景，機(jī)器學(xué)習(xí)場(chǎng)景等業(yè)務(wù)的統(tǒng)一接入，結(jié)合全局的資源管控和優(yōu)化，能夠?qū)崿F(xiàn)進(jìn)一步的調(diào)度；同時(shí)，方案融合了離線和在線的容災(zāi)體系，進(jìn)一步實(shí)現(xiàn)整個(gè)數(shù)據(jù)中心層面的資源共享和復(fù)用。

調(diào)度系統(tǒng)終態(tài)視圖

基于上述的調(diào)整和升級(jí)，調(diào)度系統(tǒng)最終演進(jìn)成如下圖所示的分層架構(gòu)：

首先，單集群調(diào)度層面會(huì)運(yùn)行承載所有的資源，運(yùn)用統(tǒng)一的調(diào)度器、統(tǒng)一的資源管理、統(tǒng)一的隔離能力來(lái)實(shí)現(xiàn)資源的共享和復(fù)用；其次，聯(lián)邦層實(shí)現(xiàn)整個(gè)數(shù)據(jù)中心層面任務(wù)的統(tǒng)一編排調(diào)度和資源管理；再對(duì)接到上層，實(shí)現(xiàn)不同的租戶隔離能力和接入手段；最后，對(duì)接上層的 Paas平臺(tái)、機(jī)器學(xué)習(xí)平臺(tái)和大數(shù)據(jù)平臺(tái)等不同的業(yè)務(wù)系統(tǒng)。

服務(wù) QoS 保障

對(duì)于大規(guī)模的混部集群而言，需要注意的是服務(wù)的 QoS 保障，因此監(jiān)控非常必要。

● 基于 eBPF 內(nèi)核機(jī)制，在 SysProbe 系統(tǒng)中集成了內(nèi)核監(jiān)控的能力；

● 在 CPU 和內(nèi)存層，復(fù)用了 Cgroups 的數(shù)據(jù)，同時(shí)擴(kuò)展增加了 throttle、組線程數(shù)和狀態(tài)，以及實(shí)例 Load 等更能反映實(shí)例負(fù)載真實(shí)情況的一些指標(biāo)；

● 在 BlockIO 層，通過(guò)識(shí)別 Hook 的 VFS 層關(guān)鍵的函數(shù)以及系統(tǒng)的調(diào)用，實(shí)現(xiàn)了準(zhǔn)確識(shí)別實(shí)例的讀寫(xiě)行為；

● 在網(wǎng)絡(luò) IO 層，探測(cè)服務(wù)的 Socket 級(jí)別的連接的狀態(tài)，以及實(shí)時(shí)的 SLA，比如 SRTT 的抖動(dòng)。

基于這些監(jiān)控機(jī)制，能夠不斷發(fā)現(xiàn)并且解決混部過(guò)程中遇到的影響業(yè)務(wù) QoS 的問(wèn)題，最終實(shí)現(xiàn)完善的隔離機(jī)制。

上圖中左側(cè)流程是發(fā)現(xiàn)問(wèn)題并且解決問(wèn)題的飛輪模型，右邊為實(shí)際解決的問(wèn)題，如 CFS 調(diào)參的擴(kuò)展解決應(yīng)用 PCT99 毛刺，以及其他內(nèi)核 bug 等，都是通過(guò)這種機(jī)制發(fā)現(xiàn)并不斷優(yōu)化。

業(yè)務(wù)效果

在常態(tài)場(chǎng)景下，業(yè)務(wù)效果如下圖所示：

資源利用率情況，在線集群和離線集群的資源利用率從原來(lái)的平均 23% 提升到 63%，節(jié)省 40% 左右的服務(wù)器成本；

業(yè)務(wù) QPS 指標(biāo)，即在離線混部對(duì)業(yè)務(wù) QPS 的影響，整體影響很小。

在保證在線業(yè)務(wù)資源需求的情況下，離線任務(wù)被驅(qū)逐的概率很低。

有了穩(wěn)定的在離線資源調(diào)度系統(tǒng)，在需要應(yīng)急資源的情況下，可以通過(guò)系統(tǒng)進(jìn)行調(diào)配。比如2021 年春晚抖音紅包雨活動(dòng)，活動(dòng)期間需要大量的服務(wù)器來(lái)支持。但如果僅為支撐春晚活動(dòng)而去采購(gòu)過(guò)多計(jì)算資源，活動(dòng)結(jié)束后肯定會(huì)浪費(fèi)，所以團(tuán)隊(duì)除少量采購(gòu)服務(wù)器之外，通過(guò)采用離線資源拆借和在線混部出讓的方案解決了臨時(shí)資源問(wèn)題。

離線資源拆借。字節(jié)跳動(dòng)內(nèi)部有很多離線任務(wù)，例如模型訓(xùn)練等，這些任務(wù)在時(shí)間上并沒(méi)有特殊約束。所以春晚活動(dòng)就對(duì)這部分業(yè)務(wù)所占用的服務(wù)器進(jìn)行了拆借，設(shè)置離線出讓策略后，這些服務(wù)器可以在 5 分鐘內(nèi)轉(zhuǎn)換成在線紅包活動(dòng)的可用狀態(tài)。

在線資源出讓。春晚當(dāng)天，字節(jié)跳動(dòng)還有大量服務(wù)器在支撐其他在線服務(wù)。所謂在線混部出讓，即在保證其他業(yè)務(wù)穩(wěn)定不受影響的前提下，在服務(wù)器上插入部分春晚作業(yè)。

基于這兩種技術(shù)方案，在硬件設(shè)備有限的情況下，為春晚活動(dòng)提供了充足的算力。

火山引擎云原生服務(wù)

火山引擎云原生服務(wù)的產(chǎn)品矩陣示意圖如下所示：

2021 年12月，火山引擎發(fā)布公有云服務(wù)，對(duì)外輸出字節(jié)多年來(lái)積累的技術(shù)和經(jīng)驗(yàn)，云原生方向也以PaaS 的形態(tài)上線了很多服務(wù)。

● 容器服務(wù)：包括托管的 K8s 管理平臺(tái) VKE、彈性容器平臺(tái) VCI，和邊緣容器服務(wù)以及多云混合云的產(chǎn)品 veStack；

● 敏捷開(kāi)發(fā)：包括持續(xù)交付、鏡像倉(cāng)庫(kù)等產(chǎn)品；

● 服務(wù)治理：包括服務(wù)網(wǎng)格、混沌工程等產(chǎn)品。

上述產(chǎn)品共同組成了云原生產(chǎn)品基礎(chǔ)矩陣，火山引擎云原生服務(wù)不僅僅提供了托管應(yīng)用的能力，也融入了字節(jié)跳動(dòng)在多年的實(shí)踐過(guò)程中沉淀的 K8s 的穩(wěn)定性，可觀測(cè)性，服務(wù)網(wǎng)格等方面的技術(shù)積累和最佳實(shí)踐，方便用戶快速地使用相關(guān)技術(shù)。