作者 | 付秋偉
創(chuàng)業(yè)初期，小紅書(shū)與多數(shù)互聯(lián)網(wǎng)公司一樣，采用相對(duì)“單調(diào)”的上云、用云策略。
但當(dāng)容器化率突破 80%、資源量突破數(shù)百萬(wàn)核 CPU 時(shí)，粗放用云模式的代價(jià)開(kāi)始顯現(xiàn)：集群利用率明顯低于其他互聯(lián)網(wǎng)企業(yè)，跨云環(huán)境的應(yīng)用部署復(fù)雜度飆升，可觀測(cè)性和運(yùn)維能力面臨新挑戰(zhàn)。同時(shí)，還要充分滿足業(yè)務(wù)快速穩(wěn)定迭代的訴求，靈活應(yīng)對(duì)市場(chǎng)和業(yè)務(wù)變化。
技術(shù)團(tuán)隊(duì)清醒意識(shí)到，需要在云廠商基礎(chǔ)設(shè)施之上構(gòu)建一系列小紅書(shū)獨(dú)有的云原生技術(shù)中臺(tái)能力。
面對(duì)既要延續(xù)技術(shù)積累又要突破發(fā)展瓶頸的雙重課題，小紅書(shū)技術(shù)團(tuán)隊(duì)選擇了一條獨(dú)特的技術(shù)路徑：沒(méi)有陷入 "推倒重來(lái)" 或 "簡(jiǎn)單復(fù)用" 的二元對(duì)立，在多云的資源結(jié)構(gòu)下，以阿里云容器服務(wù) ACK + 云服務(wù)器 ECS 構(gòu)建穩(wěn)固云基座，將小紅書(shū)特有的社區(qū)電商、內(nèi)容分發(fā)等復(fù)雜業(yè)務(wù)場(chǎng)景需求，與阿里云開(kāi)源項(xiàng)目 OpenKruise（已捐贈(zèng)給 CNCF）、Koordinator 的技術(shù)優(yōu)勢(shì)深度融合。這種 "云基座打底 - 通過(guò)開(kāi)源共建滿足個(gè)性化需求" 的創(chuàng)新模式，既能在保留原有技術(shù)架構(gòu)核心價(jià)值的基礎(chǔ)上，通過(guò)深度定制的方式滿足高效穩(wěn)定的業(yè)務(wù)用云需求；又能通過(guò)開(kāi)源共建的方式，讓小紅書(shū)的技術(shù)具備足夠的先進(jìn)性與可持續(xù)性。
InfoQ 與小紅書(shū)技術(shù)團(tuán)隊(duì)、阿里云技術(shù)團(tuán)隊(duì)分別聊了聊，希望能盡可能完整地復(fù)盤本次云上創(chuàng)新，也為業(yè)界貢獻(xiàn)更多技術(shù)選型的思路和案例。
小紅書(shū)云原生平臺(tái)
2018 年，小紅書(shū)邁出了容器化建設(shè)的第一步。
云服務(wù)為小紅書(shū)帶來(lái)了顯著的便捷，能在幾分鐘內(nèi)創(chuàng)建 Kubernetes（K8s）集群并交付機(jī)器。但與此同時(shí)，對(duì)于小紅書(shū)團(tuán)隊(duì)而言，新的管理挑戰(zhàn)也隨之浮現(xiàn)。
早期小紅書(shū)允許各業(yè)務(wù)線自行申請(qǐng)獨(dú)立集群，雖然單個(gè)集群規(guī)模不大，卻因數(shù)量龐大，且缺乏專業(yè)團(tuán)隊(duì)維護(hù)，致使 K8s 版本高度碎片化。許多集群長(zhǎng)期停留在初始申請(qǐng)版本。不同版本的 K8s 在資源調(diào)度、管理策略上存在差異，無(wú)法統(tǒng)一優(yōu)化資源分配，加上低版本缺少高效資源管理特性和性能優(yōu)化，無(wú)法充分利用硬件資源。
更深層次的問(wèn)題在于，資源效能與業(yè)務(wù)穩(wěn)定性之間存在天然的矛盾。正如小紅書(shū)云原生平臺(tái)負(fù)責(zé)人林格所說(shuō)：“過(guò)去我們總是依靠資源冗余來(lái)保障穩(wěn)定性，資源和應(yīng)用架構(gòu)的云原生化相對(duì)滯后?！?/p>
面對(duì)這些挑戰(zhàn)，小紅書(shū)開(kāi)始反思：在增強(qiáng)業(yè)務(wù)穩(wěn)定性、資源調(diào)度和架構(gòu)優(yōu)化方面，是否有更成熟的行業(yè)方案可借鑒？畢竟，云原生發(fā)展已有十年，但許多企業(yè)仍停留在“用容器但不做調(diào)度”的階段，即使這種做法在企業(yè)快速成長(zhǎng)時(shí)期難以避免。
OpenKruise 和 Koordinator 這兩個(gè)開(kāi)源項(xiàng)目，正是在這樣的背景下，開(kāi)始進(jìn)入小紅書(shū)團(tuán)隊(duì)的視野。
先看看 OpenKruise 。OpenKruise 是 Kubernetes 擴(kuò)展套件，專注于云原生應(yīng)用的自動(dòng)化管理，包括部署、發(fā)布、運(yùn)維及高可用性防護(hù)。通常被用來(lái)解決有狀態(tài)服務(wù)云原生化的一些問(wèn)題，和 Kubernetes 官方工具 StatefulSet 定位接近。
但在選擇有狀態(tài)應(yīng)用編排工具的技術(shù)選型中，小紅書(shū)團(tuán)隊(duì)放棄了 StatefulSet，轉(zhuǎn)而選擇了 OpenKruise。
原因在于，在小紅書(shū)有狀態(tài)應(yīng)用容器化場(chǎng)景中，核心業(yè)務(wù)主要包含以下兩類技術(shù)形態(tài)：
數(shù)據(jù)密集型有狀態(tài)服務(wù)，比如：Kafka、Mysql、NoSQL
分布式在線推理服務(wù)
搜索的 Merger-Searcher 架構(gòu)：實(shí)現(xiàn)檢索與排序解耦，通過(guò)異構(gòu) Pod（檢索節(jié)點(diǎn)與排序節(jié)點(diǎn)）協(xié)同工作
稀疏模型相關(guān)的（PS-Worker）訓(xùn)練架構(gòu)：隨著模型參數(shù)量和數(shù)據(jù)規(guī)模增長(zhǎng)，此類服務(wù)需要數(shù)據(jù)分片化處理和分布式計(jì)算，這會(huì)導(dǎo)致應(yīng)用內(nèi)部 Pod 不再同質(zhì)化，必須采用有狀態(tài)的編排方式進(jìn)行管理
總的來(lái)說(shuō)，這些有狀態(tài)編排的訴求可以分為 多角色 和 多分片 兩大類。
StatefulSet 作為 Kubernetes 官方的有狀態(tài)應(yīng)用編排方案，在基礎(chǔ)場(chǎng)景中能滿足多分片 / 多角色應(yīng)用的簡(jiǎn)單編排需求，但在企業(yè)級(jí)生產(chǎn)環(huán)境中面臨顯著局限性，主要體現(xiàn)在兩個(gè)核心場(chǎng)景：
多副本分片部署場(chǎng)景：生產(chǎn)環(huán)境中的多分片應(yīng)用（如分布式數(shù)據(jù)庫(kù)、搜索推薦服務(wù)）通常需要 每個(gè)分片部署多副本 以保證業(yè)務(wù)高可用和負(fù)載均衡。而 StatefulSet 的默認(rèn)設(shè)計(jì)為每個(gè)分片僅支持單 Pod，無(wú)法直接實(shí)現(xiàn)分片內(nèi)的水平擴(kuò)展。
大規(guī)模存儲(chǔ)分片場(chǎng)景：當(dāng)存儲(chǔ)類應(yīng)用（如 Kafka/MySQL 集群）數(shù)據(jù)量達(dá)到 PB 級(jí)時(shí)，動(dòng)態(tài)分片擴(kuò)容 和 跨分片數(shù)據(jù)均衡 成為剛需。
綜上所述，社區(qū) StatefulSet 并不能滿足生產(chǎn)級(jí)要求。
小紅書(shū)把這些應(yīng)用的編排形態(tài)抽象成了一個(gè)二維矩陣，并稱為行列編排，其中一列代表一個(gè)分片，行數(shù)代表了一個(gè)分片的副本數(shù)量。當(dāng)發(fā)現(xiàn)上游對(duì)服務(wù)的調(diào)用量增加，可以在行的維度進(jìn)行擴(kuò)容；另一方面，當(dāng)數(shù)據(jù)量發(fā)生變化，可以在列的維度進(jìn)行擴(kuò)容。
在這個(gè)過(guò)程中，小紅書(shū)技術(shù)團(tuán)隊(duì)發(fā)現(xiàn) OpenKruise 的 UnitedDeployment 可以提供關(guān)鍵技術(shù)支撐。并根據(jù)業(yè)務(wù)場(chǎng)景構(gòu)建統(tǒng)一工作負(fù)載模型，封裝到小紅書(shū)云原生平臺(tái)中，解決小紅書(shū)內(nèi)部有狀態(tài)服務(wù)的編排問(wèn)題。
而選擇 Koordinator，則是為了重點(diǎn)解決資源調(diào)度問(wèn)題。
2023 年初，隨著資源規(guī)模擴(kuò)大，對(duì)資源效能的要求提高，公司開(kāi)始構(gòu)建自主的混部調(diào)度能力。不同于以往在資源壓力較小時(shí)，僅依靠簡(jiǎn)單的資源騰挪、二次調(diào)度和碎片治理，此次調(diào)整是一次更深層次的架構(gòu)升級(jí)。
然而，小紅書(shū)云原生架構(gòu)師熊峰也強(qiáng)調(diào)，必須構(gòu)建自己的協(xié)調(diào)層，這樣才能真正掌控技術(shù)棧。
這源于小紅書(shū)本身業(yè)務(wù)需求的特殊性，在混部和相關(guān)能力增強(qiáng)方面，很難在業(yè)內(nèi)找到開(kāi)箱即用的方案。因此，需要進(jìn)一步的定制化，構(gòu)建更符合業(yè)務(wù)需求且易用的上層能力，形成一個(gè)可插拔、可擴(kuò)展的調(diào)度體系。在保障核心業(yè)務(wù)穩(wěn)定性的基礎(chǔ)上，進(jìn)一步提升資源編排和調(diào)度的效率。
無(wú)論是快手、美團(tuán)、滴滴還是小紅書(shū)，大家在進(jìn)入原生化深水區(qū)時(shí)遇到的問(wèn)題和需求，最終有相當(dāng)一部分會(huì)歸結(jié)到調(diào)度及其相關(guān)領(lǐng)域上。對(duì)于小紅書(shū)而言，混部技術(shù)正是小紅書(shū)云原生平臺(tái)能力的核心戰(zhàn)場(chǎng)。
2023 年初，團(tuán)隊(duì)在多種社區(qū)開(kāi)源方案中反復(fù)權(quán)衡，最終，他們選擇了阿里云開(kāi)源的 Koordinator。
“選擇 Koordinator，既有歷史路徑依賴，也有技術(shù)理性?！绷指窠忉尅Ｔ缙谛〖t書(shū)基于 ACK 搭建技術(shù)底座，Koordinator 作為其開(kāi)源延伸，天然適配現(xiàn)有架構(gòu)；更重要的是，阿里內(nèi)部多年混部實(shí)踐為方案提供了“規(guī)?；?yàn)證”背書(shū)。
小紅書(shū)深度參與了 Koordinator 社區(qū)的建設(shè)。在 Koordinator 開(kāi)源初期，小紅書(shū)就積極參與了方案討論，并發(fā)現(xiàn)其資源模型抽象和 QoS 策略與小紅書(shū)的思路一致，因此結(jié)合自身的具體場(chǎng)景進(jìn)行了探索并參與社區(qū)代碼提交。與其他開(kāi)源架構(gòu)相比，Koordinator 底層構(gòu)建了一個(gè)可插拔、可擴(kuò)展的體系?；谶@一特點(diǎn)，小紅書(shū)并未完全照搬其架構(gòu)，而是選擇性地使用了部分組件或借鑒了其部分能力，并結(jié)合自研成果和內(nèi)部積累的開(kāi)源能力進(jìn)行了整合。
小紅書(shū)的案例在業(yè)內(nèi)具有普遍性，特別是在大數(shù)據(jù)調(diào)度方面。許多客戶由于各種原因仍依賴現(xiàn)有調(diào)度方式，無(wú)法立即切換至 K8s 原生的 Operator 調(diào)度模式。為了解決 EMR 場(chǎng)景下的資源效能問(wèn)題，小紅書(shū)自 2023 年 5 月起開(kāi)始啟動(dòng) YARN & K8s 混部方案。
最初階段，小紅書(shū)主要進(jìn)行技術(shù)探索。同業(yè)界其他 Yarn on K8s 方案不同的是，小紅書(shū)并未對(duì) Yarn 進(jìn)行侵入式改造，而是基于開(kāi)源 Yarn 版本進(jìn)行開(kāi)發(fā)。在過(guò)去一年中，小紅書(shū)的 Yarn 與 K8s 混合調(diào)度方案逐漸成熟，規(guī)模也在持續(xù)擴(kuò)大，覆蓋了數(shù)萬(wàn)臺(tái)節(jié)點(diǎn)，提供了數(shù)十萬(wàn)核資源，效果也很明顯：CPU 利用率平均增長(zhǎng) 8%~10%，部分達(dá)到 45% 以上。在此基礎(chǔ)上，團(tuán)隊(duì)進(jìn)一步嘗試優(yōu)化 Yarn on K8s 的方案。短期目標(biāo)是提升資源復(fù)用率和效能，而長(zhǎng)期規(guī)劃是借鑒 Koordinator 的統(tǒng)一調(diào)度理念，在 K8s 中支持 Spark 和 Flink 等業(yè)務(wù)的統(tǒng)一調(diào)度，從兩套調(diào)度體系并存演進(jìn)為統(tǒng)一調(diào)度，逐步實(shí)現(xiàn)從 Yarn 向 K8s 的切換過(guò)渡。最終，Yarn 將逐步退出歷史舞臺(tái)，K8s 生態(tài)則需全面承接大數(shù)據(jù)負(fù)載。
值得注意的是，小紅書(shū)與阿里云開(kāi)源社區(qū)之間采用的，是一種帶有共創(chuàng)性質(zhì)的社區(qū)協(xié)作范式，打破了傳統(tǒng)“用戶提問(wèn)題→云廠商做方案”的單向路徑。
小紅書(shū)早期就一直持續(xù)數(shù)月定期參與社區(qū)會(huì)議，并結(jié)合自身落地場(chǎng)景參與了技術(shù)方案設(shè)計(jì)。特別是離線混部、大數(shù)據(jù)生態(tài)融合等領(lǐng)域，資源畫(huà)像和數(shù)據(jù)預(yù)測(cè)能力的早期 proposal，均由小紅書(shū)提供了場(chǎng)景和 idea，并與阿里云社區(qū)開(kāi)發(fā)者共同討論實(shí)現(xiàn)路徑。這種合作也催生了意料之外的“共鳴”：Koordinator 開(kāi)源團(tuán)隊(duì)也從小紅書(shū)提出的 Proxy 組件方案中發(fā)現(xiàn)雙方對(duì)架構(gòu)設(shè)計(jì)理念和資源模型的理解竟高度一致，隨即開(kāi)放核心模塊的代碼共建。
通過(guò) issue 跟進(jìn)、代碼提交等方式，持續(xù)推動(dòng)核心功能的完善，小紅書(shū)的場(chǎng)景需求成為了開(kāi)源組件設(shè)計(jì)的原生基因，讓技術(shù)方案在一開(kāi)始就烙上了生產(chǎn)級(jí)場(chǎng)景的印記。
圖中為小紅書(shū)（songzh215）與阿里云（zwzhang0107）
眾所周知，調(diào)度領(lǐng)域很難做出一種完全通用的方案，尤其當(dāng)業(yè)務(wù)規(guī)模達(dá)到一定體量后，往往會(huì)出現(xiàn)許多定制化需求。而這種開(kāi)源協(xié)作形式以及最終形成的方案，對(duì)很多類似企業(yè)都具有重要的參考價(jià)值。而且面對(duì)中國(guó)開(kāi)源生態(tài)中“曇花一現(xiàn)”的挑戰(zhàn)，這種以真實(shí)場(chǎng)景驅(qū)動(dòng)、多方持續(xù)投入的深度共建模式，或許正是維持社區(qū)生命力的關(guān)鍵。
ACK 為核心的技術(shù)底座
高效支撐小紅書(shū)落地混部
以上只是解決了小紅書(shū)在開(kāi)源層面的選型問(wèn)題，在混部方案啟動(dòng)后，如何進(jìn)一步提升收益、避免資源浪費(fèi)，保障傳統(tǒng)核心業(yè)務(wù)的高效運(yùn)行，又能從調(diào)度層面解決不同業(yè)務(wù)間的資源供給問(wèn)題，成為了下一階段的核心命題。
這是一個(gè)涉及業(yè)務(wù)和基礎(chǔ)設(shè)施層面的整體工程，要求對(duì)調(diào)度系統(tǒng)、內(nèi)核等多個(gè)維度進(jìn)行優(yōu)化，同時(shí)還要在業(yè)務(wù)指標(biāo)中引入響應(yīng)時(shí)間（RT）劣化率、CPU 分層利用率等指標(biāo)，以降低低效資源比例，倒逼架構(gòu)優(yōu)化。
在這一系統(tǒng)性工程中，“大 Node 小 Pod”成為小紅書(shū)混部落地的核心方法論。
在混部的情況下，首先需要確認(rèn)的是資源供給方式。早期，小紅書(shū)的許多業(yè)務(wù)在一定程度上將 Pod 和虛擬機(jī)綁定在一起。一臺(tái)機(jī)器上通常只部署一到兩個(gè)應(yīng)用，導(dǎo)致遷移成本高、彈性差，并且由于負(fù)載特性相似，對(duì)資源的訴求同質(zhì)化嚴(yán)重，比如流量到來(lái)后在某個(gè)時(shí)間這些業(yè)務(wù)同時(shí)將 CPU 打高，容易出現(xiàn)資源共振問(wèn)題，影響系統(tǒng)穩(wěn)定性。因此，要在同一節(jié)點(diǎn)上對(duì)不同業(yè)務(wù)進(jìn)行混部，并為業(yè)務(wù)提供彈性和性能緩沖的空間非常有限。
于是技術(shù)團(tuán)隊(duì)突破性提出“大 Node 小 Pod”策略：將物理節(jié)點(diǎn)規(guī)格做大，將應(yīng)用拆小，實(shí)例增多并打散分布，既規(guī)避了虛擬化層潛在的資源干擾，又為跨業(yè)務(wù)混部創(chuàng)造了靈活的資源調(diào)度空間：在單機(jī)故障或出現(xiàn)熱點(diǎn)問(wèn)題時(shí)，可以更快速地進(jìn)行應(yīng)用遷移，從而減少停機(jī)時(shí)間和對(duì)業(yè)務(wù)的影響。
小紅書(shū)進(jìn)一步提升混部收益的一個(gè)非常關(guān)鍵的手段是將核心的一些業(yè)務(wù)線，約 50 萬(wàn)核的計(jì)算資源，替換為了“大 Node”的基于阿里云 CIPU 架構(gòu)的大規(guī)格 ECS 實(shí)例。
“基于阿里云自研的 CIPU 架構(gòu)的云服務(wù)器，確實(shí)幫了我們大忙?！绷指駨?qiáng)調(diào)。
小紅書(shū)主力使用的是 64 核的 VM 與 192 核的整機(jī)規(guī)格服務(wù)器，其中整機(jī)規(guī)格的服務(wù)器作為大 Node 使用時(shí)，小紅書(shū)能夠直接掌控從 CPU、內(nèi)存到緩存的全量硬件資源，避免跨租戶資源爭(zhēng)搶導(dǎo)致的性能抖動(dòng)。在推進(jìn)“大 Node、小 Pod”策略時(shí)，這相當(dāng)于提供了一種極限規(guī)格的大型計(jì)算節(jié)點(diǎn)能力。
在構(gòu)建大規(guī)模計(jì)算節(jié)點(diǎn)時(shí)，阿里云云服務(wù)器 ECS AMD 實(shí)例（以下簡(jiǎn)稱 ECS AMD 實(shí)例）是小紅書(shū)在大 Node 方案中的另一個(gè)重要選擇。ECS AMD 實(shí)例構(gòu)建在多層技術(shù)架構(gòu)之上，最底層是 AMD CPU 芯片，并疊加阿里云自研的 CIPU 架構(gòu)，其上一層為容器相關(guān)產(chǎn)品如容器服務(wù) Kubernetes 版 ACK（以下簡(jiǎn)稱 ACK），最上層則是用戶的應(yīng)用層。
自 2022 年起，小紅書(shū)便開(kāi)始采用 ECS AMD 實(shí)例。近年來(lái)，特別是第八代推出后，CPU 能力方面得到了更大提升。例如，主頻提升到 2.7GHz，最高睿頻到 3.7GHz，核心密度不斷優(yōu)化，同時(shí)相比上一代單核的二級(jí)緩存提升一倍，IPC 提升了 14%，使其在相同功耗水平下算力提升約 25%。
除了高密度核心帶來(lái)的性價(jià)比收益，還有一個(gè)是在大數(shù)據(jù)和搜推場(chǎng)景下的性能優(yōu)勢(shì)。
在深度學(xué)習(xí)驅(qū)動(dòng)的搜推業(yè)務(wù)中，小紅書(shū)采用 PS-Worker 分布式訓(xùn)練架構(gòu)作為技術(shù)底座。該架構(gòu)下，參數(shù)服務(wù)器需要在內(nèi)存中存儲(chǔ)并快速讀取大量參數(shù)，那么內(nèi)存帶寬以及網(wǎng)絡(luò)吞吐率都是重要的性能瓶頸點(diǎn)。
為了突破這些瓶頸，小紅書(shū)選擇基于阿里云自研的 CIPU 架構(gòu)的 ECS AMD 實(shí)例，將內(nèi)存帶寬提升 125%，達(dá)到 350GB。
這一顯著提升，主要來(lái)自兩個(gè)方面。
一是傳統(tǒng)的 VM 由于虛擬化開(kāi)銷，會(huì)丟失部分內(nèi)存帶寬和 Cache 資源的隔離能力。而 CIPU 架構(gòu)保留了這些能力，也能夠接入 VPC 網(wǎng)絡(luò)、云盤及訪問(wèn)大數(shù)據(jù) EMR 系統(tǒng)的能力。這種特性使得服務(wù)器在保持云計(jì)算靈活性的同時(shí)，也能提供精細(xì)化的資源控制能力，包括內(nèi)存帶寬和 L3 Cache 的調(diào)優(yōu)，從而更好地適配大規(guī)?；觳繄?chǎng)景。
二是 ECS AMD 實(shí)例處理器在第八代升級(jí)中，將內(nèi)存通道數(shù)從 8 個(gè)擴(kuò)展到 12 個(gè)，并提升了內(nèi)存速率，使得數(shù)據(jù)吞吐能力顯著增強(qiáng)。同時(shí)，這代處理器還采用了先進(jìn)工藝實(shí)現(xiàn)了硬件微架構(gòu)上比如 CPU 內(nèi)核密度、io 等多方面的提升。除硬件外，在指令方面，不僅兼容了 AVX512 同時(shí)還支持了 bf16，使得在高并發(fā)、大規(guī)模計(jì)算任務(wù)下，系統(tǒng)能夠保持更高的穩(wěn)定性和效率。
eRDMA 加速搜推廣混部集群性能示意圖
在超大規(guī)模計(jì)算（大 Node）場(chǎng)景下，網(wǎng)絡(luò)性能往往是影響整體計(jì)算效率的關(guān)鍵因素。PS-Worker 節(jié)點(diǎn)里，網(wǎng)絡(luò)的開(kāi)銷通常會(huì)在整個(gè)性能權(quán)重中占據(jù)很大一部分。
CIPU 架構(gòu)引入的 eRDMA（Elastic RDMA）網(wǎng)絡(luò)，以其低時(shí)延、高吞吐性能使大 Node 之間的數(shù)據(jù)傳輸時(shí)延最低可達(dá) 8-10 微秒，相比傳統(tǒng) VPC 網(wǎng)絡(luò)，通信開(kāi)銷降低達(dá) 45%。結(jié)合任務(wù)并行度優(yōu)化算法，使 AI 訓(xùn)練和在線推理的長(zhǎng)尾延遲顯著改善。
超大集群規(guī)模支持
早期小紅書(shū)集群資源管理粗放，存在大量業(yè)務(wù)獨(dú)占資源池，導(dǎo)致資源池割裂、碎片化嚴(yán)重。業(yè)務(wù)為保障穩(wěn)定性過(guò)度囤積資源，進(jìn)一步加劇浪費(fèi)。為此，小紅書(shū)調(diào)整集群架構(gòu)，建成包含 7000 至 8000 個(gè)節(jié)點(diǎn)的超大規(guī)模集群，成為云上單集群節(jié)點(diǎn)數(shù)最多的案例之一。
在業(yè)內(nèi)，突破 K8s 社區(qū)的節(jié)點(diǎn)規(guī)模上限，一直被視為衡量技術(shù)能力的重要指標(biāo)。隨著阿里云產(chǎn)品能力的不斷提升，ACK 目前對(duì)外承諾的單集群節(jié)點(diǎn)上限已達(dá)到 1.5 萬(wàn)個(gè)節(jié)點(diǎn)。這意味著，從 K8s 社區(qū)推薦的 5000 節(jié)點(diǎn)，到 ACK 支持的 1.5 萬(wàn)節(jié)點(diǎn)，規(guī)模足足提升了三倍。
阿里云在應(yīng)對(duì)單集群 1.5 萬(wàn)節(jié)點(diǎn)的挑戰(zhàn)過(guò)程中，針對(duì)控制面和數(shù)據(jù)面進(jìn)行了多項(xiàng)優(yōu)化。
ACK 的控制面與數(shù)據(jù)面優(yōu)化
在 AI 和大規(guī)模彈性場(chǎng)景下，單集群規(guī)模擴(kuò)大會(huì)導(dǎo)致資源膨脹，對(duì)控制面和數(shù)據(jù)面提出更高要求。節(jié)點(diǎn)數(shù)增至 5000 時(shí)，控制面壓力顯著增加，表現(xiàn)為內(nèi)存與 CPU 消耗成倍增長(zhǎng)，以及 API Server 穩(wěn)定性問(wèn)題 —— 控制面需緩存全部數(shù)據(jù)面資源信息，導(dǎo)致資源占用遠(yuǎn)高于常規(guī)集群。ACK 針對(duì)控制面組件實(shí)施多項(xiàng)優(yōu)化：
API Server：作為控制面核心，其穩(wěn)定性至關(guān)重要。ACK 引入自動(dòng)化彈性擴(kuò)容和限流機(jī)制，采用 KON K 架構(gòu)將 API Server Pod 部署在專屬集群，可根據(jù)負(fù)載動(dòng)態(tài)調(diào)整副本數(shù)，秒級(jí)完成彈性擴(kuò)容。
ETCD：作為有狀態(tài)組件，采用三副本架構(gòu)，引入自動(dòng)化垂直彈性擴(kuò)容（VPA），緊急時(shí)自動(dòng)擴(kuò)展資源配置；將社區(qū)版存儲(chǔ)空間優(yōu)化，默認(rèn)提升 quota，解決存儲(chǔ)瓶頸。
限流機(jī)制：當(dāng)擴(kuò)容后壓力仍較大時(shí)，主動(dòng)限制數(shù)據(jù)面部分訪問(wèn)以保障控制面穩(wěn)定，恢復(fù)后自動(dòng)解除。該機(jī)制避免了類似 OpenAI 因 API Server 壓力導(dǎo)致的集群失控問(wèn)題，確保用戶對(duì)集群的控制權(quán)。
數(shù)據(jù)面的優(yōu)化主要針對(duì)大規(guī)模彈性場(chǎng)景（如小紅書(shū)離線任務(wù)）：
節(jié)點(diǎn)初始化并行化處理組件部署、OpenAPI 訪問(wèn)等步驟，提升啟動(dòng)速度。
優(yōu)化 Pod 創(chuàng)建與事件推送效率，加快數(shù)據(jù)面彈性響應(yīng)。
事實(shí)上，在應(yīng)對(duì)單集群 1.5 萬(wàn)節(jié)點(diǎn)挑戰(zhàn)過(guò)程中，ACK 的優(yōu)化不僅滿足了自身業(yè)務(wù)的高標(biāo)準(zhǔn)需求，還貢獻(xiàn)至 K8s 社區(qū)，有些優(yōu)化已在 1.30 版本中得到應(yīng)用。
當(dāng)然，面對(duì)超大規(guī)模的集群管理，不同企業(yè)也會(huì)采用不同的策略。有些企業(yè)選擇將業(yè)務(wù)拆分到多個(gè)小集群中，而有些則傾向于將大部分業(yè)務(wù)集中在少量的大集群中，以簡(jiǎn)化運(yùn)維管理和降低發(fā)布復(fù)雜度。
小紅書(shū)的集群管理策略
作為用戶，小紅書(shū)本身不需要太關(guān)注管控面的穩(wěn)定性該怎么去建設(shè)，但因?yàn)闃I(yè)務(wù)需要，落地了一個(gè) 8000 節(jié)點(diǎn)級(jí)別的規(guī)模，所以也一直對(duì)爆炸半徑問(wèn)題保持高度警惕，并通過(guò)一系列策略加以控制。
首先，小紅書(shū)在內(nèi)部對(duì)集群規(guī)模進(jìn)行了嚴(yán)格限制。為了防止集群規(guī)模過(guò)大帶來(lái)的爆炸半徑風(fēng)險(xiǎn)，每個(gè)集群設(shè)定了水位線，當(dāng)規(guī)模達(dá)到上限后，將停止承接新業(yè)務(wù)，僅對(duì)存量業(yè)務(wù)進(jìn)行擴(kuò)容。
隨著 K8s 原生化的發(fā)展，越來(lái)越多的業(yè)務(wù)方開(kāi)始自行開(kāi)發(fā) Operator，并通過(guò) K8s 管控面與業(yè)務(wù)系統(tǒng)進(jìn)行交互。對(duì)此，小紅書(shū)制定了嚴(yán)格的規(guī)范，禁止業(yè)務(wù)方將 K8s 管控面作為核心數(shù)據(jù)鏈路，要求盡可能使用緩存，并對(duì)高頻訪問(wèn)進(jìn)行限流，以防止管控面被打掛。
同時(shí)，小紅書(shū)還通過(guò)定期巡檢和治理機(jī)制，及時(shí)發(fā)現(xiàn)并修復(fù)不規(guī)范的使用方式，確保集群在高并發(fā)、高負(fù)載場(chǎng)景下的穩(wěn)定性。
此外，在架構(gòu)設(shè)計(jì)上，還將管控面不可用作為極端情況下的前提條件，并以此為基礎(chǔ)進(jìn)行了容災(zāi)設(shè)計(jì)。
當(dāng)然，相較于阿里云支持的 1.5 萬(wàn)節(jié)點(diǎn)集群，小紅書(shū)集群由于計(jì)算節(jié)點(diǎn)多采用大規(guī)格配置，對(duì)單集群規(guī)模的實(shí)際需求較低，因此整體規(guī)模相對(duì)較小；在管控面加固方面，小紅書(shū)充分借鑒行業(yè)成熟方案，從而有效提升了平臺(tái)的穩(wěn)定性與安全性。
“云計(jì)算的標(biāo)準(zhǔn)化交付恰恰為滿足企業(yè)個(gè)性化需求提供了前提?！绷指駨?qiáng)調(diào)。
技術(shù)路徑并非非此即彼, 在 ACK 等標(biāo)準(zhǔn)化能力基礎(chǔ)上，通過(guò)共建的方式滿足個(gè)性化需求，小紅書(shū)實(shí)現(xiàn)了業(yè)務(wù)場(chǎng)景精細(xì)化資源效率管理與業(yè)務(wù)穩(wěn)定性的動(dòng)態(tài)平衡。
在混部架構(gòu)與資源調(diào)度優(yōu)化的驅(qū)動(dòng)下，小紅書(shū)成功將集群資源利用率提升至 40%，這一數(shù)字背后是內(nèi)核調(diào)優(yōu)、精細(xì)化調(diào)度策略及資源池優(yōu)化的協(xié)同作用。
值得注意的是，小紅書(shū)團(tuán)隊(duì)對(duì)云原生演進(jìn)方向的判斷與社區(qū)趨勢(shì)高度契合：簡(jiǎn)化復(fù)雜性與適配新興場(chǎng)景將成為下一階段的關(guān)鍵。小紅書(shū)技術(shù)團(tuán)隊(duì)指出，大家都認(rèn)為云原生“好”，但是想把它真的用起來(lái)卻太難，所以我們需要破解云原生技術(shù)的“復(fù)雜度悖論”。
正如團(tuán)隊(duì)所強(qiáng)調(diào)的，云原生的價(jià)值在于持續(xù)解決業(yè)務(wù)的實(shí)際問(wèn)題。面對(duì) AI 驅(qū)動(dòng)的算力革命與混合架構(gòu)的常態(tài)化，小紅書(shū)的技術(shù)實(shí)踐或?qū)樾袠I(yè)提供一條可參考的路徑——在效率與靈活性之間尋找平衡，以持續(xù)演進(jìn)的架構(gòu)能力迎接未來(lái)的業(yè)務(wù)挑戰(zhàn)。
更進(jìn)一步看，今天的云計(jì)算，已經(jīng)成為 IT 技術(shù)歷史中，最重要的一筆——它橫跨 Web 時(shí)代、移動(dòng)互聯(lián)網(wǎng)時(shí)代、AI 時(shí)代，不斷進(jìn)化，極大地降低了企業(yè)的 IT 成本，將基礎(chǔ)設(shè)施企業(yè)與技術(shù)企業(yè)、平臺(tái)企業(yè)、應(yīng)用企業(yè)緊緊連接在一起。
當(dāng)我們回望阿里云彈性計(jì)算 15 年技術(shù)演進(jìn)軌跡，這條路徑清晰勾勒出云計(jì)算與時(shí)代需求的同頻共振——從早期助力傳統(tǒng)企業(yè)叩開(kāi)互聯(lián)網(wǎng)大門，到深度陪伴互聯(lián)網(wǎng)企業(yè)完成從業(yè)務(wù)上云到架構(gòu)云原生化的蛻變，直至今日成為 AI 時(shí)代算力革命的核心基礎(chǔ)設(shè)施。這場(chǎng)持續(xù)升級(jí)的底層邏輯，始終圍繞 "讓算力服務(wù)于業(yè)務(wù)價(jià)值" 展開(kāi)：在基礎(chǔ)資源層構(gòu)建兼具彈性擴(kuò)展能力與極致性能的算力矩陣（如 ECS AMD 實(shí)例提供的高性能算力選項(xiàng)），在調(diào)度管理層打造覆蓋 "算力供給 - 資源調(diào)度 - 應(yīng)用交付" 的全鏈路閉環(huán)（如容器服務(wù) ACK 實(shí)現(xiàn)的高效應(yīng)用管理），形成支撐企業(yè)數(shù)字化轉(zhuǎn)型的技術(shù)底座。
從虛擬化技術(shù)的突破到智能混部調(diào)度，每一次技術(shù)跨越是都在踐行 "降低用云門檻" 的普惠理念。在 AI 重塑產(chǎn)業(yè)的當(dāng)下，阿里云彈性計(jì)算將繼續(xù)與客戶并肩同行，不止是為 AI 企業(yè)提供支撐大模型訓(xùn)練、智能推理的澎湃算力，更是技術(shù)演進(jìn)的同路人。在持續(xù)迭代的架構(gòu)創(chuàng)新中為企業(yè)打開(kāi)業(yè)務(wù)增長(zhǎng)的新空間，讓云計(jì)算真正成為跨越時(shí)代的技術(shù)核心紐帶。
熱門跟貼