單朋榮，楊美紅，趙志剛，李志鵬，楊麗娜

（1.齊魯工業(yè)大學（山東省科學院）山東省計算中心（國家超級計算濟南中心）山東省計算機網(wǎng)絡重點實驗室，濟南 250000；2.同濟大學 電子信息工程學院，上海 201804）

0 概述

近年來，容器（Docker）［1］技術(shù)的飛速發(fā)展帶來了云平臺技術(shù)的新一輪變革，它使得打包應用可以無縫遷移到具備容器基礎(chǔ)運行環(huán)境的平臺上，其本質(zhì)是建立在Linux 的Cgroup、Namespace 等技術(shù)上的虛擬化技術(shù)，而容器（鏡像）打包的本質(zhì)是打包本地的文件系統(tǒng)，文件系統(tǒng)代表本地的應用環(huán)境，從而實現(xiàn)將應用及其依賴環(huán)境一起打包。同時，容器技術(shù)解耦了Linux 底層實現(xiàn)機制，由此賦予了容器輕量、靈活等特性，但容器技術(shù)歸根到底只是一種虛擬化技術(shù)，雖然能將應用抽象成云端的一個可遷移單位，但云平臺上所承載的應用數(shù)以億萬計，由此需要通過工具來編排容器，使容器技術(shù)上升到PaaS 層，從而帶來真正的商業(yè)價值。

Kubernetes［2］作為業(yè)內(nèi)領(lǐng)先的基于容器技術(shù)的分布式系統(tǒng)支撐平臺，提供了完備的集群管理能力及工具，具備開放式的可擴展機制和先進的大規(guī)模集群編排理念。Kubernestes 項目是隨著Docker 公司發(fā)布容器技術(shù)后逐漸興起的，目前已成為容器編排領(lǐng)域的事實標準［3］。容器編排面向的是PaaS 層，為領(lǐng)先該領(lǐng)域，以Docker Swarm、Mesos和Kubernetes為代表的技術(shù)進行進行了改進［4］。Kubernetes 技術(shù)憑借“先進的設(shè)計理念”和開源生態(tài)所落地的“用戶二次創(chuàng)新”［5］能力，最終確立了其在容器編排領(lǐng)域的主導地位，也使得以容器為代表的應用形態(tài)技術(shù)成為了引領(lǐng)“下一代數(shù)據(jù)中心”［8］的關(guān)鍵技術(shù)之一。OpenStack［6］雖然也通過各種方式增加對容器的支持，但它仍然是以資源為中心，且管理的核心目標是機器，目前不被視為管理容器的主流平臺。Mesos作為業(yè)內(nèi)主流的通用計算資源管理平臺，為編排容器推出了Mesophere 項目［7］，但Mesos 社區(qū)與容器技術(shù)的關(guān)系更多地是“借勢”，加上它所屬Apache 社區(qū)固有的封閉性，在容器編排領(lǐng)域缺乏創(chuàng)新性而逐漸失去競爭力。

Kubernetes 已成為業(yè)內(nèi)主流的容器編排方案，Kubernetes 集群中抽象出各類資源對象應用程序編程接口（Application Programming Interface，API），用于資源對象的統(tǒng)一管理和維護。Kubernetes 集群編排的基本可運行的單位為Pod［2］，它是應用資源的抽象和對容器的進一步封裝，也是Kubernetes 平臺中彈性伸縮和調(diào)度的基本單位，Pod 與容器一樣具備輕量和易移植性等特性。因此，Kubernetes 編排系統(tǒng)可根據(jù)編排對象模板在短時間內(nèi)生成極為龐大的可再生Pod 副本集。正是因為Kubernetes 技術(shù)的獨特性，它賦予了云原生［2］時代下彈性伸縮細粒度、多維度、可擴展、高效率、低成本和高可用等新的特點。因為Pod 非常輕量和靈活，所以彈性伸縮在伸縮效率和成本上相較于虛擬機都有明顯優(yōu)勢［8］。

