基于Kubemark的微服務(wù)性能仿真測試研究*

雷 擎

(對外經(jīng)濟貿(mào)易大學(xué)信息學(xué)院，北京 100029)

1 引言

隨著云計算的發(fā)展，微服務(wù)架構(gòu)的優(yōu)勢使其逐漸成為云服務(wù)提供商普遍采用的軟件體系結(jié)構(gòu)。微服務(wù)對其構(gòu)成的云應(yīng)用程序進(jìn)行的細(xì)粒度控制，縮短了將新功能投入運營的時間，已被諸如Facebook、LinkedIn和Amazon之類的大型Web公司廣泛使用。微服務(wù)通過基于虛擬機VM或基于容器虛擬化的基礎(chǔ)架構(gòu)技術(shù)，可以提供高度的可伸縮性、可用性和可移植性。但是，由于基于微服務(wù)的部署更具動態(tài)性和易變性，架構(gòu)和部署方式不同于傳統(tǒng)應(yīng)用程序，也給系統(tǒng)監(jiān)測和性能建模帶來了新的挑戰(zhàn)。

與傳統(tǒng)軟件架構(gòu)相比，微服務(wù)具有更高的發(fā)布頻率和速度，在運營環(huán)境中進(jìn)行廣泛性能測試的可行性受到限制，所以基于單體服務(wù)器的性能評估和傳統(tǒng)軟件測試的性能評估都不完全適合于微服務(wù)[1]。通過對微服務(wù)和云測試領(lǐng)域已發(fā)表的論文研究發(fā)現(xiàn)，學(xué)者們研究的成果集中在云應(yīng)用程序建模、構(gòu)建和服務(wù)方面，對云服務(wù)性能測試研究較少，大多數(shù)與微服務(wù)的性能測試沒有直接關(guān)系。對于微服務(wù)性能測試方面的研究，包括測試方法、測試工具、基準(zhǔn)測試以及評價標(biāo)準(zhǔn)和機制都還處于探索階段。

針對微服務(wù)的服務(wù)特性，本文借鑒Web服務(wù)質(zhì)量的測試方法和評價標(biāo)準(zhǔn)，基于Kubernetes平臺對微服務(wù)的虛擬化平臺和架構(gòu)性能進(jìn)行測試研究。在實驗過程中采用了新的仿真工具Kubemark，通過Kubemark在Kubernets上部署集群，使用從運營數(shù)據(jù)中提取出的負(fù)載模型加載仿真負(fù)荷，測試不斷增加的負(fù)載或突然的負(fù)載峰值是否可能會違反Kubernetes的服務(wù)級別目標(biāo)SLO(Service Level Objectives)，測試不同類型的微服務(wù)負(fù)載會對系統(tǒng)資源產(chǎn)生的性能影響，是對微服務(wù)性能測試方法、工具和評價標(biāo)準(zhǔn)的一種嘗試和探索。

2 背景和相關(guān)工作

2.1 國內(nèi)外研究現(xiàn)狀

通過對國內(nèi)外微服務(wù)研究領(lǐng)域的研究成果進(jìn)行對比，本文發(fā)現(xiàn)雖然有一些學(xué)者對于微服務(wù)安全性、可用性和系統(tǒng)性能進(jìn)行了研究，但研究的重點主要集中在體系結(jié)構(gòu)方面[2]。

國外的學(xué)者對于微服務(wù)性能方面的研究主要從2個角度展開：一是從集群硬件平臺角度，在微服務(wù)體系結(jié)構(gòu)下，分別直接加載CPU的基準(zhǔn)測試、網(wǎng)絡(luò)性能基準(zhǔn)測試，收集CPU利用率、內(nèi)存訪問延遲、網(wǎng)絡(luò)帶寬和延遲以及存儲開銷等數(shù)據(jù)，使用硬件的性能指標(biāo)來衡量微服務(wù)平臺的性能[3,4]；另一方面是基于AWS Lambda、Microsoft Azure等商業(yè)的云平臺，通過API加載負(fù)荷，測試虛擬機和容器的啟動運行時間、狀態(tài)轉(zhuǎn)換、負(fù)載能力等來評估不同微服務(wù)架構(gòu)的虛擬平臺性能[5,6]。另外，有一些學(xué)者在云計算的虛擬化技術(shù)之間的性能比較領(lǐng)域做了大量工作，例如對于同樣的基準(zhǔn)測試，測試KVM、Docker、LXC和CoreOs Rocket等對于系統(tǒng)硬件性能的差異[7]。這些研究成果也可以從側(cè)面反映采用不同虛擬化技術(shù)的系統(tǒng)中，微服務(wù)可能呈現(xiàn)的性能。

