KubeTea:面向容器云環(huán)境的輕量級多維度微服務(wù)應(yīng)用調(diào)度框架

摘 要：容器云中，應(yīng)用和資源調(diào)度始終是集群管理的重點。如何在提高資源利用率的同時保證應(yīng)用服務(wù)質(zhì)量是目前行業(yè)積極探索的問題之一。針對該問題，提出一個面向容器云環(huán)境的輕量級多維度微服務(wù)應(yīng)用調(diào)度框架。該框架設(shè)計了非侵入式的網(wǎng)絡(luò)調(diào)用觀測方法，并基于觀測和監(jiān)控數(shù)據(jù)定義親和性、熱點值（HV）和熱路徑（HP）來指導(dǎo)調(diào)度決策。為平衡資源利用率和應(yīng)用QoS，該框架在調(diào)度的垂直方向上提出彈性余量控制機制（elastic slack controller，ESC），在水平方向上考慮了微服務(wù)親和性；并設(shè)計了擴散導(dǎo)向的自動伸縮策略（diffusion-oriented autoscaling strategy，DOAS）以緩解應(yīng)用出現(xiàn)的QoS下降。實驗表明，該框架與主流的Kubernetes原生調(diào)度工具相比，在集群資源利用率方面提高21%，同時能降低23%的應(yīng)用端到端時延，實現(xiàn)資源利用率和應(yīng)用QoS的平衡。

關(guān)鍵詞：資源調(diào)度； 容器； 微服務(wù)； 可觀測性； 云原生

中圖分類號：TP391 文獻標志碼：A

文章編號：1001-3695（2024）09-032-2794-06

doi：10.19734/j.issn.1001-3695.2024.01.0009

KubeTea：lightweight multi-dimensional microservice application schedulingframework for container cloud environments

Li Zonglin1， He Junjiang1， Li Wenshan1，2， Lyu Xiao1， Lan Xiaolong1， Li Tao1

（1.School of Cyber Science & Engineering， Sichuan University， Chengdu 610065， China; 2.School of Cybersecurity， Chengdu University of Information Technology， Chengdu 610225， China）

Abstract：In container clouds， application and resource scheduling has always been a key focus of cluster management. One of the active explorations in the industry is how to improve resource utilization while ensuring application service quality. This paper proposed a lightweight microservice application scheduling framework for container cloud environments. This framework designed a non-intrusive network call observation method and defined affinity， hot value（HV）， and hot path（HP） based on observation and monitoring data to guide scheduling decisions. To balance resource utilization and application of QoS， the framework proposed the ESC mechanism in the vertical direction of scheduling and considered microservice affinity in the horizontal direction. Furthermore，it designed the DOAS to alleviate the QoS degradation of applications. Experimental results show that compared with the mainstream Kubernetes native scheduling tool， this framework improves resource utilization by 21% while reducing end-to-end application latency by 23%， achieving a balance between resource utilization and QoS application.

Key words：resource management; container; microservice; observability; cloud native

0 引言

將應(yīng)用容器化后上云是目前互聯(lián)網(wǎng)服務(wù)部署的主流方式［1］。同時，應(yīng)用快速迭代的需求使微服務(wù)架構(gòu)被廣泛采用［2］。大型單體應(yīng)用在劃分成多個微服務(wù)模塊并容器化后，有助于DevOps的實踐［3， 4］，進而適合部署在資源高度共享的容器云中。運維人員通常會為應(yīng)用申請遠超其所需的資源配額［5］，一方面導(dǎo)致云租戶成本增加［6］，另一方面加劇數(shù)據(jù)中心資源利用率本就不高的情況［7］。提高數(shù)據(jù)中心資源利用率、實現(xiàn)降本增效，始終是云計算領(lǐng)域持續(xù)跟蹤的問題［8］，各大云廠商也在如何調(diào)度云上應(yīng)用和資源進行了豐富實踐［9］。

在管理大型云上集群時，提高資源利用率和應(yīng)用服務(wù)質(zhì)量這兩個目標從技術(shù)視角看是矛盾的，因此在兩者間求得平衡是需要解決的問題［10］。

在集群中，應(yīng)用的調(diào)度工作包含對應(yīng)用資源使用指標進行監(jiān)控和觀測，根據(jù)數(shù)據(jù)給出調(diào)度決策并執(zhí)行兩個主要步驟，資源在該流程組成的閉環(huán)中不斷調(diào)配到各應(yīng)用實例。觀測集群和應(yīng)用狀態(tài)是調(diào)度決策和資源分配的基礎(chǔ)，實現(xiàn)微服務(wù)的可觀測性對于分析微服務(wù)之間的關(guān)系十分重要［11］，可以使調(diào)度工作更加有效。實現(xiàn)可觀測性的手段包括在應(yīng)用代碼中嵌入鏈路追蹤框架或是部署Sidecar容器［12，13］。前者能夠最為準確地捕獲微服務(wù)間產(chǎn)生調(diào)用的位置，但會給開發(fā)人員帶來額外的負擔，對應(yīng)用不透明；后者能夠避免侵入到應(yīng)用代碼層面，但會加劇本就復(fù)雜的云原生網(wǎng)絡(luò)，并帶來更多資源開銷。在現(xiàn)有研究工作中，調(diào)度方式按照資源分配維度可分為垂直方向和水平方向，按照執(zhí)行時間點分為響應(yīng)式和預(yù)測式。響應(yīng)式調(diào)度手段的主要思想是根據(jù)設(shè)定的資源使用閾值分配資源，在此基礎(chǔ)上的研究多將資源利用率和各項觀測指標建模成多目標優(yōu)化或是控制理論問題［14～16］，在資源和負載出現(xiàn)變化后執(zhí)行調(diào)度。而預(yù)測式的調(diào)度方案多是利用機器學習方法，提前預(yù)測未來可能變化的負載，在負載變化來臨前調(diào)度［17～19］。上述方法大都需要針對特定場景建立數(shù)學模型或是使用大量數(shù)據(jù)訓練機器學習模型來產(chǎn)生調(diào)度決策。

