陳 雁,黃嘉鑫

(西南石油大學(xué) 計(jì)算機(jī)科學(xué)學(xué)院,成都 610500)

隨著計(jì)算機(jī)技術(shù)的更新迭代,傳統(tǒng)的應(yīng)用正在變得越來越復(fù)雜,需要支持更多的用戶、更強(qiáng)的計(jì)算能力,而且還需要更加穩(wěn)定和安全,為了支撐這些不斷增長的需求,一種新型的計(jì)算模式“云計(jì)算”應(yīng)運(yùn)而生.云計(jì)算是一種新的基于互聯(lián)網(wǎng)的計(jì)算方式和資源應(yīng)用平臺(tái),從計(jì)算方式上來說,“云計(jì)算”是通過網(wǎng)絡(luò)將龐大復(fù)雜的數(shù)據(jù)交由多臺(tái)服務(wù)器組成的集群系統(tǒng)進(jìn)行存儲(chǔ)、計(jì)算、分析后,將處理結(jié)果回傳給用戶的一種計(jì)算模式[1].

虛擬化是云計(jì)算的基石,傳統(tǒng)虛擬化技術(shù)是在硬件資源級別的虛擬化,需要有虛擬機(jī)管理程序和虛擬機(jī)操作系統(tǒng).隨著Docker[2]的出現(xiàn),容器技術(shù)正在成為打包和部署應(yīng)用程序的新趨勢,Docker是直接建立在操作系統(tǒng)上的虛擬化,它直接復(fù)用本地操作系統(tǒng),更加輕量級.使用Docker比使用虛擬機(jī)(VM)部署應(yīng)用啟動(dòng)更快,系統(tǒng)的開銷更小,能夠更有效地支持應(yīng)用程序的快速迭代[3].目前,Docker容器已在云基礎(chǔ)架構(gòu)中得到廣泛部署,例如Amazon Ec2 Container Service,Google Container Engine,Rackspace,Docker Data Center[4].

Docker 是一個(gè)相對底層的容器引擎,在大規(guī)模的服務(wù)器集群中,需要一個(gè)集中的控制器來進(jìn)行任務(wù)的編排,調(diào)度和控制.而Kubernetes[5]提供了大規(guī)模運(yùn)行容器的編排系統(tǒng)和管理平臺(tái),它實(shí)現(xiàn)了包括應(yīng)用部署、高可用管理和彈性伸縮在內(nèi)的一系列基礎(chǔ)功能,并封裝成為一整套完整、簡單易用的RESTful API對外提供服務(wù).

Kubernetes的彈性擴(kuò)展功能是由Horizontal Pod Autoscaler (HPA)[6]控制器來實(shí)現(xiàn)的,HPA會(huì)根據(jù)自定義指標(biāo)控制副本集中的容器數(shù)量,這種自動(dòng)擴(kuò)展伸縮機(jī)制使用固定閾值的規(guī)則,并且Kubernetes的擴(kuò)展和收縮Pod數(shù)量是根據(jù)同一套算法,同一個(gè)檢測指標(biāo)來判定是否需要擴(kuò)容或者收縮.

由于Kubernetes的擴(kuò)容和收縮決策判斷基于同一個(gè)指標(biāo),這就會(huì)產(chǎn)生頻繁擴(kuò)容縮容的問題;在應(yīng)對大規(guī)模突發(fā)流量時(shí),Kubernetes的擴(kuò)容幅度不足以應(yīng)對大規(guī)模流量,就會(huì)造成訪問中斷;在訪問流量驟降的時(shí)候,Kubernetes內(nèi)置算法則會(huì)迅速收縮Pod 的數(shù)量,收縮速度太快,當(dāng)出現(xiàn)第二次突發(fā)流量,收縮后的Pod還來不及擴(kuò)展,就會(huì)導(dǎo)致應(yīng)用負(fù)載過大,造成應(yīng)用崩潰.

