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

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

0 概述

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

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

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

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

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

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

1.1 彈性伸縮場景

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

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

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

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

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

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

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

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

2 基于自定義指標(biāo)的彈性伸縮方案

基于自定義指標(biāo)的彈性伸縮方案是指引入三方監(jiān)控提供“業(yè)務(wù)”指標(biāo)類型，結(jié)合HPA 組件實(shí)現(xiàn)基于業(yè)務(wù)指標(biāo)的彈性伸縮方案。其中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è)計(jì)理念。聲明式API 是Kubernetes（API Server）的一項(xiàng)重要能力，即以YAML（Yet Another Markup Language）［2］文件的方式聲明所期望集群的狀態(tài)，然后由控制器獲取集群的實(shí)際狀態(tài)并執(zhí)行相應(yīng)的邏輯，來完成期望和實(shí)際狀態(tài)的調(diào)諧過程。其中，Kube apiserver 組件負(fù)責(zé)聲明式API 對(duì)象的管理，Controller（HPA）組件是彈性伸縮的控制器，Tunning Process 代表調(diào)諧的循環(huán)流程。它們統(tǒng)一由KUBER MASTER 管理，由三方監(jiān)控提供指標(biāo)服務(wù)，最終將期望結(jié)果作用到實(shí)際的物理集群中。

2.1.2 HPA 代碼流程

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

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

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

2.1.3 HPA 執(zhí)行流程

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

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

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

3 彈性伸縮組件搭配方案

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

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

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

圖5 HPA 指標(biāo)的配套方案Fig.5 Supporting scheme of HPA index

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

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

3.3 CA 組件

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

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

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

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

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

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

3.4 CPA 組件

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

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

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

3.5 VPA 組件

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如表1、表2 所示，在2 min、6 min 和10 min 3 個(gè)壓力測試時(shí)間節(jié)點(diǎn)上，CPU 和內(nèi)存的負(fù)載在增加，同時(shí)應(yīng)用集群中出現(xiàn)了新的Pod 副本?？梢钥闯黾弘S著訪問量的增加，各副本Pod 資源消耗的變化情況，以及當(dāng)負(fù)載持續(xù)增加時(shí)，新副本的出現(xiàn)對(duì)集群中各副本Pod 負(fù)載逐漸趨于穩(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 個(gè)時(shí)間節(jié)點(diǎn)，當(dāng)負(fù)載增加時(shí)（壓力測試）的1 min 內(nèi)，應(yīng)用集群總體的CPU 和內(nèi)存使用總量在開始時(shí)迅速遞增，但隨之趨于平緩，甚至有所回落。

圖12 Web-test 應(yīng)用集群CPU 平均負(fù)載時(shí)間走勢Fig.12 CPU average load time trend in Web-test application cluster

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

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

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

6 結(jié)束語

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