作為Kubernetes 核心的發(fā)布功能之一，彈性伸縮技術(shù)及其方案的設(shè)計與實現(xiàn)已成為衡量“容器云”平臺服務能力的重要參考標準。彈性伸縮技術(shù)中最具代表性的技術(shù)分別是垂直彈性伸縮技術(shù)和水平彈性伸縮技術(shù)。文獻［9］提出一種使用cAdvisor 和Heapster［10］采集匯集數(shù)據(jù)的彈性伸縮技術(shù)，但Heapster 的強耦合性使得它的擴展性較差，難以解決實際應用中度量指標的多樣化問題。在社區(qū)Kubernetes1.11 版本后，Kubernetes使用Metric Server（指標服務器）來替代Heapster，雖然Metric Server 對CPU 和內(nèi)存等資源支持良好，但不支持用戶自定義指標。Kubernetes1.11 版本后提供的“指標聚合”［11］功能，為自定義指標的引入提供了基礎(chǔ)。文獻［12］提出基于HPA 的疊加E-HPA 彈性擴縮容系統(tǒng)只給出了水平彈性伸縮方法，對異構(gòu)環(huán)境下的多維度彈性伸縮需求支撐不足。

本文提出Kubernetes 云平臺自定義指標［13］和不同維度相結(jié)合的彈性伸縮方案。該方案通過集成Prometheus［14］監(jiān)控系統(tǒng)來自定義和采集業(yè)務指標，并結(jié)合HPA 組件實現(xiàn)自定義指標的彈性伸縮方案，以滿足不同業(yè)務場景根據(jù)業(yè)務指標完成伸縮的需求，通過搭配使用HPA、CPA 和VPA［15］等組件，實現(xiàn)水平、垂直和根據(jù)集群規(guī)模伸縮資源的策略，以在異構(gòu)環(huán)境下選擇彈性伸縮方案。

1 彈性伸縮場景和方案分析

1.1 彈性伸縮場景

因為業(yè)務需求在不斷變化，應用資源的在線負載也處于動態(tài)的變化中，所以在生產(chǎn)環(huán)境中常面臨資源的容量規(guī)劃不能滿足在線負載變化的困境。為解決這個問題，需要云平臺具備動態(tài)擴縮容應用和虛擬機集群節(jié)點的能力。隨著應用類型的多樣性發(fā)展及云平臺技術(shù)的革新，應用對云資源的需求也出現(xiàn)更加豐富的態(tài)勢。常見的應用類型可分在線負載型、離線任務型、定時任務型和特殊場景型等。不同的應用類型往往會對彈性伸縮提出不同的要求，如：在線負載型應用對彈出時間敏感，機器學習等離線任務型對價格敏感，定時任務對調(diào)度敏感，自定義伸縮和超算等異構(gòu)場景對彈出穩(wěn)定性敏感。單一的彈性伸縮策略已不能滿足這種多元化的需求，云平臺需要一種多維度、立體的彈性伸縮方案來解決這一難題。同時，隨著業(yè)務類型的豐富，彈性伸縮方案不僅需要基于“資源類型”指標，也需要基于“業(yè)務指標”等自定義指標，來解決更加復雜的應用場景下彈性伸縮的難題，并達到彈性伸縮方案覆蓋場景廣、適用性強和易擴展的目標。

1.2 不同維度的彈性伸縮方案

彈性伸縮方案首先通過“監(jiān)控系統(tǒng)”采集指標，然后將采集的指標聚合到“指標服務器”，并由其提供指標，最后“彈性伸縮組件”依據(jù)提供的指標觸發(fā)伸縮動作。用戶通常會根據(jù)業(yè)務的需求和集群的特點集成不同的方案，從而形成不同維度和業(yè)務類型的彈性伸縮方案。