針對Kubernetes彈性擴(kuò)展的調(diào)度策略,Casalicchio等[7]對CPU密集型的工作負(fù)載,提出KHPA-A算法,該算法采用絕對度量指標(biāo)來做擴(kuò)展決策,使用絕對指標(biāo)來觸發(fā)容器彈性伸縮和確定Pod的數(shù)量,將度量指標(biāo)保持在設(shè)定閾值以下.Al-Dhuraibi等[8]在Docker層面提出ELASTICDOCKER算法,該算法是垂直彈性擴(kuò)展容器的CPU和內(nèi)存大小,當(dāng)應(yīng)用程序工作負(fù)載上升/下降時(shí),ELASTICDOCKER將分配給每個(gè)容器的CPU和內(nèi)存向上/下彈性伸縮.垂直彈性僅受限于主機(jī)容量,當(dāng)所有主機(jī)資源都已分配給容器時(shí),容器將會(huì)執(zhí)行從源主機(jī)到目標(biāo)主機(jī)的動(dòng)態(tài)遷移.

以上研究是針對于特殊場景的CPU密集型計(jì)算和縱向擴(kuò)展增加容器的CPU和內(nèi)存,而如何在通用常規(guī)情況下,使用方便簡單的方法保證系統(tǒng)平穩(wěn)、穩(wěn)定運(yùn)行則是更需要解決的問題.因此,本文提出步長容忍度算法水平伸縮的控制器,它能在當(dāng)應(yīng)用服務(wù)器中業(yè)務(wù)負(fù)載上升的時(shí)候,迅速創(chuàng)建多個(gè)新的Pod來保證業(yè)務(wù)系統(tǒng)穩(wěn)定運(yùn)行,當(dāng)Pod中業(yè)務(wù)負(fù)載下降的時(shí)候,在保證系統(tǒng)穩(wěn)定運(yùn)行的前提下逐步銷毀Pod來提高資源利用率.對于應(yīng)用,需要保障能夠穩(wěn)定平滑的運(yùn)行,而不只是盡可能的節(jié)約成本.步長容忍度算法在擴(kuò)展的時(shí)候,保證應(yīng)用服務(wù)器能夠承擔(dān)不斷增長的連接數(shù),做到快速擴(kuò)展,甚至過度擴(kuò)展.在收縮的時(shí)候采取較為寬松的收縮策略,達(dá)到逐漸收縮的目的.

1 Kubernetes內(nèi)置算法

HPA是Kubernetes里面Pod彈性伸縮的實(shí)現(xiàn),它在Kubernetes中被設(shè)計(jì)為一個(gè)controller,能根據(jù)設(shè)置的監(jiān)控閥值進(jìn)行Pod的彈性擴(kuò)縮容[9].HPA Controller默認(rèn)30 s輪詢一次,查詢指定的resource中Deployment/RS的資源使用率[10],并且與創(chuàng)建時(shí)設(shè)定的值和指標(biāo)做對比,從而實(shí)現(xiàn)自動(dòng)伸縮的功能.HPA控制器工作原理如圖1所示.

圖1 HPA控制器原理圖

HPA使用式(1)中的方法計(jì)算

其中,dP(desired Replicas)為期待的副本數(shù)量,即算法計(jì)算后得到的副本數(shù)量;cR(current Replicas)為當(dāng)前的副本數(shù)量,探測器檢測到的副本的數(shù)量;cM(current Metric value)為當(dāng)前設(shè)置的檢測指標(biāo)的值,比如CPU利用率,內(nèi)存使用情況;dM(desired Metric value)為期望的Pod 的檢測指標(biāo)的值;ceil為表示取大于或等于某數(shù)的最近一個(gè)整數(shù).