本文針對上述問題提出一個輕量級的調(diào)度框架，并在垂直（針對單個副本的資源配額）和水平（調(diào)整服務(wù)副本數(shù)量）兩個維度設(shè)計了調(diào)度策略，貢獻如下：

a）設(shè)計了一種非侵入式的網(wǎng)絡(luò)，調(diào)用觀測方法生成微服務(wù)調(diào)用圖。區(qū)別于傳統(tǒng)常用可觀測性實現(xiàn)方式對應(yīng)用不透明和增加資源開銷，該方法用輕量化的手段實現(xiàn)微服務(wù)間調(diào)用的可觀測性，并基于觀測和監(jiān)控的信息定義親和性，綜合指導(dǎo)調(diào)度決策。

b）提出了一種ESC和基于親和性的多維度調(diào)度方法來優(yōu)化資源分配。與傳統(tǒng)僅在單一維度的調(diào)度工作相比，該方法在水平方向和垂直方向，同時把應(yīng)用服務(wù)質(zhì)量（quality of service，QoS）也納入考量，以獲得提升資源利用率和保證QoS的平衡，并設(shè)計了DOAS提高QoS。

c）KubeTea在Kubernetes集群中進行實現(xiàn)，并通過實驗驗證了該框架能在提高資源利用率的情況下優(yōu)化應(yīng)用服務(wù)質(zhì)量。在資源利用率提升21%的同時，應(yīng)用的端到端延遲降低23%。

1 背景與研究現(xiàn)狀

1.1 微服務(wù)架構(gòu)分析

以典型的微服務(wù)架構(gòu)社交網(wǎng)絡(luò)應(yīng)用［20］為例，如圖1所示，該應(yīng)用被劃分成數(shù)十個微服務(wù)。微服務(wù)架構(gòu)在解耦復(fù)雜應(yīng)用的同時也帶來服務(wù)治理的挑戰(zhàn)。首先，微服務(wù)通常使用RESTful API或RPC調(diào)用進行通信，錯綜復(fù)雜的網(wǎng)絡(luò)請求導(dǎo)致某一微服務(wù)模塊的服務(wù)質(zhì)量下降就會影響整個應(yīng)用的端到端延遲；其次，微服務(wù)應(yīng)用不同的API，對應(yīng)的后端調(diào)用鏈路表現(xiàn)出一定的動態(tài)性，產(chǎn)生相異的調(diào)用拓撲［21］，例如圖1中“搜索”和“提交文章”功能對應(yīng)不同的調(diào)用鏈路。在特定API的QoS下降時，對應(yīng)調(diào)用路徑上的微服務(wù)應(yīng)用都需要被排查。因此，實現(xiàn)微服務(wù)應(yīng)用的可觀測性、分析應(yīng)用不同的微服務(wù)間調(diào)用關(guān)系能使調(diào)度決策更為準確有效。

上述微服務(wù)的特點對調(diào)度工作提出了挑戰(zhàn)：如何通過調(diào)度降低端到端延遲以獲得更好的QoS。本文提出一個非侵入式的觀測方法，通過分析微服務(wù)間調(diào)用鏈路優(yōu)化副本的放置以提升應(yīng)用的服務(wù)質(zhì)量。

1.2 相關(guān)工作

從Borg［22］中積累的集群管理經(jīng)驗催生了如Kubernetes［23］和Autopilot［24］等云數(shù)據(jù)中心管理著數(shù)十億的容器化應(yīng)用的編排工具，為用戶提供基礎(chǔ)的容器伸縮和調(diào)度能力。就調(diào)度容器化應(yīng)用來說，包含垂直方向和水平方向兩個維度的自動伸縮，前者指對單一實例的副本配額進行增減，后者則體現(xiàn)在對某一微服務(wù)的副本數(shù)量進行增減。調(diào)度工作依賴對集群及容器實例狀態(tài)的監(jiān)控和觀測，所得到的數(shù)據(jù)用于支撐調(diào)度決策。

1.2.1 監(jiān)控和觀測相關(guān)工作

調(diào)度工作需要依靠如CPU、內(nèi)存、網(wǎng)絡(luò)等指標的數(shù)據(jù)［25～28］，獲取這些數(shù)據(jù)的手段稱為監(jiān)控。對于微服務(wù)架構(gòu)應(yīng)用來說，還需考慮服務(wù)間調(diào)用關(guān)系［16，29］，以反映微服務(wù)之間的親和性。捕獲此類網(wǎng)絡(luò)調(diào)用關(guān)系的能力用可觀測性來表述。實現(xiàn)微服務(wù)調(diào)用可觀測性的第一種方法是使用 Zipkin、Jaeger這類鏈路追蹤框架［12］，該類框架在程序代碼中發(fā)起跨服務(wù)調(diào)用的位置處埋點，在應(yīng)用發(fā)起調(diào)用請求時上報數(shù)據(jù)。另一種方法是使用以Istio為代表的Sidecar技術(shù)，在Pod中注入代理容器［13］，代理容器和業(yè)務(wù)容器位于同一Pod中并且共享網(wǎng)絡(luò)命名空間，通過接管業(yè)務(wù)流量來實現(xiàn)可觀測性。本文KubeTea設(shè)計了一種非侵入式的觀測方法，既節(jié)省了開發(fā)人員的工作量又避免了Sidecar容器額外的資源消耗。

1.2.2 應(yīng)用與資源調(diào)度相關(guān)工作

