可擴(kuò)展的應(yīng)用可能會(huì)采用水平或垂直擴(kuò)縮容來(lái)動(dòng)態(tài)調(diào)整云端資源。為了幫助選擇最佳策略，本文主要對(duì)比了kubernetes中的水平和垂直擴(kuò)縮容。通過(guò)對(duì) Web 應(yīng)用程序進(jìn)行綜合負(fù)載測(cè)量實(shí)驗(yàn)，結(jié)果表明水平擴(kuò)縮容的效率更高，對(duì)負(fù)載變化的響應(yīng)更快，且對(duì)應(yīng)用程序響應(yīng)時(shí)間的影響更小。

簡(jiǎn)介

云服務(wù)的負(fù)載可能會(huì)隨時(shí)間變動(dòng)，為了實(shí)現(xiàn)可擴(kuò)展，需要依據(jù)特定的指標(biāo)(如CPU)來(lái)采取自動(dòng)擴(kuò)容策略，以此來(lái)擴(kuò)大應(yīng)用的處理能力。為此，我們需要均衡應(yīng)用的QoS和云基礎(chǔ)設(shè)施的開(kāi)銷(xiāo)，即量入為出。

當(dāng)前有兩種擴(kuò)縮容類型：水平，即服務(wù)的數(shù)目會(huì)視負(fù)載的情況增加或減少；垂直，即服務(wù)的資源(CPU或內(nèi)存)會(huì)視負(fù)載的情況增加或減少。但即使有了這兩種方法，也沒(méi)有明確定義的標(biāo)準(zhǔn)來(lái)決定使用哪種方法。此外，在性能和成本效益方面，還缺乏與垂直自動(dòng)擴(kuò)縮容相關(guān)的分析，以及如何與水平自動(dòng)擴(kuò)縮容進(jìn)行比較。

因此，為了評(píng)估這兩種方法的性能，我們使用kubernetes做了一個(gè)測(cè)量實(shí)驗(yàn)，并借助了一個(gè)壓測(cè)工具，該工具可以以一種受控的方式向一個(gè)"busy-wait"應(yīng)用發(fā)送請(qǐng)求，并根據(jù)負(fù)載發(fā)生變化后自動(dòng)擴(kuò)縮容決策的時(shí)間、每個(gè)決策上請(qǐng)求的 CPU 的容量以及應(yīng)用響應(yīng)時(shí)間的影響來(lái)對(duì)這些機(jī)制進(jìn)行評(píng)估。

Kubernetes的自動(dòng)擴(kuò)縮容策略

k8s是一個(gè)基于Borg的開(kāi)源項(xiàng)目，聚焦容器編排，并允許在集群中運(yùn)行容器應(yīng)用，同時(shí)簡(jiǎn)化了不同環(huán)境(生產(chǎn)、開(kāi)發(fā)等)的配置?？傊?，k8s提供了一組物理和虛擬機(jī)(節(jié)點(diǎn))，其中，master負(fù)責(zé)控制和給worker節(jié)點(diǎn)分配任務(wù)。在k8s中，pod是節(jié)點(diǎn)上最小的可分配單元，一個(gè)pod可以打包一個(gè)或多個(gè)容器，并定義執(zhí)行規(guī)則。需要注意的是，要確保節(jié)點(diǎn)能夠有足夠的資源去運(yùn)行對(duì)應(yīng)的pod。

為了在k8s中創(chuàng)建一個(gè)對(duì)象，需要?jiǎng)?chuàng)建一個(gè)包含所需規(guī)格的配置文件。K8s的對(duì)象可以用于不同的目的，如監(jiān)控、網(wǎng)絡(luò)配置、擴(kuò)縮容等。因此，需要根據(jù)不同的目的來(lái)選擇不同的類型。此處使用的類型是:

• horizontal pod autoscaler
• vertical pod autoscaler

Horizontal Pod Autoscaler

水平自動(dòng)擴(kuò)縮容的目的是降低或增加集群中的Pods數(shù)目，以便有效地利用資源并滿足應(yīng)用的需求。這種擴(kuò)縮容方式圍繞某些指標(biāo)，如CPU、內(nèi)存、自定義指標(biāo)或外部指標(biāo)(基于Kubernetes外部的應(yīng)用負(fù)載)。[2] [3]