HPA中Pod水平彈性伸縮的實(shí)現(xiàn)是通過定期輪循查詢Pod的狀態(tài)(默認(rèn)輪詢時(shí)間為30 s)通過式(1)計(jì)算.在每個(gè)周期時(shí)間,控制器管理器根據(jù)每個(gè)HPA定義中指定的度量標(biāo)準(zhǔn)查詢資源利用率.控制管理器從資源指標(biāo)的API中獲取度量,獲取到Pod的監(jiān)控?cái)?shù)據(jù),然后通過現(xiàn)有Pod使用率的平均值跟目標(biāo)使用率進(jìn)行比較,計(jì)算出需要伸縮的具體值并進(jìn)行操作.在每次擴(kuò)容和收縮都有一個(gè)窗口時(shí)間,在執(zhí)行伸縮操作后,在這個(gè)窗口時(shí)間內(nèi),不會(huì)再進(jìn)行伸縮操作,默認(rèn)擴(kuò)容為3 min,收縮為5 min.

例如當(dāng)前的副本數(shù)量為1個(gè),設(shè)置當(dāng)前度量標(biāo)準(zhǔn)值cM是內(nèi)存,檢測到當(dāng)前Pod 的內(nèi)存為150 MB,而初始設(shè)定的期望為100 MB,則副本的數(shù)量將變?yōu)?個(gè),因?yàn)?1×(150/100)= 1.5 向上取整為 2,所以Pod數(shù)量會(huì)彈性擴(kuò)展到 2個(gè).

參考 Kubernates源代碼發(fā)現(xiàn),原生彈性伸縮的實(shí)現(xiàn)非常簡單:(1)計(jì)算所有Pod的度量指標(biāo)使用率;(2)根據(jù)彈性伸縮算法計(jì)算Pod的需求量;(3)按照計(jì)算出的Pod數(shù)量進(jìn)行擴(kuò)容和伸縮.這一自動(dòng)縮放算法靈活性差,擴(kuò)容和收縮都是用同一個(gè)算法,對突發(fā)流量會(huì)造成頻繁擴(kuò)容問題,突發(fā)流量過后會(huì)造成頻繁收縮的問題;容器啟動(dòng)是需要一定的時(shí)間的,在應(yīng)對大規(guī)模突發(fā)流量時(shí),擴(kuò)容還來不及擴(kuò)展Pod,就可能會(huì)造成當(dāng)前應(yīng)用承受不了負(fù)載而崩潰,應(yīng)當(dāng)為新擴(kuò)容的容器實(shí)例預(yù)留啟動(dòng)時(shí)間,給正在運(yùn)行的Pod充足的資源應(yīng)對負(fù)載;逐漸收縮,在保證訪問量承載的前提下,逐步遞減收縮Pod,防止收縮太快低于系統(tǒng)的承載能力,造成系統(tǒng)的不穩(wěn)定,針對這些問題本文提出了步長容忍度算法.

2 步長容忍度算法

設(shè)計(jì)步長容忍度算法的時(shí)候,考慮到自動(dòng)擴(kuò)展的決策需要一段時(shí)間才會(huì)生效,若當(dāng)前Pod的CPU負(fù)荷過大,在創(chuàng)建一個(gè)新Pod的過程中,應(yīng)用系統(tǒng)的CPU使用量可能會(huì)同樣有一個(gè)攀升的過程.所以在循環(huán)探測中,在每一次作出決策后的一段時(shí)間內(nèi),將不再進(jìn)行擴(kuò)展/收縮決策.對于擴(kuò)容而言,這個(gè)時(shí)間段為3分鐘,縮容為5分鐘.因?yàn)樾枰M可能滿足Pod業(yè)務(wù)的正常使用,所以擴(kuò)容的優(yōu)先級要大于縮容.步長容忍度算法會(huì)通過調(diào)整副本數(shù)量使得檢測指標(biāo)使用率盡可能向期望值靠近,而且不是完全相等.步長容忍度算法在HPA Controller中引入一個(gè)tolerance (容忍度)的概念,它允許在一定范圍內(nèi)使用量的不穩(wěn)定,設(shè)置容忍度為15%,這也是出于維護(hù)系統(tǒng)穩(wěn)定性的考慮.例如,設(shè)定HPA調(diào)度策略為CPU使用率高于60%觸發(fā)擴(kuò)容,那么只有當(dāng)使用率大于75%或者小于45%才會(huì)觸發(fā)伸縮活動(dòng),HPA會(huì)盡力把Pod的使用率控制在這個(gè)范圍之間.自動(dòng)伸縮的監(jiān)測指標(biāo)包括CPU平均使用量、內(nèi)存平均使用量、用戶自定義一些監(jiān)控指標(biāo).