在面對動態(tài)的負載時，往往分配超出應(yīng)用實際所需的資源配額以保證其穩(wěn)定性，但這會導(dǎo)致不必要的資源浪費［30］。為改善這種情況，VPA［31］和HPA［32］作為容器云中使用最為廣泛的調(diào)度框架，分別從水平和垂直兩個維度根據(jù)設(shè)定的閾值自動為應(yīng)用分配資源。文獻［22， 33］將在線應(yīng)用和離線任務(wù)進行混部以提高資源利用率，但大部分小規(guī)模數(shù)據(jù)中心沒有混部條件。文獻［17， 18］為優(yōu)化服務(wù)質(zhì)量，采用機器學習預(yù)測的方法提前為應(yīng)用擴容，不過一些研究對機器學習在面對動態(tài)且無規(guī)律的負載時是否能勝任預(yù)測工作存有爭議［19， 34］。文獻［14， 15， 27］把調(diào)度決策抽象成多目標優(yōu)化任務(wù)、Baarzi等人［16］利用控制理論中的PID算法輔助調(diào)度工作，但這類方法要對特定應(yīng)用進行數(shù)學建模并涉及復(fù)雜的參數(shù)調(diào)優(yōu)。本文對近年來容器化微服務(wù)應(yīng)用調(diào)度的相關(guān)工作進行了整理，如表1所示。表1從是否有可觀測性組件、是否考慮微服務(wù)親和性、是否考慮服務(wù)質(zhì)量、調(diào)度維度以及調(diào)度方式這五個方面進行了歸納。

與現(xiàn)有工作相比，本文將微服務(wù)調(diào)用可觀測性的實現(xiàn)納入調(diào)度框架中；基于可觀測性的能力，KubeTea將微服務(wù)親和性和服務(wù)質(zhì)量納入調(diào)度決策的參考依據(jù)；同時實現(xiàn)了水平方向和垂直方向上多維的調(diào)度決策能力。

2 KubeTea的設(shè)計與實現(xiàn)

KubeTea整體架構(gòu)如圖2所示，其包含三個主要模塊，工作流程有以下四步：

a）監(jiān)控和觀測模塊獲取集群狀態(tài)數(shù)據(jù)，包括時序監(jiān)控指標和觀測到的微服務(wù)間調(diào)用信息，這些數(shù)據(jù)在狀態(tài)分析模塊處理。

b）狀態(tài)分析模塊利用時序數(shù)據(jù)表征微服務(wù)對資源的使用模式，主要指導(dǎo)垂直方向的自動伸縮。以圖結(jié)構(gòu)展現(xiàn)網(wǎng)絡(luò)調(diào)用數(shù)據(jù)，來分析出微服務(wù)之間的聯(lián)系，支撐跨節(jié)點的水平自動伸縮。

c）基于分析結(jié)果，自動伸縮模塊在垂直或水平方向進行調(diào)度工作，必要時會聯(lián)合兩個維度執(zhí)行DOAS以緩解SLO違規(guī)。

d）自動伸縮模塊實現(xiàn)了Kubernetes的client-go接口，將最終的決策下發(fā)執(zhí)行，變更集群中應(yīng)用的資源配額和副本數(shù)量。

KubeTea在上述四個步驟的循環(huán)中工作，以應(yīng)對動態(tài)變化的工作負載，在提高資源利用率的同時保證應(yīng)用服務(wù)質(zhì)量。

2.1 監(jiān)控和觀測模塊

該模塊抓取集群中節(jié)點以及應(yīng)用的狀態(tài)，捕獲并存儲實時數(shù)據(jù)以供狀態(tài)分析模塊分析，數(shù)據(jù)源是Prometheus［35］和Hubble［36］。前者監(jiān)控CPU和內(nèi)存的使用情況，后者用于實現(xiàn)微服務(wù)間調(diào)用的可觀測性。

為避免1.2.1節(jié)所述的代碼及Pod侵入帶來的弊端，本文利用Hubble提供的eBPF［37］程序接口設(shè)計并實現(xiàn)了非侵入式的網(wǎng)絡(luò)調(diào)用觀測方法，原理如圖3所示。

同一宿主機上容器共享OS內(nèi)核的特性使eBPF技術(shù)在內(nèi)核空間就能觀測到容器間的網(wǎng)絡(luò)調(diào)用信息，Hubble提供了gRPC服務(wù)端接口來使用eBPF的觀測能力。KubeTea在狀態(tài)分析模塊中實現(xiàn)了hubble-gRPC-client，針對性地捕獲網(wǎng)絡(luò)調(diào)用上游和下游Pod信息，并統(tǒng)計不同微服務(wù)間的調(diào)用頻率。

2.2 狀態(tài)分析模塊

該模塊基于收集到的監(jiān)控和觀測數(shù)據(jù)提出三個定義來具體反映微服務(wù)間的狀態(tài)關(guān)系，用于指導(dǎo)調(diào)度決策。

a）親和性（affinity）。兩個微服務(wù)間調(diào)用越頻繁，親和性越高，調(diào)用頻率相近時，具有雙向調(diào)用特性的兩個微服務(wù)親和性高。親和性體現(xiàn)在微服務(wù)之間，但由于容器運行在某個節(jié)點上，親和性關(guān)系會傳遞到微服務(wù)與節(jié)點之間。

b）熱點值（HV）。HV用于反映某個微服務(wù)的服務(wù)質(zhì)量變化對整個應(yīng)用的影響程度，本文以微服務(wù)上下游數(shù)量為依據(jù)。圖1中在出現(xiàn)服務(wù)質(zhì)量下降時，“Nginx”和“compost post”微服務(wù)對其他微服務(wù)的影響顯然比“media”大。