國內(nèi)的學(xué)者對于微服務(wù)的研究主要集中在應(yīng)用方面，對于云平臺性能的研究在2015年已經(jīng)有學(xué)者涉及[8]，在輕量虛擬化技術(shù)之間的性能對比，以及虛擬機和容器技術(shù)的性能方面，國內(nèi)學(xué)者已經(jīng)開始有所關(guān)注[9 - 11]。但是，有關(guān)這些問題研究的方法、深度和熱度，與國外的研究相比還有很大的距離。有關(guān)微服務(wù)性能和測試方面的研究，也還沒有搜索到相關(guān)的學(xué)術(shù)論文。

從國內(nèi)外的研究來看，目前微服務(wù)性能測試的研究與用戶所獲得服務(wù)的性能和質(zhì)量都沒有直接關(guān)系，也缺少基于Kubernetes平臺的性能研究。由于在微服務(wù)架構(gòu)中，每個微服務(wù)都實現(xiàn)自己的功能，并通過與語言和平臺無關(guān)的API與其他微服務(wù)進(jìn)行通信，微服務(wù)的資源使用量取決于所實現(xiàn)的功能和工作負(fù)載，因此本文借鑒Web服務(wù)性能評估方法，直接測試微服務(wù)的吞吐量、請求成功率、響應(yīng)時間分布等性能指標(biāo)來進(jìn)行微服務(wù)系統(tǒng)性能評估，是一個有意義的嘗試。

2.2 Kubertnetes體系結(jié)構(gòu)

云計算的2個關(guān)鍵技術(shù)——資源管理中的隔離技術(shù)和控制技術(shù)，是云計算根據(jù)消費者需求動態(tài)分配和重新分配不同的物理和虛擬資源的基礎(chǔ)，從而能夠?qū)崿F(xiàn)云計算的多負(fù)載、高并行管理和運行。資源隔離是指一項工作負(fù)載的執(zhí)行不能影響同一系統(tǒng)上另一工作負(fù)載的執(zhí)行要求。資源控制是指將工作負(fù)載限制為一組特定資源的能力。目前云資源管理主要基于2種技術(shù)：虛擬機和容器。研究人員發(fā)現(xiàn)，基于以Docker為代表的容器化帶來的開銷更少，與基于虛擬機管理程序的云相比，具有更好的資源控制能力，可以獲得更好的應(yīng)用程序性能。但是，微服務(wù)使用容器技術(shù)以Docker模式進(jìn)行部署，隔離性也相對較差，如果需要很高的安全性，就必須通過犧牲純?nèi)萜鞑渴鸬男阅軄慝@得更多可靠的隔離。

Kubernetes是一個開源的容器編排系統(tǒng)，基本工作單元稱為Pod。每一個Pod都擁有其自己的唯一IP地址，可以與集群中的任何其他Pod相互訪問。Kubernetes將一個或多個容器部署在Pod中，在靈活性和隔離性上有更多的優(yōu)勢[12]。

Kubernetes高層架構(gòu)由控制組件和監(jiān)測組件組成。 控制組件保持整個系統(tǒng)功能一致性，監(jiān)測組件負(fù)責(zé)計算系統(tǒng)資源的使用情況，收集指標(biāo)，監(jiān)視整個系統(tǒng)的運行狀況，如圖1所示。

Figure 1 Kubernetes architecture圖1 Kubernetes體系機構(gòu)

(1)控制組件。

