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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

解決思路

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

首先需要通過 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，只保留對應(yīng)的離線作業(yè)生命周期管理以及周邊功能，進(jìn)而實現(xiàn)離在線無縫遷移和并池的能力；將公司所有 Yarn 上的存量大數(shù)據(jù)業(yè)務(wù)無縫遷移至新的調(diào)度平臺，來實現(xiàn)在離線資源池的統(tǒng)一。最后，獲取了單集群的在離線統(tǒng)一調(diào)度能力后，就可以通過集群聯(lián)邦對多個集群的在離線資源進(jìn)行統(tǒng)一管理。

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

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

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

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

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

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

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

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

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

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

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

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

服務(wù) QoS 保障

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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