c）熱路徑（HP）。HP用于表示出現(xiàn)SLO違規(guī)的API涉及的微服務(wù)調(diào)用鏈路。應(yīng)用接受不同API請求時會有不同的微服務(wù)模塊參與響應(yīng)，為定位各API調(diào)用涉及到哪些微服務(wù)，KubeTea會逐一有間隔地向不同API發(fā)起調(diào)用，觀測參與響應(yīng)的微服務(wù)并與API之間建立映射。在特定API出現(xiàn)SLO違規(guī)時便可快速找出對應(yīng)的調(diào)用鏈路，此時該鏈路就是HP。

2.3 自動伸縮模塊

該模塊為容器化微服務(wù)應(yīng)用的調(diào)度作出決策，通過垂直維度和水平維度的自動伸縮，實現(xiàn)在提高資源利用率的同時優(yōu)化應(yīng)用的QoS。

2.3.1 垂直自動伸縮

垂直自動伸縮調(diào)整單一實例的資源配額以快速響應(yīng)負載變化。KubeTea在垂直方向設(shè)計了ESC，通過為實例動態(tài)調(diào)整余量（slack）使資源利用率提高，同時面對不同負載時保證QoS。Slack的計算方法見式（1），通過資源的給定配額與一段時間內(nèi)平均使用情況來表示。相應(yīng)地，新配額則通過式（2）進行計算。

slack=quota-Avg（utilization）［interval］quota（1）

new_quota=avg（utilization）［interval］×（1+slack）（2）

從資源能否壓縮角度來看，CPU是可壓縮資源，而內(nèi)存是不可壓縮資源，內(nèi)存不足會導(dǎo)致內(nèi)存溢出（out of memory，OoM），應(yīng)用無法正常運行。因此，將CPU和內(nèi)存的slack初始值分別設(shè)置為0.1和0.2，為內(nèi)存資源預(yù)留更多的余量。

在出現(xiàn)SLO違規(guī)時，伴隨負載突增或資源緊張，需要增加slack為微服務(wù)配置更多的資源以緩解SLO違規(guī)的情況。ESC采用算法1動態(tài)調(diào)整slack及資源配額。該算法的核心思想是對出現(xiàn)SLO違規(guī)的應(yīng)用配置更多的資源余量。由于某些情況下需要多次增加slack才能緩解SLO違規(guī)，為加快應(yīng)用服務(wù)質(zhì)量的恢復(fù)速度，本文使用一個負載和資源余量slack的映射表w2s來緩存歷史出現(xiàn)過的負載情況和對應(yīng)的slack數(shù)據(jù)。當應(yīng)用工作負載降低并且不再出現(xiàn)SLO違規(guī)時，ESC會相應(yīng)降低slack來提高資源利用率。其余正常情況下按照當前slack為應(yīng)用配置資源即可。相較于其他響應(yīng)式調(diào)度策略，ESC將服務(wù)質(zhì)量納入資源分配的參考范圍內(nèi)，在出現(xiàn)服務(wù)質(zhì)量下降時適當犧牲資源利用率為應(yīng)用提供更多的資源保障。

算法1 ESC彈性余量控制算法

輸入：初始余量slack_init；負載到余量映射表w2s。

輸出：新的資源配額new_quota。

func ESC（slack_init， w2s）：

slack：=slack_init // 初始化

statusInfo：=GetObversedInfo（） // 獲取當前應(yīng)用狀態(tài)

if IsSLOViolated（statusInfo） // 如果出現(xiàn)SLO違規(guī)

slack += slack_init // 增加 slack

w2s.Record（statusInfo，slack） // 記錄當前負載狀態(tài)

// 如果沒出現(xiàn)SLO違規(guī)且工作負載比上一次違規(guī)時的低

else if LoadLevel（state_info）<w2s.PreviousLoadLevel（）

slack-=slack_init

new_quota：=Reallocation（slack）

return new_quota

2.3.2 水平自動伸縮

水平自動伸縮主要應(yīng)對節(jié)點資源不足以創(chuàng)建新副本以及單副本申請的資源超過最大限額的情況。水平自動伸縮主要解決的問題是選擇哪個節(jié)點來放置新的或清理不需要的實例副本。KubeTea使用算法2進行新副本放置節(jié)點的選擇。在監(jiān)控和觀測模塊收集到信息后，狀態(tài)分析模塊從觀測到的微服務(wù)間調(diào)用信息，識別待調(diào)度微服務(wù)的上下游依賴微服務(wù)，對上下游微服務(wù)按照調(diào)用次數(shù)和調(diào)用是否具有雙向性排序，從而衡量微服務(wù)間的親和性。由于水平伸縮涉及到跨節(jié)點部署，該動作能夠影響應(yīng)用包含的微服務(wù)間通信時延。本文通過給出的affinity這一定義，將親和性程度高的微服務(wù)調(diào)度到同一物理節(jié)點或相近物理節(jié)點以降低應(yīng)用端到端時延，提高應(yīng)用的服務(wù)質(zhì)量。與常規(guī)在水平方向進行調(diào)度的工作相比，KubeTea將微服務(wù)間調(diào)用可觀測性的實現(xiàn)納入調(diào)度框架的一部分，通過水平自動伸縮變更資源配置的同時，利用affinity放置新服務(wù)實例以求降低微服務(wù)間通信的時間開銷。

算法2 新實例副本部署節(jié)點選擇算法

輸入：待調(diào)度的微服務(wù)srv。

輸出：優(yōu)選的節(jié)點node。

func NodeSelect（service）：

callInfo：= GetCallInfo（srv） // 獲得上下游調(diào)用信息

// 從callInfo中分析上下微服務(wù)

srvList：=callInfo.UpDownStreamSrv（callInfo）