控制組件主要包含7個組件。其中Apiserver是Kubernetes控制平面的前端，即主服務(wù)器上提供Kubernetes API服務(wù)的組件。 Kubectl提供針對Kubernetes集群運行命令的命令行界面。 etcd實現(xiàn)一致且高度可用的鍵值存儲，用作所有集群數(shù)據(jù)的Kubernetes后備存儲。 Scheduler是主服務(wù)器上的組件，用于監(jiān)視未分配節(jié)點的新Pod，并選擇一個要在其上運行的節(jié)點。 Controller-Manager是主機上的運行控制器。 從邏輯上講，每個控制器是一個單獨的進(jìn)程，但是為了降低復(fù)雜性，它們都被編譯為單個二進(jìn)制文件并在一個進(jìn)程中運行。 Kubelet是集群中每個節(jié)點上運行的代理，管理并確保容器正常運行。Kube-Proxy組件通過在主機上維護(hù)網(wǎng)絡(luò)規(guī)則并執(zhí)行連接轉(zhuǎn)發(fā)來啟用Kubernetes服務(wù)。

(2)監(jiān)測組件。

監(jiān)測組件主要包含2個組件。其中cAdvisor是專門為容器而構(gòu)建的，是開源容器資源使用和性能分析代理，支持Docker容器。在Kubernetes中，cAdvisor已集成到Kubelet二進(jìn)制文件中。cAdvisor會自動發(fā)現(xiàn)計算機中的所有容器，并收集CPU、內(nèi)存、文件系統(tǒng)和網(wǎng)絡(luò)使用情況統(tǒng)計信息。cAdvisor還可以通過分析計算機上的“root”容器來提供整個計算機的使用情況。Heapster是Kubernetes 1.0.6及更高版本兼容的性能監(jiān)視和指標(biāo)收集系統(tǒng)，不僅可以收集有關(guān)系統(tǒng)的工作負(fù)載，Pod和容器的性能指標(biāo)，還可以收集群集生成的事件和其他信號。Heapster完全開源，并且支持多種用于持久存儲數(shù)據(jù)的后端。

2.3 Kubemark體系結(jié)構(gòu)

本文采用Kubemark模擬集群測試工具來實現(xiàn)微服務(wù)性能測試的研究。Kubemark是Kubernetes的一個獨立模塊，可以用于構(gòu)建Kubernetes的模擬測試集群，進(jìn)行Kubernetes上微服務(wù)的性能測試[13]。

在頂層設(shè)計上，Kubemark集群由2部分組成(如圖2所示)：一個真實的控制節(jié)點(Kubemark Master Node)和由一組“虛擬(Hollow)”節(jié)點構(gòu)成的模擬集群(External Cluster)。其中任何加前綴“虛擬(Hollow)”的組件都是實際組件對應(yīng)的模擬組件，內(nèi)部使用其真實核心代碼實現(xiàn)。例如Kubelet的對應(yīng)模擬組件是HollowKubelet。Kubemark使用這些模擬組件創(chuàng)建仿真測試集群，從而確保了模擬性能測試程序的可維護(hù)性。模擬集群建立在真實的Kubernetes集群之上，用每一個真實的Pod可以作為模擬集群中一個工作節(jié)點(HollowNode)，其中運行模擬組件HollowKubelet、HollowProxy和HollowNodeProblemDetector。因此，單個真實節(jié)點能夠運行多套Kubelet和Kube-Proxy程序集來模擬多個節(jié)點。到Kubernetes v1.6為止，Kubemark可以支持5 000個節(jié)點的集群規(guī)模。實際上，Kubernetes所有基準(zhǔn)測試是基于Kubemark構(gòu)建的模擬集群，而不需要構(gòu)建數(shù)千個真實節(jié)點。

Figure 2 Kubemark architecture圖2 Kubemark體系結(jié)構(gòu)

通過Kubemark性能測試工具，本文可以使用較少的硬件資源構(gòu)建大型的Kubernetes模擬集群，配置模擬集群的應(yīng)用測試數(shù)據(jù)集，在模擬的Kubernetes集群上運行端到端測試e2e(End-to-End)，獲得集群的性能指標(biāo)。Kubemark集群的測試數(shù)據(jù)雖然與真實集群略有不同，但可以代表真實集群的數(shù)據(jù)。因此，Kubemark可用于直接在真實集群上運行端到端測試，作為對真實集群執(zhí)行性能測試的方案。

3 測試設(shè)計和實驗

3.1 微服務(wù)性能度量指標(biāo)選取