從用戶角度分析，彈性伸縮分為集群非自定義彈性伸縮方案和自定義彈性伸縮方案。非自定義彈性伸縮方案是指自Kubernetes1.11 版本廢棄heapster后，迭代出了Metric Sever 組件，實現(xiàn)了內(nèi)部組件間的松耦合和可擴展性。自定義彈性伸縮方案是指引入外部監(jiān)控系統(tǒng)，并實現(xiàn)相應的適配器以適配到Kubernetes 中。從指標維度分析可將指標大致分為Resource Metrics、Custom Metrics 和External Metrics 3 類指標。其中：Resource Metrics 是指系統(tǒng)（核心）資源指標，指標由系統(tǒng)組件kubelet 提供；Custom Metrics 是包括Pods 和Object 的自定義指標類型，需配套搭建自定義指標服務器和“監(jiān)控系統(tǒng)”，其中監(jiān)控系統(tǒng)負責進行采集和處理數(shù)據(jù)并提供給自定義指標服務器；External Metrics 指標由公有云廠商提供，通?；谠贫说南⒎蘸拓撦d均衡器的QPS 等來實現(xiàn)彈性擴縮容。另外，“指標”通常以自定義資源（Custom Resource Definition，CRD）［2］方式定義和注冊為API 資源對象，從而被伸縮組件獲取到并根據(jù)預先設(shè)定規(guī)則進行彈性伸縮。

以彈性伸縮的對象為維度，彈性伸縮方案可分為應用和集群節(jié)點的彈性伸縮。應用節(jié)點的彈性伸縮是指擴縮容應用集群的節(jié)點數(shù)量，即Pod 的數(shù)量；集群節(jié)點的彈性伸縮是增加或減少虛擬機/物理節(jié)點的數(shù)量。

從資源的伸縮方向來分析，彈性伸縮大致分為兩類組件：一類是修改節(jié)點的數(shù)量從水平方向來彈性伸縮，使應用和集群在水平方向上具備彈性能力；另一類是從垂直方向來改變資源的分配量，而不改變Pod 的數(shù)量來實現(xiàn)資源容量的擴縮容。

圖1 所示分別以伸縮對象和伸縮方向為橫縱坐標建立彈性伸縮二象限。每個坐標點代表它的伸縮組件和配套的實現(xiàn)方案，忽略指標獲取和調(diào)度層面，單從彈性伸縮動作觸發(fā)層面分析，彈性伸縮組件包括CA（Cluster Autoscaler）、HPA（Horizontal Pod Autoscaler）、CPA（Cluster Proportional Autoscaler）、VPA（Vertical Pod Autoscaler）和AR（Addon Resizer）［2］。其中，CA 的功能是從水平方向擴縮容資源池的大小，即增加或減少物理節(jié)點的數(shù)目，HPA 的功能是動態(tài)增加或減少集群中Pod 的數(shù)目，CPA 可以依據(jù)集群的規(guī)模來同比例增加或減少集群中“核心組件”的數(shù)目，主要是為了解決“核心組件”的彈性問題，VPA的功能是增加或減少資源的請求值，不改變Pod 數(shù)目，Addon Resizer 則具備根據(jù)集群中節(jié)點的數(shù)目來調(diào)整負載的資源請求值，目前尚不成熟。另外，互不沖突的組件之間的搭配使用可以實現(xiàn)更加“極致”的彈性伸縮方法。

圖1 彈性伸縮維度示意圖Fig.1 Schematic diagram of elastic telescopic dimension

2 基于自定義指標的彈性伸縮方案

基于自定義指標的彈性伸縮方案是指引入三方監(jiān)控提供“業(yè)務”指標類型，結(jié)合HPA 組件實現(xiàn)基于業(yè)務指標的彈性伸縮方案。其中HPA 組件是彈性伸縮方案中的核心組件，三方監(jiān)控系統(tǒng)是指Prometheus 監(jiān)控體系。

2.1 HPA 組件

2.1.1 HPA 架構(gòu)

HPA 架構(gòu)如圖2所示。

圖2 HPA 伸縮架構(gòu)Fig.2 HPA telescopic architecture

HPA 架構(gòu)基本遵循Kubernetes 中聲明式API 和控制器模型［5］的設(shè)計理念。聲明式API 是Kubernetes（API Server）的一項重要能力，即以YAML（Yet Another Markup Language）［2］文件的方式聲明所期望集群的狀態(tài)，然后由控制器獲取集群的實際狀態(tài)并執(zhí)行相應的邏輯，來完成期望和實際狀態(tài)的調(diào)諧過程。其中，Kube apiserver 組件負責聲明式API 對象的管理，Controller（HPA）組件是彈性伸縮的控制器，Tunning Process 代表調(diào)諧的循環(huán)流程。它們統(tǒng)一由KUBER MASTER 管理，由三方監(jiān)控提供指標服務，最終將期望結(jié)果作用到實際的物理集群中。