srvList.SortByCountAnd2Way（） // 根據(jù)調(diào)用次數(shù)和雙向性排序

for s：= range srvList

if s.NodeIsAvailable（）

return s.Node

2.3.3 擴散導(dǎo)向的自動伸縮策略DOAS

本文提出DOAS旨在緩解應(yīng)用出現(xiàn)的SLO違規(guī)。通過為應(yīng)用增加資源配額以緩解QoS下降，有以下兩種選擇：

a）為構(gòu)成應(yīng)用的所有微服務(wù)增加資源配額。這種方式可能導(dǎo)致不必要的資源開銷，如圖1中“提交文章”功能對應(yīng)的API出現(xiàn)SLO違規(guī)時，為“media”微服務(wù)模塊增加資源并不能緩解，此時額外的資源開銷是無效且浪費的。

b）為相關(guān)的微服務(wù)增加資源配額。同樣考慮圖1中“提交文章”功能的API出現(xiàn)SLO違規(guī)，對該API涉及的調(diào)用鏈路上的微服務(wù)增加資源配額能緩解QoS下降的情況。因此就需要定位到哪些微服務(wù)需要擴容。

b）即本文提出的DOAS，通過擴容盡可能少的微服務(wù)來緩解SLO違規(guī)，避免非必要的資源開銷。本文通過定義HP對需要擴容的微服務(wù)進行定位，結(jié)合HA，逐漸將參與擴容的微服務(wù)范圍擴大。DOAS的執(zhí)行邏輯如圖4以及算法3所示。

算法3 基于DOAS的SLO違規(guī)緩解算法

輸入：出現(xiàn)SLO違規(guī)的API apis；HP的原始API到調(diào)用鏈路的映射a2p；參與DOAS的首輪微服務(wù)數(shù)量start；每輪增長數(shù)量add。

輸出：true或false表示是否成功緩解SLO違規(guī)以排查問題。

func DOAS（apis， a2p， start， add）：

// 獲取出現(xiàn)SLO違規(guī)的API涉及到的微服務(wù)

calledSrvs：= GetSrvs（apis，a2p）

calledSrvs.SortByHV（） // 將這些微服務(wù)按照HV排序

current：= start // 初始化當前參與的服務(wù)數(shù)量

while SLONotMitigate（） // 沒有緩解SLO時進行循環(huán)

if current > SrvSumCount

return false // 瓶頸不在資源采取其他措施

//這些微服務(wù)中HV處于前current的執(zhí)行ESC算法

calledSrvs.Top（current）.ESC（）

current += add // 下一輪使更多的微服務(wù)參與

return true

如圖4（a）所示，微服務(wù)架構(gòu)應(yīng)用中，不同的API請求對應(yīng)不同的后端微服務(wù)，當某API出現(xiàn)SLO違規(guī)時，可以直接將出現(xiàn)資源緊張的微服務(wù)范圍縮小到該API對應(yīng)的調(diào)用鏈路上。在算法3中使用a2p記錄API到其調(diào)用鏈路涉及到的微服務(wù)之間的映射關(guān)系，該關(guān)系也是由KubeTea的監(jiān)控和觀測模塊所捕獲的。DOAS選取部分微服務(wù)執(zhí)行ESC算法，為其增加資源配額，選取微服務(wù)的過程可以形象地用圖4（b）這三輪陰影的擴散來表示。由于API出現(xiàn)的服務(wù)質(zhì)量下降可能由該調(diào)用鏈路上的多個微服務(wù)所導(dǎo)致，所以DOAS的流程會執(zhí)行多輪，按照HV排序來增加微服務(wù)執(zhí)行ESC，直至SLO違規(guī)得到緩解。

對應(yīng)到算法3，首先規(guī)定參與DOAS的首輪微服務(wù)數(shù)量start以及每輪新增加的數(shù)量add，每一輪次中參與擴容的微服務(wù)數(shù)量為current，按照HV降序方式讓前current個微服務(wù)執(zhí)行ESC來擴容，逐步擴散至更多的微服務(wù)直至SLO違規(guī)得到緩解。KubeTea通過這種思路用盡可能少的資源開銷來緩解應(yīng)用出現(xiàn)的服務(wù)質(zhì)量下降。

3 實驗評估與結(jié)果分析

本文KubeTea主要使用Go語言實現(xiàn)，并以自定義控制器的形式部署在Kubernetes集群中以開展實驗評估。

3.1 實驗設(shè)置

a）集群設(shè)置。本文實驗所部署的Kubernetes集群有1個控制平面節(jié)點和5個工作節(jié)點，Kubernetes版本為1.26.3。節(jié)點均運行在虛擬機中，處理器型號為Intel Xeon CPU E5-2650 v4@2.20 GHz，控制平面節(jié)點配置為16vCore和16 GB RAM，工作節(jié)點配置為8vCore和16 GB RAM。

b）應(yīng)用設(shè)置。本文使用社交網(wǎng)絡(luò)應(yīng)用［14］參與實驗，如圖1所示，該應(yīng)用包含20余個不同的微服務(wù)模塊。其典型的架構(gòu)設(shè)計能反映微服務(wù)的特征，該項目還為微服務(wù)架構(gòu)的研究提供了一系列的基準應(yīng)用和工具。

c）負載設(shè)置。實驗中負載以請求每秒（req/s）表示，設(shè)置范圍從0～2 500 req/s以分析KubeTea應(yīng)對負載變化的表現(xiàn)。同時如表2所示，實驗定義3個級別的SLO以驗證DOAS的效果。