步長容忍度算法包含兩個(gè)部分:快速擴(kuò)展算法和逐步收縮算法.

2.1 快速擴(kuò)展算法

步長容忍度算法的快速擴(kuò)展將Pods的目標(biāo)期望利用率Tmetric(作為MetricValue指標(biāo)的百分比)、前一個(gè)輪詢控制周期(Ts)中運(yùn)行的Pods的ActPod集合、實(shí)例化的初始Pod擴(kuò)容數(shù)量、設(shè)定的擴(kuò)展步長UpSetup等作為輸入,輸出是則要部署的Pods的目標(biāo)數(shù)量P.

系統(tǒng)啟動(dòng)之后,每隔Ts(如30 s)循環(huán)檢查一次所有HPA,檢測結(jié)果若有一個(gè)Pod指標(biāo)超過初始設(shè)置的期望值加上容忍度的值,就以步長(如2)執(zhí)行擴(kuò)展.每次擴(kuò)展完成后,記錄擴(kuò)展時(shí)間間隔,保證擴(kuò)展操作間隔不小于3 min以確保系統(tǒng)的穩(wěn)定性.Pod的數(shù)量按照式(1)進(jìn)行計(jì)算,而利用率/期望的比例大于1.15(容忍度為15%),才能進(jìn)行擴(kuò)容,防止抖動(dòng).

系統(tǒng)每Ts(實(shí)驗(yàn)設(shè)置為30 s),算法收集Pod的MetricValue利用率,用cAdvisor(容器監(jiān)控工具)測量并將其存儲(chǔ)在向量U中.最后,計(jì)算出DisredPods的目標(biāo)數(shù)量P,P由式(2)計(jì)算得出.

算法1為步長容忍度算法中的快速擴(kuò)展算法.

算法1.步長容忍度算法的快速擴(kuò)展算法Inputs:TMetric:期望的檢測指標(biāo)的平均使用率;AvgMetric:檢測指標(biāo)的平均使用率;ActPod:正在運(yùn)行的Pod的數(shù)量;DisredPods:期望Pod的數(shù)量;Tolerance:期望的容忍度;UpSetup:擴(kuò)容的步長;T:定期輪詢時(shí)間.run Application(s)init ActPod = 1 while true do if [AvgMetric ＞ (Tmetric + Tolerance)] {if (ActPod = = 1){DesiredPod = ActPod + UpSetup ActPod = DesiredPod}}else{DesiredPod=Ceil[ActPod*(AvgMetric/Tmetric)+UpSetup]ActPod = DesiredPod}wait(T)end while

假設(shè)Tmetric= 60%.正在運(yùn)行3個(gè)應(yīng)用程序副本,每個(gè)Pod的CPU利用率分別為73%,75%和82%.在下一個(gè)控制周期,步長容忍度算法確定應(yīng)該部署新的PodP= 6.這樣快速擴(kuò)展以應(yīng)對大規(guī)模的數(shù)據(jù)流量,防止應(yīng)用崩潰.負(fù)載將在Pod之間分配,預(yù)計(jì)的每Pod調(diào)整利用率由式(3)計(jì)算出:

在下一次擴(kuò)容的時(shí)間間隔3 min內(nèi),以便有足夠的資源來負(fù)載訪問流量,達(dá)到快速擴(kuò)容的目的.

2.2 逐步收縮算法

步長容忍度算法節(jié)點(diǎn)收縮采取的策略是當(dāng)監(jiān)測指標(biāo)值低于所設(shè)定的縮容條件,以默認(rèn)步長2減少節(jié)點(diǎn)數(shù)量.當(dāng)監(jiān)測節(jié)點(diǎn)數(shù)量為2,停止減少容器數(shù)量.