為了使用水平擴(kuò)縮容，需要?jiǎng)?chuàng)建一個(gè)HorizontalPodAutoscaler配置文件，并定義一個(gè)CPU百分比使用限制，如果Pod的利用率達(dá)到該限制，則會(huì)創(chuàng)建出更多的副本。HPA每15s(可變)會(huì)校驗(yàn)是否需要?jiǎng)?chuàng)建新的Pods。

HPA 背后的算法基于 HPA 所watch的所有Pods的當(dāng)前利用率的平均值(U?)，期望利用率(U)，以及當(dāng)前副本數(shù)量(U?)，因此可以根據(jù)如下格式進(jìn)行計(jì)算：

Nd=Na?(Ua/Ud)Nd=Na?(Ua/Ud)

為了更好地理解上述格式，我們假設(shè)如下場(chǎng)景：

1. 一個(gè)集群中有5個(gè)副本(N? = 5)，平均利用率為限制100 milicores或0.1 CPU-core(U = 100)。
2. 在一個(gè)負(fù)載峰值之后，所有pods的平均利用率上升到200m(U = 200)。
3. 應(yīng)用公式，得到N = 5 * (200 / 100) = 10,其中N = 10，就是在保證平均利用率為100m且兼顧到閾值的理想Pods數(shù)。

通過(guò)以上例子，可以看到HPA會(huì)將副本數(shù)翻倍，而不是每次僅創(chuàng)建一個(gè)副本，這種方式使得HPA非常精準(zhǔn)。

HPA有一個(gè)默認(rèn)的延遲(5分鐘)，在負(fù)載降低時(shí)進(jìn)行縮容。該時(shí)間僅在利用率低于定義的利用率限制時(shí)才會(huì)開(kāi)始計(jì)算。

Vertical Pod Autoscaler

垂直擴(kuò)縮容的目的是增加或降低現(xiàn)有Pods分配的資源(CPU或內(nèi)存)。在Kubernetes中，它會(huì)修改Pod請(qǐng)求的資源容量。[4]

為了使用這種方式，需要?jiǎng)?chuàng)建一個(gè)VerticalPodAutoscaler類型的對(duì)象，并指定需要自動(dòng)擴(kuò)縮容的deployment。這種方式包含3個(gè)主要的組件：

• Updater：充當(dāng)哨兵，校驗(yàn)Pods是否有做夠的資源，否則會(huì)使用期望的資源來(lái)重啟這些Pods。
• Admission controller：和updater配合，定義合適的pod request資源容量。
• Recommender：watch資源，基于過(guò)去或當(dāng)前利用率，提供建議來(lái)擴(kuò)大或縮小內(nèi)存或CPU。

當(dāng)前VPA提供了3種類型的Recommender：

1. Target：推薦理想的內(nèi)存和CPU容量
2. Upper bound：推薦request資源的上限值，如果request大于此限值，考慮到置信因子，將會(huì)縮小Pod的規(guī)模
3. Lower bound：推薦request資源的下限值，如果request低于此限制，考慮到置信因子，將會(huì)擴(kuò)大Pod的規(guī)模

置信因子是一種使VPA 在自動(dòng)擴(kuò)縮容決策上更加保守的一種方法。這種方式會(huì)用到如下變量：當(dāng)前Pod request CPU(R?)，下限(B?)及其置信因子 (a?)，和上限 (B?)及其置信因子(a?)。

當(dāng)R? > (B? * a?)時(shí)，VPA會(huì)減少資源規(guī)模，其中置信因子a?會(huì)隨著 Pod 啟動(dòng)時(shí)間的增加而增加，并緩慢收斂到1。上限的置信因子的計(jì)算式為a? = (1 + 1/Δ?)，其中Δ?是Pod創(chuàng)建以來(lái)的天數(shù)。

另一方面，當(dāng)R? < (B? * a?)時(shí)VPA會(huì)增加資源規(guī)模，其中置信因子a?會(huì)隨著 Pod 啟動(dòng)時(shí)間的增加而增加，并緩慢收斂到1。下限的置信因子的計(jì)算式為a? = (1 + 0.001/Δ?)^-2。這樣，通過(guò)置信因子，VPA可以快速做出決策。