2.1.2 HPA 代碼流程

如圖3所示，HPA Controller使用List&Watch［2］方法獲得所監(jiān)控對象的實際狀態(tài)，然后觸發(fā)相應的事件處理邏輯，最后完成調(diào)諧的過程。需要注意的是，HPA Controller 直接作用的資源對象并不是集群里的應用（Pod），而是一種“中間”資源對象的抽象概念，即Replicas。Replica 資源對象由復制控制器（Replication Controller，RC）［2］管理和維護，然后由它來控制Pod 的數(shù)量變化。

圖3 HPA 代碼流程Fig.3 HPA code procdure

代碼的入口部分是控制器管理器［2］，大部分Kubernetes 內(nèi)置核心組件都由該組件負責管理和維護，然后進入HPA Controller 部分，其中Metrics 指標獲取客戶端由之前的New Heapster Metrics Client 替換為New REST Metrics Client。前者耦合了Heapster進行資源監(jiān)控和指標獲取；后者以松耦合的能力集成了三方監(jiān)控并提供了Resouces Metrics、Custom Metrics 和External Metrics 等的指標類型，目前由autoscaling/v2beta2 版本支持。接著進入創(chuàng)建HPA Controller 流程，執(zhí)行控制循環(huán)并計算得出新的Replica 的期望值，并同步HPA 的資源狀態(tài)。最后RC 會監(jiān)測（Watch）Replica 資源對象的狀態(tài)，并執(zhí)行后續(xù)的代碼邏輯。

2.1.3 HPA 執(zhí)行流程

如圖4 所示，HPA 控制器首先從聚合API 持續(xù)獲取指標，再基于內(nèi)部的擴縮容規(guī)則進行計算，得到目標Pod 的副本數(shù)量，即Replicas 字段值，最后發(fā)出擴容的伸縮指令。當集群中“期望”和“實際”狀態(tài)不匹配時，HPA 控制器就會向RC、Deployment 或者ReplicaSet 發(fā)起Scale 指令，修改Replicas 字段的值，然后由相應控制器檢測該字段值的變化，從而調(diào)整Pod 的副本數(shù)量。

圖4 HPA 執(zhí)行流程Fig.4 HPA execution procdure

自Kubernetes1.9 版本以后，社區(qū)對StatefulSet（有狀態(tài)應用控制器）和Deployment［2］進行改進，切換到了統(tǒng)一的Scaler Interface 實現(xiàn)接口，所以HPA控制器同樣可以向StatefulSet 發(fā)起Scale 指令，從而調(diào)整“有狀態(tài)”應用的Pod 的數(shù)量。同理，如果用戶自己的CRD 支持Scaler 接口，就可以被HPA 管理，從而實現(xiàn)自定義資源類型的動態(tài)擴縮容。

3 彈性伸縮組件搭配方案

彈性伸縮方案的搭配可分為兩個分析方向：一是彈性伸縮組件和第三方監(jiān)控配套方案的搭配；二是彈性伸縮組件之間從不同維度上的搭配使用。其中，彈性伸縮組件搭配的配套方案是指集成Prometheus 監(jiān)控系統(tǒng)，實現(xiàn)自定義業(yè)務指標的彈性伸縮策略。組件之間的搭配是指面向不同的異構(gòu)環(huán)境、業(yè)務場景和用戶需求，各組件組合的多維度彈性伸縮方案。

3.1 自定義彈性伸縮配套方案

如圖5 所示，自定義彈性伸縮是指在指標層面上集成三方監(jiān)控，以獲取業(yè)務指標來實現(xiàn)自定義的彈性伸縮方法。目前，三方監(jiān)控主要有Prometheus、Microsoft Azure［16］和Datadog Cluster［17］等，然后實現(xiàn)相應的指標適配器（Custom Metircs Server），將指標聚合到Aggregator，由其向彈性伸縮控制器提供所需指標。本文論述的是基于Prometheus 監(jiān)控系統(tǒng)實現(xiàn)的自定義指標服務器方案，Prometheus 可以支持Kubernetes 集群的監(jiān)控，對時序數(shù)據(jù)具備優(yōu)秀的處理能力。