約束規(guī)則為縮容條件的可選范圍是(0%～45%).縮容的時(shí)候當(dāng)節(jié)點(diǎn)數(shù)＜= 集群最小節(jié)點(diǎn)數(shù)(設(shè)置為2)的時(shí)候,不會(huì)進(jìn)行縮容操作.

算法2為步長容忍度算法中的逐步收縮的算法.

假設(shè)Tmetric= 60%.正在運(yùn)行6個(gè)應(yīng)用程序副本,每個(gè)Pod的CPU利用率分別為50%,45%,47%,52%,43%和40%.在下一個(gè)控制周期,步長容忍度算法確定收縮節(jié)點(diǎn)的數(shù)量P=4.這樣以步長為2逐步收縮.負(fù)載將在Pod之間分配,預(yù)計(jì)的每Pod調(diào)整利用率由式(4)計(jì)算出變?yōu)?

算法2.步長容忍度算法的逐步收縮算法Inputs:TMetric:期望的檢測指標(biāo)的平均使用率AvgMetric:檢測指標(biāo)的平均使用率ActPod:正在運(yùn)行的Pod的數(shù)量DisredPods:期望Pod的數(shù)量Tolerance:期望的容忍度DownSetup:收縮的步長T:定期輪詢時(shí)間run Application(s)init ActPod = 1 while true do if [AvgMetric ＜ (Tmetric-Tolerance)] {if (ActPod = = 2){ActPod = 2}}else{DesiredPod = ActPod -DownSetup]ActPod = DesiredPod}wait(T)end while

在下一次收縮的時(shí)間間隔5 min內(nèi),保持系統(tǒng)的穩(wěn)定性,達(dá)到逐步收縮的目的.

3 實(shí)驗(yàn)結(jié)果與分析

3.1 實(shí)驗(yàn)環(huán)境

在實(shí)驗(yàn)中,為了驗(yàn)證步長容忍度算法,實(shí)驗(yàn)環(huán)境采用2套相同的Kubernetes實(shí)驗(yàn)環(huán)境做對比測試,一套Kubernetes實(shí)驗(yàn)環(huán)境使用原生的彈性伸縮算法,對比實(shí)驗(yàn)采用步長容忍度算法.Kubernetes實(shí)驗(yàn)環(huán)境都是1個(gè)master節(jié)點(diǎn)和2個(gè)node節(jié)點(diǎn),Kubernetes版本1.11.3,docker版本為17.03.3-ce.在實(shí)驗(yàn)中使用的環(huán)境配置如表1所示.

表1 實(shí)驗(yàn)環(huán)境配置

設(shè)定了一個(gè)在進(jìn)行壓力測試的情況下檢驗(yàn)Pod個(gè)數(shù)的變換以及每個(gè)Pod的CPU負(fù)載的變換情況.

3.2 實(shí)驗(yàn)步驟

實(shí)驗(yàn)包含兩個(gè)部分:(1)使用ApacheBench進(jìn)行壓力測試,在壓力測試的時(shí)候檢驗(yàn)pod的變化情況,在壓力測試完成后,觀察Pod隨即的數(shù)量變化狀況,驗(yàn)證在應(yīng)對突發(fā)流量時(shí)擴(kuò)容/收縮情況.(2)使用不同的并發(fā)請求數(shù),請求5 000 000個(gè)連接,在高壓高并發(fā)的情況下檢測服務(wù)的吞吐率、用戶平均請求等待時(shí)間、服務(wù)器平均處理時(shí)間,驗(yàn)證步長容忍度算法是否提高系統(tǒng)的穩(wěn)定性.每個(gè)實(shí)驗(yàn)重復(fù)進(jìn)行5次迭代,取實(shí)驗(yàn)結(jié)果的平均值.