為了更好地理解，假設(shè)一個(gè)pod當(dāng)前的request CPU為R? = 100，當(dāng)前下限為B? = 150，啟動(dòng)以來(lái)的時(shí)間為5分鐘，將其轉(zhuǎn)換為天，得到Δ? = 5 /60/24 = 0.003472。下限的置信因子為a? = (1 + 0.001/0.00347)^-2 = 0.6，因此，可以看到100 < 150 * 0.6 ? 100 < 90，結(jié)論為false，此時(shí)不會(huì)增加Pod的容量。為了重新創(chuàng)建Pod，置信因子最少應(yīng)該為a? = 0.67，換句話說(shuō)，大約需要7分鐘才會(huì)重建。

驗(yàn)證環(huán)境

為了生成并分析實(shí)驗(yàn)結(jié)果，需要?jiǎng)?chuàng)建一個(gè)測(cè)試環(huán)境，并定義某種方式來(lái)生成資源利用率來(lái)觸發(fā)自動(dòng)擴(kuò)縮容策略，所有實(shí)驗(yàn)都實(shí)現(xiàn)了自動(dòng)化，并保存和組織實(shí)驗(yàn)數(shù)據(jù)。環(huán)境的架構(gòu)和組件如下圖所示：

• Eventos: 事件
• Aplica??o: 應(yīng)用
• Legenda: 副標(biāo)題
• Green: 分配負(fù)載
• Blue: 采集集群信息
• Red: 日志存儲(chǔ)

容器編排環(huán)境使用的是Minikube，生成負(fù)載采用的工具是Hey Benchmark Tool，它是使用Go編寫(xiě)的壓測(cè)工具，能夠并發(fā)大量請(qǐng)求，此外，它還包含所有所需的參數(shù)：

• 定義了請(qǐng)求執(zhí)行的時(shí)長(zhǎng)
• 定義了并行的workers數(shù)目
• 定義了worker發(fā)送的請(qǐng)求速率

為了在Minikube中生成負(fù)載，我們開(kāi)發(fā)了一個(gè)node.js web應(yīng)用，該應(yīng)用會(huì)暴露一個(gè)REST，其會(huì)調(diào)用一個(gè)busy-wait 函數(shù)，使服務(wù)在一定毫秒時(shí)間段內(nèi)的CPU-core的利用率達(dá)到100%，從下圖中可以看出，該函數(shù)接收一個(gè)服務(wù)時(shí)間，并在時(shí)間結(jié)束前讓CPU保持繁忙。

評(píng)估場(chǎng)景

考慮到垂直擴(kuò)縮容至少需要一個(gè)監(jiān)控的Pod，因此為了保持配置相似，需要為每個(gè)擴(kuò)縮容策略配置2個(gè)初始Pods。此外，每個(gè)Pod初始request的CPU為0.15 CPU-cores，限制為1.5CPU-cores。

在所有評(píng)估的場(chǎng)景中，服務(wù)時(shí)間(endpoint處理一個(gè)請(qǐng)求的時(shí)間)為常數(shù)S = 0.175 秒。負(fù)載強(qiáng)度受發(fā)送的請(qǐng)求速率(λ)以及并發(fā)的客戶端(每秒發(fā)送一個(gè)請(qǐng)求)控制。實(shí)驗(yàn)的每個(gè)場(chǎng)景分為9個(gè)階段，每個(gè)階段包含不同的負(fù)載，每個(gè)階段的執(zhí)行時(shí)間為2分鐘，每種場(chǎng)景的總執(zhí)行時(shí)間為18分鐘。

為了讓每個(gè)階段達(dá)到期望的CPU利用率，根據(jù)隊(duì)列理論的運(yùn)算規(guī)律定義了請(qǐng)求速率。根據(jù)利用率規(guī)律，流量強(qiáng)度定義為ρ = λ ? S。例如，達(dá)到2 cores利用率(ρ = 2)的服務(wù)時(shí)間為S = 0.1， 此時(shí)每秒請(qǐng)求速率為λ = ρ / S = 2 / 0.1 = 20。但如果該請(qǐng)求速率超過(guò)40，那么等式不再平衡，因?yàn)榇藭r(shí)的負(fù)載的確需要4個(gè)cores。[5]

實(shí)驗(yàn)的階段流程