圖5 HPA 指標的配套方案Fig.5 Supporting scheme of HPA index

3.2 不同維度上彈性伸縮方案的組合

HPA 在資源池容量充足的情況下，可以方便地水平擴展應用節(jié)點的數(shù)量，但當資源池容量匱乏時，往往難以發(fā)揮作用。為解決該難題，需要搭配一個彈性伸縮組件，該組件具備在資源池容量不足時彈性擴展虛擬機/物理集群節(jié)點的數(shù)量，以增加資源池容量。資源需要縮容時同理。

3.3 CA 組件

CA 是物理集群節(jié)點級別的擴縮容，擴容的條件是集群存在未調(diào)度的Pod 且不在“冷卻周期”內(nèi)，縮容的條件是節(jié)點利用率低于閾值。

如圖6 所示，CA 會監(jiān)聽所有的Pod，當出現(xiàn)未調(diào)度Pod 時，便嘗試從配置好的彈性伸縮組（Auto Scaling Group，ASG）中選擇虛擬化的節(jié)點進行“模擬調(diào)度”。需要注意的是，增刪節(jié)點只是觸發(fā)ASG增刪節(jié)點的接口，具體的實現(xiàn)由云廠商來完成。而當某節(jié)點資源利用率低于閾值并到達指定時間時，CA 會在該節(jié)點打上禁止調(diào)度標簽，然后驅(qū)逐容器，最后逐一刪除節(jié)點。同時，CA 在伸縮規(guī)格、伸縮策略、多可用區(qū)和自定義伸縮等方面擁有豐富配置項，需要用戶按需進行配置。

圖6 CA 伸縮流程Fig.6 CA telescopic procdure

因調(diào)度器重新計算集群規(guī)模時具有時間間隔/冷卻周期，當新節(jié)點加入集群時，并不能立即感知它的存在，所以CA 對彈出時延敏感的應用場景支撐不足。為了使新彈出節(jié)點更好地滿足彈出時延敏感的應用場景，社區(qū)內(nèi)提出了兩個主流的方案：一是在YAML 文件中“聲明字段”添加節(jié)點的聲明信息來進行定向的調(diào)度，而不用一直等待冷卻周期結(jié)束；二是“占位”思想，設(shè)置優(yōu)先級非常低的Pod 來進行搶占調(diào)度。其中，“占位”思想是指設(shè)置優(yōu)先級較低的Pod占用而不使用資源。當集群中存在未調(diào)度Pod 時，可直接對優(yōu)先級低的Pod 進行資源搶占；此時集群中會出現(xiàn)優(yōu)先級低的Pod 處于未調(diào)度的狀態(tài)，進而觸發(fā)CA 組件來進行節(jié)點的伸縮?！罢嘉弧彼枷朐诓挥绊懻od 調(diào)度的情況下，利用CA 的觸發(fā)條件使得集群可以“快速”地彈出節(jié)點，以滿足彈出時延敏感的應用場景。

同時，“占位”思想也體現(xiàn)了當資源池資源充足時，使用HPA 組件從調(diào)度的維度來使得集群充滿彈性。當資源池資源匱乏時，使用CA 組件對資源池資源進行擴充，實現(xiàn)了組件間搭配使用的“極致”彈性伸縮方案。

HPA 常用于動態(tài)Pod 的伸縮場景，無法支持靜態(tài)Pod 的伸縮需求。Kubeadm［2］部署的系統(tǒng)“核心”組件都是以靜態(tài)Pod 方式存在于系統(tǒng)中，當集群規(guī)模變化時，為減輕系統(tǒng)組件的訪問壓力和增強可用性，需要“核心”組件具備彈性的能力。

3.4 CPA 組件

CPA（Cluster Proportional Autoscaler）是根據(jù)集群節(jié)點數(shù)目進行Pod 副本水平伸縮的組件，主要是解決Kubernetes 集群中“核心組件”的負載彈性問題。它的彈性伸縮策略包括“線性模型”和“梯度模型”兩種，分別通過線性公式和匹配區(qū)間方式進行副本數(shù)的計算。CPA 組件的集成分流了核心組件的負載壓力，使集群服務更加穩(wěn)定和高效。