云平臺的用戶通常通過Internet從Web瀏覽器訪問自己訂制的資源(例如數(shù)據(jù)、軟硬件資源或第三方服務(wù))，并且通過與云服務(wù)提供商所簽定的合同，即服務(wù)級別協(xié)議SLA(Service-Level Agreement)，來為使用的計算機資源和服務(wù)付費。SLA規(guī)定了服務(wù)提供商在給定價格必須提供的服務(wù)質(zhì)量QoS(Quality of Service)，包括服務(wù)時間段、服務(wù)響應(yīng)時間和吞吐量等。服務(wù)性能QoS的要求一般體現(xiàn)為服務(wù)響應(yīng)時間和吞吐量。與吞吐量相比，Web客戶更直接的體驗通常是服務(wù)響應(yīng)時間。例如，點擊一個鏈接，看到響應(yīng)頁面的時間的長短會讓用戶對Web服務(wù)的質(zhì)量有更加直觀的感覺。

因此，本文在測試中對微服務(wù)的性能進(jìn)行度量的標(biāo)準(zhǔn)采用RFC 2679和IETF RFC5166定義的p百分位數(shù)，也就是在服務(wù)響應(yīng)時間某界限內(nèi)的服務(wù)請求所占總量的百分比，又稱為百分位數(shù)延遲。這個標(biāo)準(zhǔn)在服務(wù)和網(wǎng)絡(luò)性能研究中已經(jīng)被研究人員廣泛采用[14,15]。假定fT(t)是響應(yīng)時間T的概率分布函數(shù)。TD是客戶根據(jù)客戶支付的費用請求，并與其服務(wù)提供商達(dá)成一致的期望目標(biāo)響應(yīng)時間，則保證SLA服務(wù)性能指標(biāo)的公式為：

(1)

其中，客戶在不到TD的時間得到服務(wù)響應(yīng)的服務(wù)請求，至少占所有請求總數(shù)的γ%，這個性能指標(biāo)就稱為p百分位數(shù)。通過這個性能指標(biāo)，客戶可以統(tǒng)計服務(wù)的QoS是否達(dá)到服務(wù)商承諾的標(biāo)準(zhǔn)；另一方面，服務(wù)商可以通過這個指標(biāo)進(jìn)行反向計算，來測量系統(tǒng)提供各種不同服務(wù)的性能差異，以及整個系統(tǒng)所提供的總體服務(wù)性能和業(yè)務(wù)可擴展尺度。

SLA中具體定義服務(wù)響應(yīng)時間的是服務(wù)級別目標(biāo)SLOs，使用Kubernetes定義的服務(wù)性能標(biāo)準(zhǔn)如表1所示。

Table 1 SLOs for service response time

在實驗中，通過Kubemark的監(jiān)測代理獲取每個服務(wù)請求所發(fā)出的請求時間和響應(yīng)資源時間，然后對占所有請求總數(shù)分別在50%,90%和99%時，對這些服務(wù)請求的響應(yīng)時間界限進(jìn)行統(tǒng)計，以此來測度系統(tǒng)提供各種不同微服務(wù)的性能差異，以及在系統(tǒng)微服務(wù)負(fù)載逐步增加時，Kubernetes中各種資源響應(yīng)的情況，測度不同微服務(wù)對于系統(tǒng)性能的壓力和影響情況。

3.2 測試實驗設(shè)計

性能測試是為了獲得系統(tǒng)在某種特定的條件下(包括特定的負(fù)載條件下)的性能指標(biāo)數(shù)據(jù)。本文測試方案包括密度測試(Density Testing)和負(fù)載測試(Load Testing)。密度測試是測試一個節(jié)點支持不同數(shù)量Pod時的各項性能指標(biāo)。通過密度測試，可以選擇單節(jié)點最佳的Pod配置數(shù)量。負(fù)載測試是在系統(tǒng)上模擬實際用戶負(fù)載的過程，檢測微服務(wù)及其系統(tǒng)在正常和高負(fù)載期間的行為。

本文實驗基于Kubernetes，采用集群模擬工具Kubemark作為測試工具，使用腳本語言創(chuàng)建一個包含100個節(jié)點的模擬測試集群，模擬測試集群平均節(jié)點密度采用每個節(jié)點設(shè)置30個Pods，如表2所示。測試中，采用端到端測試策略加載數(shù)據(jù)，測試Kubernetes通過REST over HTTP提供的系統(tǒng)級微服務(wù)性能。

Table 2 Simulation cluster configuration