如上圖所示，請(qǐng)求速率為λ = 2(需要ρ = 0.35 CPU-cores)；λ = 4 (需要 ρ = 0.7 CPU-cores); λ = 6 (需要 ρ = 1.05 CPU-cores); 和 λ = 8 (需要 ρ = 1.4 CPU-cores)，因此，這些情景假設(shè)綜合了以下幾點(diǎn):

1. 第一種場(chǎng)景中λ = [2, 2, 4, 6, 8, 6, 4, 2, 2]，以一種非激進(jìn)的方式逐步增加或減少負(fù)載
2. 第二種場(chǎng)景中λ = [2, 2, 8, 8, 8, 2, 2, 2, 2]，突然增加負(fù)載，并保持3個(gè)階段，然后在剩余的階段中降低降到最低值
3. 第三種場(chǎng)景中λ = [2, 2, 8, 8, 2, 2, 2, 2, 2]，與第二種類似，但高負(fù)載持續(xù)時(shí)間更少
4. 第四種場(chǎng)景中λ = [2, 2, 8, 2, 8, 2, 8, 2, 2]，使用多個(gè)峰值負(fù)載

當(dāng)定義好這些場(chǎng)景之后，就可以使用腳本自動(dòng)化執(zhí)行。

在實(shí)驗(yàn)執(zhí)行過(guò)程中，Kubernetes API會(huì)提供評(píng)估所需的關(guān)鍵數(shù)據(jù)：1)CPU使用情況；2)autoscaler推薦值；3)Pod Request的CPU數(shù)。每10秒對(duì)這些數(shù)據(jù)進(jìn)行一次檢索，并保存到日志文件中。因此，使用這些信息，可以判斷每個(gè)Pod request的CPU隨時(shí)間的變化情況。

同時(shí)，每次執(zhí)行腳本生成負(fù)載(使用Hey工具)時(shí)，也會(huì)將應(yīng)用的指標(biāo)保存到日志文件中，為測(cè)試提供應(yīng)用的行為數(shù)據(jù)。

結(jié)論

每種自動(dòng)擴(kuò)縮容策略下都會(huì)執(zhí)行者四種實(shí)驗(yàn)場(chǎng)景。每種方式的初始Pods數(shù)為2，每個(gè)Pod的CPU-core為0.15，并會(huì)隨時(shí)間被擴(kuò)縮容器所修改。圖1和圖2展示了實(shí)驗(yàn)過(guò)程中每個(gè)Pod的request CPU。虛線表示在負(fù)載的每個(gè)階段達(dá)到100% 利用率所需的 CPU 容量。

圖1：垂直擴(kuò)縮容中每個(gè)Pod request的CPU

可以看到，在VPA中，重新分配資源是有延遲的，大部分時(shí)間停留在 CPU 容量低于所需的情況下(虛線下面的彩色條)。場(chǎng)景1的負(fù)載是逐步增加的，其自動(dòng)擴(kuò)縮容決策的延遲相對(duì)要大，而場(chǎng)景2、3的負(fù)載變化比較突然，其延遲也相對(duì)較低。場(chǎng)景4的負(fù)載峰值較短，只有在階段8才出現(xiàn)了資源的申請(qǐng)，此外還可以看到，在進(jìn)行擴(kuò)容時(shí)，VPA request的CPU要大于所需的CPU，在縮容時(shí)，VPA也更加保守。

此外，即使在最后5個(gè)低強(qiáng)度的負(fù)載的階段中，VPA也沒(méi)有進(jìn)行縮容，此時(shí)申請(qǐng)的資源要大于所需的資源。這種延遲背后的原因是出于該機(jī)制的置信因子，它需要更多的時(shí)間來(lái)提升推薦的可信度。此外，在某些時(shí)候出現(xiàn)3個(gè)Pod的原因是，在調(diào)整Pod時(shí)，VPA會(huì)使用期望的資源容量來(lái)創(chuàng)建一個(gè)新的Pod，并在新的Pod就緒之后結(jié)束掉老的Pod。因此，置信因子可以多次減少重建 Pods 帶來(lái)的開(kāi)銷(xiāo)。

圖2：水平擴(kuò)縮容中每個(gè)Pod request的CPU

大部分情況下，HPA都能對(duì)工作負(fù)載的變化作出有效的反應(yīng)(盡管請(qǐng)求的 CPU 略高于所需的 CPU)。當(dāng)負(fù)載上升時(shí)，其平均擴(kuò)容決策時(shí)間為40秒。