HPA、CA 和CPA 組件的搭配使用賦予了水平方向上動態(tài)擴縮容集群節(jié)點的能力。當面向體量大的應用和“有狀態(tài)應用”［18］時，水平擴縮容節(jié)點便會變得極為困難。此時，需要一種解決方案來從不同維度和方向上擴縮容節(jié)點來解決這一難題，從而實現(xiàn)不同維度上的彈性伸縮方案。

靜脈滴注萬古霉素致中國人群急性腎損傷危險因素的系統(tǒng)評價 …………………………………………… 毛 婷等（13）：1836

3.5 VPA 組件

VPA（Vertical Pod Autoscaler）是以CRD 方式定義的垂直伸縮的組件，它能很好地支持有狀態(tài)應用的彈性伸縮，有效彌補了HPA 等組件對有狀態(tài)應用彈性伸縮支持不完善的問題。VPA 最具特色的是它的“資源推薦”功能，能根據(jù)實時和歷史負載數(shù)據(jù)計算出合適的資源值，以初始化或者“更新”資源的請求值。VPA 面向的是”離線“和”巨石“應用等場景，這些場景下的應用占用資源比例大或者因某些狀態(tài)無法”解耦“，從而很難從數(shù)量方面來擴縮容資源。VPA 具備從垂直方向來增加或減少資源量的能力，可以從垂直維度解決上述場景擴縮容需求。由于Kubernetes 目前仍不支持資源請求值的熱更新，VPA更新策略采取的是停止舊Pod 并啟動新Pod 的方式。

如圖7 所示，VPA 集成方案包括指標獲取模塊和VPA 控制器兩部分。其中，指標獲取由Metric Server 和Prometheus 組件完成。前者負責“實時”數(shù)據(jù)的采集，后者提供“歷史”監(jiān)控數(shù)據(jù)。VPA 控制器主要包含Recommender（資源建議）、Updater（資源更新）和Admission Controller（準入控制）等模塊。其中：Recommender 監(jiān)控當前和歷史負載數(shù)據(jù)，并提供資源請求的推薦值；Updater 監(jiān)控API Sever 中相關(guān)資源的變化，然后執(zhí)行相應的更新策略；Admission Controller 是Kubernetes API Server 的一項重要功能，具備“攔截”和“熱更新”相關(guān)API 資源對象的能力。

圖7 VPA 整體控制流程Fig.7 Procedure of VPA overall control

執(zhí)行流程首先是從監(jiān)控組件中獲取“實時”和“歷史”的資源負載數(shù)據(jù)，然后由Recommender 模塊決策，并在VPA API 對象中設(shè)置新的資源推薦值，此時Updater 模塊會監(jiān)測到VPA API 資源對象的變化，并觸發(fā)相應的“更新”和“異常處理”策略等。其中，“更新”簡略流程主要包括：由VPA 的“準入控制”模塊，“攔截”并“更新”VPA API 和它所關(guān)聯(lián)的Pod 資源對象的相關(guān)聲明字段值，執(zhí)行API Server 的資源有效化流程，再由控制器寫入重定義資源大小的注解，然后調(diào)度器負責調(diào)度，最后由Kubelet 執(zhí)行具體的Pod 資源的變化需求。

通過集成VPA 和HPA 組件，賦予了集群從不同維度上彈性伸縮資源的能力，提供了在異構(gòu)資源和不同業(yè)務場景下彈性伸縮方案選型的依據(jù)，同時滿足了各類應用在不同維度上彈性伸縮的差異化需求。

彈性伸縮組件的伸縮動作都是以獲取指標為前提，然后根據(jù)相應的計算規(guī)則得出所需的變化值。傳統(tǒng)的指標獲取手段是通過Metric Server 指標服務器提供的“資源”指標，如CPU 和內(nèi)存的利用率等，但復雜場景下的彈性伸縮需要根據(jù)業(yè)務類型和需求來定制彈性伸縮方案，增加彈性伸縮方案的靈活性和適用性。

4 監(jiān)控系統(tǒng)

