基于Kubernetes 云平臺的彈性伸縮方案設計與實現

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

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

0 概述

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

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

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

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

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

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

1.1 彈性伸縮場景

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

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

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

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

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

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

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

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

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

基于自定義指標的彈性伸縮方案是指引入三方監控提供“業務”指標類型，結合HPA 組件實現基于業務指標的彈性伸縮方案。其中HPA 組件是彈性伸縮方案中的核心組件，三方監控系統是指Prometheus 監控體系。

2.1 HPA 組件

2.1.1 HPA 架構

HPA 架構如圖2所示。

圖2 HPA 伸縮架構Fig.2 HPA telescopic architecture

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

2.1.2 HPA 代碼流程

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

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

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

2.1.3 HPA 執行流程

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

圖4 HPA 執行流程Fig.4 HPA execution procdure

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

3 彈性伸縮組件搭配方案

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

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

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

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

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

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

3.3 CA 組件

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

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

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

因調度器重新計算集群規模時具有時間間隔/冷卻周期，當新節點加入集群時，并不能立即感知它的存在，所以CA 對彈出時延敏感的應用場景支撐不足。為了使新彈出節點更好地滿足彈出時延敏感的應用場景，社區內提出了兩個主流的方案：一是在YAML 文件中“聲明字段”添加節點的聲明信息來進行定向的調度，而不用一直等待冷卻周期結束；二是“占位”思想，設置優先級非常低的Pod 來進行搶占調度。其中，“占位”思想是指設置優先級較低的Pod占用而不使用資源。當集群中存在未調度Pod 時，可直接對優先級低的Pod 進行資源搶占；此時集群中會出現優先級低的Pod 處于未調度的狀態，進而觸發CA 組件來進行節點的伸縮。“占位”思想在不影響正常Pod 調度的情況下，利用CA 的觸發條件使得集群可以“快速”地彈出節點，以滿足彈出時延敏感的應用場景。

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

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

3.4 CPA 組件

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

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

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

3.5 VPA 組件

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

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

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

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

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

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

4 監控系統

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

4.1 Prometheus 監控系統

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

4.2 Prometheus 架構和部署

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

圖8 Promethues 整體架構Fig.8 Promethues overall architecture

圖9 Prometheus Operator 部署架構Fig.9 Prometheus Operator deployment architecture

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

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

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

5 實驗結果與分析

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

整個測試得出的數據結果和統計結果如下：

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

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

3）應用集群中所有Pod 的CPU 和內存的變化平均值隨著時間的統計結果。

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

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

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

表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 內存分配值分析比較Table 2 Analysis and comparison of each Pod memory allocation values in Web-test cluster

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

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

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

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

表3 Web-test集群Pod分布和節點內存利用率統計結果Table 3 Statistical results of Pod distribution and node memory utilizationin in Web-test cluster

6 結束語

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