只有在所有場(chǎng)景的第3階段，以及在場(chǎng)景1的第4和第5階段中，CPU停留在所需值以下的時(shí)間持續(xù)了大約1分鐘。

HPA能夠在5分鐘的延遲后進(jìn)行縮容，而VPA則不會(huì)縮容。在場(chǎng)景4中，HPA超量request 了CPU資源，這對(duì)于處理短時(shí)間的峰值來(lái)說(shuō)這是正向的，但長(zhǎng)遠(yuǎn)來(lái)看，有可能會(huì)給基礎(chǔ)設(shè)施成本帶來(lái)一定影響。

圖3：垂直和水平擴(kuò)縮容下的應(yīng)用響應(yīng)時(shí)間

圖3展示比較了每個(gè)場(chǎng)景下的負(fù)載階段對(duì) Web 應(yīng)用程序所做請(qǐng)求的響應(yīng)時(shí)間。每個(gè)框的中間線代表中間值，而點(diǎn)和三角形是每個(gè)階段響應(yīng)時(shí)間的平均值。

在所有場(chǎng)景下下，水平自動(dòng)擴(kuò)縮容展示的響應(yīng)時(shí)間非常接近于服務(wù)時(shí)間(0.175秒)，在負(fù)載量增加的幾個(gè)階段中，只有平均值和第三四分位數(shù)略大。另一方面，在各種階段中，由于調(diào)整Pod存在延遲，垂直自動(dòng)擴(kuò)縮容展示的響應(yīng)時(shí)間要遠(yuǎn)大于服務(wù)時(shí)間(無(wú)論平均值和四分位數(shù))。

可以這么說(shuō)，在使用默認(rèn)配置對(duì)這兩種自動(dòng)擴(kuò)縮容策略進(jìn)行評(píng)估的過(guò)程中表明，HPA是更有效的，它可以更快響應(yīng)負(fù)載的變化，并且有足夠數(shù)量的 Pods 來(lái)處理請(qǐng)求，而 VPA 受到了調(diào)整 Pods延遲的負(fù)面影響。

總結(jié)

本次工作通過(guò)測(cè)量實(shí)驗(yàn)分析了Kubernetes中水平和垂直自動(dòng)擴(kuò)縮容的性能。為此，需要某種方式來(lái)生成負(fù)載并使用壓測(cè)工具控制負(fù)載，以及創(chuàng)建多個(gè)場(chǎng)景來(lái)分析自動(dòng)擴(kuò)縮容方式的行為，主要關(guān)注響應(yīng)時(shí)間、Pods的CPU request指標(biāo)，以及自動(dòng)擴(kuò)容時(shí)間時(shí)間的時(shí)間。

從本次的實(shí)驗(yàn)中可以看到，水平自動(dòng)擴(kuò)縮容相對(duì)不保守，但對(duì)資源的調(diào)整也相對(duì)更高效。需要注意的是，這種精度是由水平pod自動(dòng)擴(kuò)縮容器算法的客觀性決定的，該算法將請(qǐng)求的資源保持在已定義的資源使用限制的平均值內(nèi)。

相比之下，垂直自動(dòng)擴(kuò)縮容在資源申請(qǐng)決策上則更加保守，因?yàn)樗蕾囉陔S時(shí)間增加置信因子的對(duì)數(shù)。可以得出，在較長(zhǎng)時(shí)間的實(shí)驗(yàn)中，可以生成更多的pod執(zhí)行的歷史數(shù)據(jù)，垂直自動(dòng)擴(kuò)縮容將更有效地執(zhí)行自動(dòng)擴(kuò)縮容決策。

在本次的實(shí)驗(yàn)參數(shù)和場(chǎng)景下，水平自動(dòng)擴(kuò)縮容展現(xiàn)了更高的效率，其決策的精確性提供了資源的靈活性，以及更快的 Web 應(yīng)用響應(yīng)時(shí)間。需要注意的是，在本次時(shí)間結(jié)束之時(shí)，垂直自動(dòng)擴(kuò)縮容還處理beta階段，仍然會(huì)接受日常更新，因此未來(lái)有可能會(huì)在效率上有所提升。此外，本次實(shí)驗(yàn)使用了Kubernetes的默認(rèn)配置，因此修改參數(shù)可能會(huì)產(chǎn)生不同的結(jié)果。