無論是自定義指標的彈性伸縮方案還是VPA垂直伸縮獲取歷史負載信息，都需要集成三方的監(jiān)控方案來獲取豐富（業(yè)務）的指標類型。另外，可根據(jù)需要配套集成“可視化”和“報警”等組件。其中，“可視化”組件用來滿足彈性伸縮Pod 等各類資源的可視化分析需求，為監(jiān)控系統(tǒng)和方案決策提供更好的支持?！皥缶苯M件通過異常事件報警，整合故障恢復腳本，使集群更加穩(wěn)定。

4.1 Prometheus 監(jiān)控系統(tǒng)

Prometheus 作為云原生基金會（Cloud Native Computing Foundation，CNCF）的第二大開源項目，原生支持Kubernetes 并已成為事實上的容器監(jiān)控標準。它具備良好的時序數(shù)據(jù)處理能力和可擴展性，可以借助第三方存儲離線監(jiān)控數(shù)據(jù)或者選用Thano［19］方案，從而實現(xiàn)對歷史數(shù)據(jù)的保存和利用。同時，它也具備自定義業(yè)務層指標的能力，可以很好地支撐自定義的彈性伸縮方案，以滿足復雜場景下的彈性伸縮需求。

4.2 Prometheus 架構(gòu)和部署

如圖8 所示，Prometheus 的監(jiān)控方案主要包括指標采集、Prometheus 服務器、報警和圖形化顯示等部分。Prometheus 的指標采集方式分“推送”和“拉取”兩種，其中“拉取”方式為官方推薦，但如果因網(wǎng)絡或內(nèi)網(wǎng)的防火墻等原因無法拉取指標時，可以使用“推送”的方式。另外，使用“推送”方式推送指標時，常借助第三方緩存中間件緩存中間數(shù)據(jù)，以免大量的被動推送的數(shù)據(jù)直接沖擊服務器，從而引起服務器的癱瘓。而“拉取”指標需要提供Metrics 數(shù)據(jù)接口，如果采集目標沒有直接提供該接口，則使用相應Exporter 來暴露Kubernetes 集群中相關(guān)指標數(shù)據(jù)。

圖8 Promethues 整體架構(gòu)Fig.8 Promethues overall architecture

圖9 Prometheus Operator 部署架構(gòu)Fig.9 Prometheus Operator deployment architecture

由于Prometheus 具備對Kubernetes 資源的指標采集和配置的自動化處理能力，以及對時序數(shù)據(jù)檢索、存儲和聚類等高效的處理方法，使得Pormetheus作為三方監(jiān)控集成到Kubernetes 集群中，并為彈性伸縮組件提供“指標”成為事實上的標準。其中，Prometheus 提供和支持用戶自定義業(yè)務指標，其結(jié)合HPA 組件是實現(xiàn)基于自定義質(zhì)保彈性伸縮方案的最佳方案。

監(jiān)控系統(tǒng)的報警模塊主要依賴Prometheus 控制器的“規(guī)則配置”和AlertManager 報警接收器兩部分，其主要通過Prometheus 預設(shè)定規(guī)則來觸發(fā)告警動作，然后發(fā)送告警到外部報警組件的方法來顯現(xiàn)告警功能。圖形化顯示器除了Prometheus 自帶的Prometheus Web UI 外，因Grafana 出色的顯示和易配置功能，業(yè)內(nèi)常選用Grafana 作為替代方案。Grafana 集群資源示意圖如圖10 所示。

圖10 Grafana 集群資源示意圖Fig.10 Schematic diagram of Grafana cluster resources

5 實驗結(jié)果與分析

本文基于Kubernetes 集群環(huán)境進行實驗，搭建方式為Kubeadm，底層管理容器為Docker。集群由2 個Master 節(jié)點（主節(jié)點、備節(jié)點）和3 個Node 節(jié)點構(gòu)成。應用類型為在線負載型的Web 應用（Webtest），可接受多用戶端的并發(fā)訪問。壓測工具為Hey，以10 000 請求總量、并發(fā)度10 和10QPS 的訪問速率對應用進行壓力測試，在2 min、6 min 和10 min 3 個時間節(jié)點將上述的請求進行1 倍壓測量、2 倍壓測量和3 倍壓測量的持續(xù)壓力測試。