實(shí)驗(yàn)設(shè)定:創(chuàng)建部署2個(gè)一主兩從的 Kubernetes集群.建一個(gè)包含nginx-stress容器的deployment,對這個(gè)deployment持續(xù)進(jìn)行并發(fā)請求,模擬用戶在客戶端頻繁地訪問web應(yīng)用,應(yīng)用會(huì)將訪問流量轉(zhuǎn)發(fā)到后端一個(gè)Pod上,繼而增加這個(gè)Pod的壓力,Kubernetes系統(tǒng)檢測到Pod內(nèi)存和CPU在不斷升高,到達(dá)擴(kuò)容的臨界值就會(huì)擴(kuò)展Pod,來應(yīng)對這些流量.

實(shí)驗(yàn)表明,啟動(dòng)一個(gè)Pod容器實(shí)例所需的時(shí)間大約是6 s.在實(shí)驗(yàn)中,Kubernetes資源探測的時(shí)間間隔定義為30 s,雖然也可以將監(jiān)視間隔指定為更短的時(shí)間,但是將其設(shè)置為30 s可以減少通信流量負(fù)載和測量的監(jiān)視開銷.在實(shí)驗(yàn)中,本文把閾值被設(shè)置為65%,這樣步長容忍度算法將有足夠的時(shí)間對工作負(fù)載中的運(yùn)行時(shí)變化作出反應(yīng),而不是閾值非常接近100%才進(jìn)行反應(yīng),從而防止壓力過大應(yīng)用崩潰的問題.擴(kuò)容間隔時(shí)間設(shè)置為3 min,可以防止運(yùn)行容器實(shí)例數(shù)量的過于頻繁的變化.收縮時(shí)間間隔為5 min,避免收縮過快引發(fā)系統(tǒng)不穩(wěn)定性.

對應(yīng)用進(jìn)行持續(xù)不斷的請求,進(jìn)行壓力測試,圖2顯示了在工作負(fù)載急劇上升的場景下內(nèi)置算法和步長容忍度算法的Pod的數(shù)量變換情況.

由圖2可見,在應(yīng)用收到大規(guī)模流量請求時(shí),內(nèi)置算法擴(kuò)容的比例比步長容忍度算法小的多,從應(yīng)用的負(fù)載情況來看,步長容忍度算法能夠很好的支持大規(guī)模訪問.步長容忍度算法幾乎沒有失敗請求數(shù),而內(nèi)置算法出現(xiàn)了不少的失敗請求數(shù)(見表2),由于工作量增加導(dǎo)致系統(tǒng)過載,內(nèi)置算法的應(yīng)用提供了一段時(shí)間的慢響應(yīng)時(shí)間.步長容忍度算法這種快速擴(kuò)展能夠很好支撐大規(guī)模流量訪問.

圖2 Pod增長變化圖

表2 內(nèi)置算法并發(fā)請求測試

當(dāng)工作負(fù)載密度下降到1個(gè)請求,Pod的數(shù)量會(huì)根據(jù)執(zhí)行時(shí)到達(dá)的請求的數(shù)量而減少.圖3顯示了在工作負(fù)載下降的場景的Pod的數(shù)量變化情況.

圖3 Pod收縮變化圖

步長容忍度算法和內(nèi)置算法的自動(dòng)彈性伸縮方法都不會(huì)立即停止在集群中運(yùn)行的容器實(shí)例,Pod數(shù)量是呈現(xiàn)逐漸減少的狀態(tài).與內(nèi)置算法的自動(dòng)縮放方法相比,步長容忍度算法分配的Pod數(shù)量明顯多于內(nèi)置算法,是遞減收縮.在工作負(fù)載突然增加時(shí),步長容忍度算法在開始及啟動(dòng)時(shí)有足夠的Pod實(shí)例,比內(nèi)置算法自動(dòng)擴(kuò)展方法更快.因此,對于急劇變化的工作負(fù)載模式,步長容忍度算法有更好的負(fù)載能力和維持系統(tǒng)的穩(wěn)定性能.