d）評價指標。實驗使用資源利用率和端到端時延這兩大指標衡量KubeTea的表現(xiàn)，上文提及的應(yīng)用服務(wù)質(zhì)量在實驗中以應(yīng)用端到端時延表示。資源利用率定義為資源實際使用量和資源配額的比值，例如為一個Pod分配1 GB內(nèi)存，實際使用512 MB，則該Pod內(nèi)存資源利用率為50%。端到端時延為發(fā)起API調(diào)用到收到響應(yīng)的時間差，后文中P50、P90和P99時延代表實驗中時延數(shù)據(jù)統(tǒng)計上的50、90和99分位數(shù)。通過這兩個指標度量KubeTea在提高資源利用率和保證應(yīng)用服務(wù)質(zhì)量上的表現(xiàn)。

3.2 非侵入式觀測帶來的優(yōu)勢

相較于Sidecar這類Pod層面侵入的方式，本文設(shè)計的非侵入式觀測資源友好且能提高應(yīng)用的QoS。實驗對比了Sidecar模式和本文使用的Sidecar-free模式下資源使用及應(yīng)用延遲方面的表現(xiàn)。Sidecar模式下部署Istio實現(xiàn)可觀測性，Sidecar-free模式下使用KubeTea來觀測網(wǎng)絡(luò)調(diào)用。如圖5（a）所示，本文提出的非侵入式觀測方法在端到端時延上最大有超過3 000的降低。圖5（b）（c）表明在資源使用方面，與Sidecar-free模式相比，Sidecar容器會額外使用超過50%的CPU和內(nèi)存資源。隨著業(yè)務(wù)容器的增加，倍增的Sidecar容器數(shù)量還將帶來更多的資源開銷，也會增加集群網(wǎng)絡(luò)平面復(fù)雜程度。

3.3 熱值HV和熱路徑HP的表征及其對DOAS的效果

實驗將“/compost-post”和“/read-home-timeline”兩個API生成的對應(yīng)調(diào)用鏈路作為HP。表3為KubeTea所觀測到的調(diào)用鏈路中涉及到的微服務(wù)模塊，并按照HV降序排列。實驗過程中對DOAS的start和add參數(shù)均設(shè)置為2，使用表2中medium等級觸發(fā)“/compose-post”API的SLO違規(guī)。如表4所示，經(jīng)過兩輪的DOAS，SLO違規(guī)情況得到緩解。

3.4 資源利用率分析

圖6展示了KubeTea與Kubernetes原生調(diào)度器在內(nèi)存和CPU上的資源利用情況。實驗中用Kubernetes原生的VPA配置“auto”模式來提供推薦的容器資源配額。

本文ESC能動態(tài)地為容器合理配置資源，在CPU和內(nèi)存資源利用率上均有提升。實驗發(fā)現(xiàn)對于低內(nèi)存需求的Pod，原生的VPA對內(nèi)存推薦配額較高，導(dǎo)致內(nèi)存資源浪費，KubeTea在內(nèi)存利用率方面高出26%。ESC同樣能在應(yīng)用空閑時壓低CPU配額，實驗表明CPU的利用率有17%的提升。

3.5 端到端時延表現(xiàn)

為驗證KubeTea使用親和性策略指導(dǎo)水平擴縮容的優(yōu)勢，本文將其與Kubernetes 原生HPA進行了對比實驗。實驗在1 500 req/s和2 500 req/s的負載下對應(yīng)用進行了端到端時延測試，并設(shè)定不同的副本數(shù)量以分析服務(wù)間調(diào)用時延對應(yīng)用整體QoS的影響。KubeTea在處理跨節(jié)點自動伸縮時，基于親和性的策略將相互調(diào)用頻繁的實例調(diào)度到同一節(jié)點上，進而有效地降低網(wǎng)絡(luò)時延。如圖7所示，在KubeTea的調(diào)度下，應(yīng)用平均端到端時延和P90時延分別有33%和20%的下降，對P90時延的優(yōu)化更加明顯。

相對于KubeTea面對SLO違規(guī)的主動處理機制，原生的Kubernetes調(diào)度機制無法緩解QoS下降。本文在實驗中使用了表2定義的SLO等級，并統(tǒng)計整個實驗進行中應(yīng)用的P50、P90和P99的時延，如圖8所示?？傮w時延表現(xiàn)上，KubeTea調(diào)度下的應(yīng)用P90時延改善了23%，P99時延改善了24%。

4 結(jié)束語

在容器云環(huán)境中部署微服務(wù)架構(gòu)應(yīng)用時，需要在提高集群資源利用率的同時保證應(yīng)用服務(wù)質(zhì)量。同時，容器云環(huán)境的復(fù)雜以及微服務(wù)架構(gòu)的特點給解決這一問題帶來了更大的困難。本文提出了一個面向容器化微服務(wù)的輕量級多維度調(diào)度框架KubeTea。與其他工作相比，本文將微服務(wù)的可觀測性納入框架能力中，并且在調(diào)度時考慮了微服務(wù)間親和性和應(yīng)用的服務(wù)質(zhì)量。KubeTea設(shè)計了非侵入式的方式實現(xiàn)可觀測性，為觀測和分析微服務(wù)間調(diào)用鏈路提供了輕量的手段。在垂直自動伸縮維度上提出ESC以提高資源利用率，在水平維度基于親和性策略調(diào)度副本以優(yōu)化應(yīng)用時延。此外，針對Kubernetes原生調(diào)度工具無法主動緩解服務(wù)質(zhì)量下降的問題，本文定義了HV和HP指標并提出DOAS來主動緩解SLO違規(guī)。最后通過實驗評估，KubeTea提升了21%的資源利用率，同時將應(yīng)用P90和P99的平均時延降低23%。

參考文獻：

［1］中國信息通信研究院. 云計算白皮書［EB/OL］. （2023-09-15） ［2024-02-23］. http：//www.caict.ac.cn/kxyj/qwfb/bps/202307/P020230725521473129120.pdf. （China Academy of Information and Communications Technology. Cloud computing white paper［EB/OL］. （2023-09-15） ［2024-02-23］. http：//www.caict.ac.cn/kxyj/qwfb/bps/ 202307/P020230725521473129120.pdf.）