測試的數(shù)據(jù)根據(jù)端到端腳本設(shè)計測試任務(wù)加載，測試包括POST、PUT、DELETE、PATCH和GET等各種API請求對系統(tǒng)資源操作時，Kubernetes所提供的微服務(wù)性能，具體的各種API的請求數(shù)量不定。在測試時，針對每一個API請求，采集在處理這個請求時所使用到的各種系統(tǒng)資源響應(yīng)時間數(shù)據(jù)。例如，采集Kubernetes平臺響應(yīng)POST請求所需要的endpoints、pods、nodes等資源信息，獲取其服務(wù)響應(yīng)時間數(shù)據(jù)。由于各種API請求使用的系統(tǒng)資源有很大部分相同，例如pods、namespaces等，表3中間一列列出了測試中所有的資源對象，對應(yīng)于表3中左邊一列所有的API操作。具體每一種API操作對于系統(tǒng)資源的使用，在后續(xù)有具體圖表說明。例如，向Kubernetes平臺POST其定義的資源endpoints，獲取其服務(wù)響應(yīng)時間數(shù)據(jù)。資源具體的測試動作和所操作的資源對象如表3所示。

Table 3 Tests tasks and resource objects

在測試過程中，主要采集API調(diào)用的服務(wù)響應(yīng)延遲和Pod啟動時間數(shù)據(jù)，選取微服務(wù)的關(guān)鍵SLI(Service Level Indicator)服務(wù)請求延遲，獲取指標(biāo)在百分位為50,90和99時的數(shù)據(jù)值作為測試結(jié)果數(shù)據(jù)。

3.3 測試結(jié)果和分析

(1)密度測試。

本文進(jìn)行的密度測試是測試集群Pod創(chuàng)建后進(jìn)行調(diào)度，然后配置到每個節(jié)點上，最后成功啟動所耗費的時間。測試過程中，每個節(jié)點將從無到有完成30個Pods配置啟動，對于模擬測試集群的100個節(jié)點，將有3 000個Pods需要創(chuàng)建、調(diào)度、運行并啟動。圖3中展示了在測試過程中50%,90%,99%和100%的Pods成功啟動時所耗費的時間延遲，并通過堆積圖顯示了啟動過程中各階段所耗費的時間延遲。通過這個測試可以看出，在系統(tǒng)微服務(wù)負(fù)載逐步增加時，總體上對微服務(wù)性能的影響，通過Kubernetes中各種資源響應(yīng)的情況(如Pod)可以看出，不同微服務(wù)對于系統(tǒng)性能的壓力和影響情況，限于篇幅本文只給出了對于GET和LIST微服務(wù)各種系統(tǒng)資源的響應(yīng)時間。

Figure 3 Delay of each stage of Pod startup in Density Testing圖3 密度測試中Pod完成啟動的各階段延時

在完成所有Pods啟動過程中，平臺也同時模擬用戶發(fā)出微服務(wù)請求，通過DELETE、GET、LIST、PATCH、POST和PUT對所有的資源進(jìn)行操作。其中對Pods進(jìn)行操作的各種服務(wù)請求響應(yīng)時間延遲如圖4所示。圖4中分別給出了50%,90%和99%的請求被成功響應(yīng)的時間延遲。

Figure 4 Microservice performance for Pod operations in Density Testing圖4 密度測試中對Pod操作的微服務(wù)性能

表3中其他資源的操作性能，在測試中都有相應(yīng)的性能數(shù)據(jù)產(chǎn)生，本文選取了GET和LIST微服務(wù)請求作為示例，分別給出了50%,90%和99%的請求被成功響應(yīng)的時間延遲，如圖5和圖6所示。圖中的x軸是操作的資源對象，標(biāo)識是參照表3的資源對象縮寫。

Figure 5 Request response delay for GET requests in Density Testing圖5 密度測試中GET請求的請求響應(yīng)延遲

Figure 6 Request response delay of LIST request in Density Testing圖6 密度測試中LIST請求的請求響應(yīng)延遲

(2)負(fù)載測試。