本文也對在彈性擴(kuò)展中Pod 的性能做了測試,在進(jìn)行5 000 000個(gè)連接數(shù)情況下對應(yīng)用的失敗請求數(shù)、吞吐率、用戶平均請求等待時(shí)間和服務(wù)器平均處理時(shí)間進(jìn)行了測試,表2為內(nèi)置算法的并發(fā)請求性能測試,表3為步長容忍度算法的并發(fā)請求性能測試.

表3 步長容忍度算法并發(fā)請求測試

對比內(nèi)置算法和步長容忍度算法并發(fā)請求測試的結(jié)果,在并發(fā)請求數(shù)比較少的情況,內(nèi)置算法和步長容忍度算法表現(xiàn)都差不多,在失敗請求數(shù)這個(gè)指標(biāo),內(nèi)置算法由于持續(xù)壓力測試當(dāng)前啟動(dòng)的Pod不能負(fù)載流量,啟動(dòng)新的Pod需要一定的啟動(dòng)時(shí)間,造成應(yīng)用的不穩(wěn)定,產(chǎn)生較多的失敗請求.在并發(fā)請求數(shù)比較大的時(shí)候,步長容忍度算法的優(yōu)勢就體現(xiàn)出來了,應(yīng)用能在更短的時(shí)間內(nèi)處理請求,響應(yīng)客戶端的速度也更快,服務(wù)器的吞吐率也更大.

實(shí)驗(yàn)表明,在并發(fā)請求數(shù)較大的情況下,步長容忍度算法的Kubernetes集群處理能力比內(nèi)置算法的集群應(yīng)對突發(fā)流量的能力更強(qiáng),內(nèi)置算法的集群對突發(fā)流量會(huì)出現(xiàn)承載過大,出現(xiàn)較多失敗請求,對比使用不同并發(fā)請求數(shù)的請求測試,步長容忍度算法的失敗請求數(shù)比內(nèi)置算法的失敗請求數(shù)下降了 97.83%,整個(gè)彈性伸縮系統(tǒng)更加穩(wěn)定健壯.步長容忍度算法集群的吞吐率比內(nèi)置算法集群的吞吐率更大,處理請求的速度越快,使用步長容忍度算法的服務(wù)器的響應(yīng)速度(依據(jù)用戶請求等待時(shí)間)比內(nèi)置算法算法的響應(yīng)速度更快,提高了4.54%.步長容忍度算法在其他方面的結(jié)果比內(nèi)置算法結(jié)果好.此實(shí)驗(yàn)通過用壓力測試模擬用戶請求觸發(fā)閾值進(jìn)而進(jìn)行擴(kuò)容驗(yàn)證了本文提出的步長容忍度算法的有效性,是在應(yīng)對大規(guī)模流量橫向擴(kuò)展的有效手段.

4 結(jié)論與展望

Kubernetes內(nèi)置的 Horizontal Pod彈性縮放算法擴(kuò)容和收縮采用相同的伸縮機(jī)制,會(huì)造成頻繁的擴(kuò)容和收縮問題.本文提出了一種新的自動(dòng)縮放算法,該算法能夠?qū)崿F(xiàn)快速擴(kuò)容和逐步收縮以達(dá)到系統(tǒng)穩(wěn)定運(yùn)行的狀態(tài),對于服務(wù)的穩(wěn)定性是一個(gè)很好的提升.本文提出的方案在并發(fā)請求數(shù)較大的情況下,步長容忍度算法比內(nèi)置彈性伸縮算法應(yīng)對突發(fā)流量的能力更強(qiáng).由于目前彈性伸縮策略是根據(jù)實(shí)時(shí)的使用率來進(jìn)行擴(kuò)容,但其實(shí)對于很多應(yīng)用來說,很多業(yè)務(wù)高峰期是有規(guī)律的,因此如果未來能做到提前預(yù)測出高峰期,做適應(yīng)的擴(kuò)容,那將會(huì)極大地提高資源使用率.