［2］Bogner J， Zimmermann A， Wagner S. Analyzing the relevance of SOA patterns for microservice-based systems［C］//Proc of Central European Workshop on Services and Their Composition. Dresden， Germany： RWTH Aachen， 2018： 9-16.

［3］Villamizar M， Garcés O， Castro H， et al. Evaluating the monolithic and the microservice architecture pattern to deploy Web applications in the cloud［C］//Proc of 10th Computing Colombian Conference. Piscataway， NJ： IEEE Press， 2015： 583-590.

［4］Kang Hui， Le M， Tao Shu. Container and microservice driven design for cloud infrastructure devops［C］//Proc of IEEE International Conference on Cloud Engineering. Piscataway， NJ： IEEE Press， 2016： 202-211.

［5］Lu Chengzhi， Ye Kejiang， Xu Guoyao， et al. Imbalance in the cloud： an analysis on alibaba cluster trace［C］//Proc of IEEE International Conference on Big Data. Piscataway， NJ： IEEE Press， 2017： 2884-2892.

［6］Kilcioglu C， Rao J M， Kannan A， et al. Usage patterns and the economics of the public cloud［C］//Proc of the 26th International Conference on World Wide Web. ［S.l.］： International World Wide Web Conferences Steering Committee， 2017： 83-91.

［7］Shan Yizhou， Huang Yutong， Chen Yilun， et al. LegoOS： a disseminated， distributed OS for hardware resource disaggregation［C］//Proc of the 13th USENIX Conference on Operating Systems Design and Implementation. Berkeley，CA： USENIX Association， 2018： 69-87.

［8］工業(yè)和信息化部. 工業(yè)和信息化部關(guān)于印發(fā)《新型數(shù)據(jù)中心發(fā)展三年行動計劃 （2021—2023年）》的通知［EB/OL］. （2021-07-04） ［2024-02-23］. https：//www.gov.cn/zhengce/zhengceku/2021-07/14/content_5624964.htm. （Ministry of Industry and Information Technology. Ministry of Industry and Information Technology on the issuance of the “Three-Year Action Plan for the Development of New Type Data Centers （2021-2023）”notice ［EB/OL］. （2021-07-04） ［2024-02-23］. https：//www.gov.cn/zhengce/ zhengceku/ 2021-07/14/content_5624964. htm.）

［9］Tirmazi M， Barker A， Deng Nan， et al. Borg： the next generation［C］//Proc of the 15th European Conference on Computer Systems. New York： ACM Press， 2020： 1-14.

［10］美團技術(shù)團隊. 提升資源利用率與保障服務(wù)質(zhì)量， 魚與熊掌不可兼得？ ［EB/OL］. （2022-08-11） ［2024-02-24］.https：//tech.meituan.com/2022/08/11/load-auto-regulator.html. （Meituan Technical Team. Are enhancing resource utilization and ensuring service quality mutually exclusive？ ［EB/OL］.（2022-08-11）［2024-02-23］.https：//tech.meituan.com/2022/08/11/load-auto-regulator. html.）

［11］Li Bowen， Peng Xin， Xiang Qilin， et al. Enjoy your observability： an industrial survey of microservice tracing and analysis［J］. Empirical Software Engineering， 2022， 27： 1-28.

［12］張齊勛， 吳一凡， 楊勇， 等. 微服務(wù)系統(tǒng)服務(wù)依賴發(fā)現(xiàn)技術(shù)綜述［J］. 軟件學報， 2024， 35（1）： 118-135. （Zhang Qixun， Wu Yifan， Yang Yong， et al. Survey on service dependency discovery technologies for microservice systems［J］. Journal of Software， 2024， 35（1）： 118-135.）

［13］李海飛， 徐政鈞. 服務(wù)網(wǎng)格中的級聯(lián)故障預(yù)測方法［J］. 計算機應(yīng)用與軟件， 2021，38（11）： 121-130. （Li Haifei， Xu Zhengjun. Cascading failure prediction method in service mesh［J］. Computer Applications and Software， 2021， 38（11）： 121-130.）

［14］Narayanan D， Kazhamiaka F， Abuzaid F， et al. Solving large-scale granular resource allocation problems efficiently with pop［C］//Proc of the 28th Symposium on Operating Systems Principles. New York： ACM Press， 2021： 521-537.

［15］Narayanan D， Santhanam K， Kazhamiaka F， et al. Heterogeneity-aware cluster scheduling policies for deep learning workloads［C］//Proc of the 14th USENIX Conference on Operating Systems Design and Implementation.［S.l.］： USENIX Association， 2020： 481-498.

［16］Baarzi A F， Kesidis G. SHOWAR： right-sizing and efficient scheduling of microservices［C］//Proc of ACM Symposium on Cloud Computing. New York： ACM Press， 2021： 427-441.

［17］宋程豪， 江凌云. 基于負載預(yù)測的微服務(wù)混合自動擴展［J］. 計算機應(yīng)用研究， 2022， 39（8）： 2273-2277，2315. （Song Chenghao， Jiang Lingyun. Hybrid autoscaling of microservices based on workload prediction［J］. Application Research of Computers， 2022， 39（8）： 2273-2277，2315.）

［18］Weng Qizhen， Xiao Wencong， Yu Yinghao， et al. MLaaS in the wild： workload analysis and scheduling in large-scale heterogeneous GPU clusters［C］//Proc of the 19th USENIX Symposium on Networked Systems Design and Implementation. ［S.l.］： USENIX Association， 2022： 945-960.