負(fù)載測試通常是根據(jù)預(yù)期的客戶行為和系統(tǒng)日常狀態(tài)對系統(tǒng)運行時負(fù)荷、狀態(tài)和用戶服務(wù)請求進(jìn)行建模。負(fù)載測試中通過向系統(tǒng)加載模擬的負(fù)荷和服務(wù)請求，查驗系統(tǒng)中各種資源的使用狀況和響應(yīng)時間，從而衡量系統(tǒng)的服務(wù)質(zhì)量(QoS)性能，以及確定系統(tǒng)在正常和預(yù)期峰值負(fù)載條件下的行為。一般情況下，在允許軟件系統(tǒng)上線之前，都需要在與生產(chǎn)環(huán)境相同的測試環(huán)境中進(jìn)行負(fù)載和性能測試。如果系統(tǒng)或服務(wù)受服務(wù)級別協(xié)議或SLA約束，則負(fù)載測試尤為重要。

本文使用Kubemark建立了Kubernetes平臺日常運行模型，通過端到端測試模式模擬用戶行為加載了對各種系統(tǒng)資源操作的微服務(wù)請求，具體的操作請求和系統(tǒng)資源如表3所示。在測試過程中系統(tǒng)提供各種不同微服務(wù)的性能差異，本文實驗收集了DELETE、GET、LIST、PATCH、POST和PUT等對表3中所有資源進(jìn)行操作服務(wù)請求的相關(guān)數(shù)據(jù)，分析所有這些統(tǒng)計數(shù)據(jù)并生成負(fù)載測試報告，從這些報告中可以看出各種不同微服務(wù)的性能差異。本節(jié)選取具有代表性的數(shù)據(jù)作為示例進(jìn)行分析，包括資源Pod的各種操作請求的響應(yīng)時間延遲(如圖7所示)、GET、LIST微服務(wù)請求的響應(yīng)時間延遲(如圖8和圖9所示)。

Figure 7 Performance of microservice for Pod operations in Load Testing圖7 負(fù)載測試中對Pod操作的微服務(wù)性能

從圖7可以看出，在對Pod的操作提供服務(wù)時，90%的GET、LIST、PATCH、POST和PUT請求可以在5 000 ms內(nèi)得到響應(yīng)，其中50%的服務(wù)請求得到響應(yīng)的延遲時間是另40%的一半左右，而剩余的9%請求，需要比90%的請求耗費多1～3倍的時間才能得到響應(yīng)。相比較而言，對Pod的DELETE操作請求與其他操作的區(qū)別比較明顯，它耗費12 000 ms左右才能完成90%的請求響應(yīng)，這比其他操作的多1～2倍的時間。但總體上說，這些服務(wù)響應(yīng)時間都遠(yuǎn)遠(yuǎn)小于1 s，符合Kubernetes所定義的SLOs，即99%的API調(diào)用在1 s內(nèi)響應(yīng)。

圖8和圖9分別給出了GET和LIST對各種資源的操作請求的響應(yīng)時間，包括成功地響應(yīng)50%,90%和99%請求的時間延遲。圖中的x軸是操作的資源對象，標(biāo)識是參照表3的資源對象縮寫。其中PATCH、POST和PUT請求呈現(xiàn)的數(shù)據(jù)形態(tài)與圖8的GET相似。

Figure 8 Request response delay for GET request in Load Testing圖8 負(fù)載測試中GET請求的請求響應(yīng)延遲

Figure 9 Request response delay of LIST request in Load Testing圖9 負(fù)載測試中LIST請求的請求響應(yīng)延遲

4 結(jié)束語

本文使用集群仿真工具Kubemark創(chuàng)建了100個節(jié)點Kubernetes集群，選擇端到端(End-to-End)的測試策略對Kubernetes所提供的微服務(wù)性能進(jìn)行測試，并給出了集群微服務(wù)的性能分析。實驗結(jié)果表明，通過模擬真實平臺的運行狀況，仿真測試能夠給出集群資源的利用狀態(tài)和對資源操作的相關(guān)性能指標(biāo)。仿真測試是云平臺微服務(wù)性能測試的有效研究方法。通過仿真測試可以規(guī)避在真實云平臺微服務(wù)性能測試所面臨的運營、成本、規(guī)模、安全、測試數(shù)據(jù)等問題。如果在生產(chǎn)環(huán)境中出現(xiàn)了系統(tǒng)可用性問題，可以通過對運營時的負(fù)載特點進(jìn)行仿真實驗來解決，或者通過仿真實驗來發(fā)現(xiàn)生產(chǎn)環(huán)境中有可能存在的致命問題。