整個測試得出的數(shù)據(jù)結(jié)果和統(tǒng)計結(jié)果如下：

1）壓力測試前后應用集群的變化，即Pod 數(shù)量的變化。

2）在壓力測試中，應用集群中各Pod 的CPU 和內(nèi)存負載隨著時間的變化結(jié)果。

3）應用集群中所有Pod 的CPU 和內(nèi)存的變化平均值隨著時間的統(tǒng)計結(jié)果。

如圖11 所示，在壓力測試過程中，隨著應用集群負載的增加，Pod 的副本數(shù)出現(xiàn)明顯變化，在2 min、6 min 和10 min 施加壓力測試的時間節(jié)點上Pod 副本數(shù)變化明顯，說明彈性伸縮方案起到了隨著負載增加，擴大集群規(guī)模的作用。

圖11 應用集群副本數(shù)變化趨勢圖Fig.11 Change trend diagram of application cluster copies number

如表1、表2 所示，在2 min、6 min 和10 min 3 個壓力測試時間節(jié)點上，CPU 和內(nèi)存的負載在增加，同時應用集群中出現(xiàn)了新的Pod 副本。可以看出集群隨著訪問量的增加，各副本Pod 資源消耗的變化情況，以及當負載持續(xù)增加時，新副本的出現(xiàn)對集群中各副本Pod 負載逐漸趨于穩(wěn)定的影響情況。

表1 Web-test 集群中各Pod CPU(cores,m)分配值分析比較Table 1 Analysis and comparison of each Pod CPU(cores,m)allocation values in Web-test cluster

表2 Web-test 集群中各Pod 內(nèi)存分配值分析比較Table 2 Analysis and comparison of each Pod memory allocation values in Web-test cluster

如圖12 所示，在2 min、6 min 和10 min 3 個時間節(jié)點，當負載增加時（壓力測試）的1 min 內(nèi)，應用集群總體的CPU 和內(nèi)存使用總量在開始時迅速遞增，但隨之趨于平緩，甚至有所回落。

圖12 Web-test 應用集群CPU 平均負載時間走勢Fig.12 CPU average load time trend in Web-test application cluster

結(jié)合表2 可以看出，在同樣的時間節(jié)點范圍內(nèi)，當負載增加時，Pod 的副本數(shù)量也在增加，均衡了應用集群整體的負載流量，使整個集群的平均負載值沒有無節(jié)制性向上攀升直至Pod 崩潰，而是使應用逐漸趨于“平緩”狀態(tài)，甚至在6 min 中后的一段時間內(nèi)整體負載平均值有所回落，此時的Pod 副本數(shù)增量較大?？梢钥闯?，彈性伸縮可以增強應用集群的高可用能力，使集群趨于穩(wěn)定。

從表3 可以看出，彈性伸縮彈出的Pod 副本數(shù)在均衡策略的作用下均衡分布在各節(jié)點上，有利于集群資源的均衡及充分利用。表3 的驗證結(jié)果表明，節(jié)點的資源使用率是彈性伸縮彈出節(jié)點的重要考量因素之一，所以各節(jié)點的資源使用率基本保持在較均衡的狀態(tài)。

表3 Web-test集群Pod分布和節(jié)點內(nèi)存利用率統(tǒng)計結(jié)果Table 3 Statistical results of Pod distribution and node memory utilizationin in Web-test cluster

6 結(jié)束語

本文設(shè)計一種基于Kubernetes 云平臺的彈性伸縮方案。該方案在Kubernetes 中集成彈性伸縮服務，當負載流量突發(fā)變化時，可使應用集群更加穩(wěn)定和健壯，并在不同業(yè)務場景下根據(jù)需求選擇彈性伸縮組件之間的搭配方案，以滿足不同場景下業(yè)務的個性化彈性伸縮需求。實驗結(jié)果表明，通過集成監(jiān)控系統(tǒng)Promtheus、可視化和報警工具，該方案能夠增強應用集群的高可用能力，使集群趨于穩(wěn)定。在目前的研究中，彈性伸縮仍然基于實時的“容器工作流”負載工作，下一步將運用模型對負載進行短期或較長期預測，從而提出一種具有精準預測功能的“智能化”的彈性伸縮方案。