［19］Zhang Yanqi， Hua Weizhe， Zhou Zhuangzhuang， et al. Sinan： ML-based and QoS-aware resource management for cloud microservices［C］//Proc of the 26th ACM International Conference on Architectu-ral Support for Programming Languages and Operating Systems. New York： ACM Press， 2021： 167-181.

［20］Gan Yu， Zhang Yanqi， Cheng Dailun， et al. An open-source benchmark suite for microservices and their hardware-software implications for cloud & edge systems［C］//Proc of the 24th International Confe-rence on Architectural Support for Programming Languages and Opera-ting Systems. New York： ACM Press， 2019： 3-18.

［21］Luo Shutian， Xu Huanle， Lu Chengzhi， et al. Characterizing microservice dependency and performance： alibaba trace analysis［C］//Proc of ACM Symposium on Cloud Computing. New York： ACM Press， 2021： 412-426.

［22］Verma A， Pedrosa L， Korupolu M， et al. Large-scale cluster management at Google with Borg［C］//Proc of the 10th European Conference on Computer Systems. New York： ACM Press， 2015： 1-17.

［23］Kubernetes Authors. Kubernetes［EB/OL］. （2014-06-06） ［2024-01-08］. https：//kubernetes.io/.［24］Rzadca K， Findeisen P， Swiderski J， et al. Autopilot： workload autoscaling at Google［C］//Proc of the 15th European Conference on Computer Systems. New York： ACM Press， 2020： 1-16.

［25］Baarzi A F， Zhu T， Urgaonkar B. BurScale： using burstable instances for cost-effective autoscaling in the public cloud［C］//Proc of ACM Symposium on Cloud Computing. New York： ACM Press， 2019： 126-138.

［26］Delimitrou C， Kozyrakis C. Quasar： resource-efficient and QoS-aware cluster management［J］. ACM SIGARCH Computer Architecture News， 2014， 42（1）： 127-144.

［27］Mostofi V M E， Krishnamurthy D， Arlitt M. Fast and efficient performance tuning of microservices ［C］//Proc of the 14th International Confe-rence on Cloud Computing. Piscataway，NJ：IEEE Press， 2021： 515-520.

［28］Venkataraman S， Yang Zongheng， Franklin M， et al. Ernest： efficient performance prediction for Large-Scale advanced analytics［C］//Proc of the 13th USENIX Conference on Networked Systems Design and Implementation. Berkeley，CA： USENIX Association， 2016： 363-378.

［29］Qiu Haoran， Banerjee S S， Jha S， et al. FIRM： an intelligent fine-grained resource management framework for SLO-oriented microservices［C］//Proc of the 14th USENIX Conference on Operating Systems Design and Implementation. Berkeley，CA： USENIX Association， 2020： 805-825.

［30］Iorgulescu C， Azimi R， Kwon Y， et al. PerfIso： performance isolation for commercial latency-sensitive services［C］//Proc of USENIX Conference on Usenix Annual Technical Conference. Berkeley，CA： USENIX Association， 2018： 519-532.

［31］Kubernetes. Vertical-pod-autoscaler［EB/OL］.［2024-02-25］. https：//github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscale/.

［32］Kubernetes. Horizontal pod autoscaling［EB/OL］. ［2024-02-25］. https：//kubernetes. io/docs/tasks/run-application/horizontal-pod-autoscale/.

［33］Leverich J， Kozyrakis C. Reconciling high server utilization and sub-millisecond quality-of-service［C］//Proc of the 9th European Confe-rence on Computer Systems. New York： ACM Press， 2014： 1-14.

［34］Fu S， Gupta S， Mittal R， et al. On the use of ML for blackbox system performance prediction［C］//Proc of the 18th USENIX Symposium on Networked Systems Design and Implementation. Berkeley，CA： USENIX Association， 2021： 763-784.

［35］Prometheus. Prometheus-from metrics to insight［EB/OL］. ［2024-01-08］. https：//prometheus.io/.

［36］Cilium Authors. Hubble-network， service & security observability for Kubernetes using eBPF［EB/OL］. ［2024-01-08］. https：//github. com/cilium/hubble.

［37］eBPF.io. eBPF， dynamically program the kernel for efficient networking， observability， tracing， and security［EB/OL］. ［2024-01-06］. https：//ebpf.io/.

收稿日期：2024-01-11；修回日期：2024-03-06 基金項目：國家重點研發(fā)計劃資助項目（2020YFB1805400）；國家自然科學基金資助項目（62032002，62101358）；四川省自然科學青年基金資助項目（2023NSFSC1395）；四川大學專職博士后研發(fā)基金資助項目（2023SCU12127）

作者簡介：李宗霖（1999—），男，山東臨沂人，碩士研究生，主要研究方向為云計算、容器技術(shù)、云安全；何俊江（1993—），男（通信作者），四川內(nèi)江人，助理研究員，碩導(dǎo)，博士，主要研究方向為人工免疫、云計算、網(wǎng)絡(luò)安全、數(shù)據(jù)挖掘（hejunjiang@scu.edu.cn）；李汶珊（1995—），女，四川廣安人，講師，博士研究生，主要研究方向為數(shù)據(jù)科學、機器學習、生物信息學；呂虓（1987—），男，貴州正安人，高級工程師，博士研究生，主要研究方向為大數(shù)據(jù)、網(wǎng)絡(luò)安全、人工免疫；蘭小龍（1989—），男，四川成都人，副研究員，博導(dǎo)，博士，主要研究方向為物理層安全、入侵檢測、移動邊緣計算；李濤（1965—），男，四川廣安人，教授，博導(dǎo)，博士，主要研究方向為人工免疫、云安全、大數(shù)據(jù)安全、網(wǎng)絡(luò)信息對抗技術(shù)．