Kubernetes中彈性伸縮最常用組件HPA的原理與演進(jìn)是怎樣的

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)Kubernetes中彈性伸縮最常用組件HPA的原理與演進(jìn)是怎樣的，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

前言

今天會(huì)為大家介紹在 Kubernetes 中彈性伸縮最常用的組件 HPA（Horizontal Pod Autoscaler）。HPA 是通過(guò)計(jì)算 Pod 的實(shí)際工作負(fù)載進(jìn)行重新容量規(guī)劃的組件，在資源池符合滿足條件的前提下，HPA 可以很好的實(shí)現(xiàn)彈性伸縮的模型。HPA 到目前為止，已經(jīng)演進(jìn)了三個(gè)大版本，本文將會(huì)為大家詳細(xì)解析 HPA 底層的原理以及在 Kubernetes 中彈性伸縮概念的演變歷程。

HPA 基本原理

HPA 是根據(jù)實(shí)際工作負(fù)載水平伸縮容器數(shù)目的組件，從中可以提煉出兩個(gè)非常重要的關(guān)鍵字：負(fù)載和數(shù)目。我們可以用一個(gè)非常簡(jiǎn)單的數(shù)學(xué)公式進(jìn)行歸納： 下面舉一個(gè)實(shí)際例子進(jìn)行上述公式的闡述。 假設(shè)存在一個(gè)叫 A 的 Deployment，包含3個(gè) Pod，每個(gè)副本的 Request 值是 1 核，當(dāng)前 3 個(gè) Pod 的 CPU 利用率分別是 60%、70% 與 80%，此時(shí)我們?cè)O(shè)置 HPA 閾值為 50%，最小副本為 3，最大副本為 10。接下來(lái)我們將上述的數(shù)據(jù)帶入公式中：

• 總的 Pod 的利用率是 60%+70%+80% = 210%；

• 當(dāng)前的 Target 是 3；

• 算式的結(jié)果是 70%，大于50%閾值，因此當(dāng)前的 Target 數(shù)目過(guò)小，需要進(jìn)行擴(kuò)容；

• 重新設(shè)置 Target 值為 5，此時(shí)算式的結(jié)果為 42% 低于 50%，判斷還需要擴(kuò)容兩個(gè)容器；

• 此時(shí) HPA 設(shè)置 Replicas 為 5，進(jìn)行 Pod 的水平擴(kuò)容。

經(jīng)過(guò)上面的推演，可以協(xié)助開(kāi)發(fā)者快速理解 HPA 最核心的原理，不過(guò)上面的推演結(jié)果和實(shí)際情況下是有所出入的，如果開(kāi)發(fā)者進(jìn)行試驗(yàn)的話，會(huì)發(fā)現(xiàn) Replicas 最終的結(jié)果是 6 而不是 5。這是由于 HPA 中一些細(xì)節(jié)的處理導(dǎo)致的，主要包含如下三個(gè)主要的方面：

1. 噪聲處理

通過(guò)上面的公式可以發(fā)現(xiàn)，Target 的數(shù)目很大程度上會(huì)影響最終的結(jié)果，而在 Kubernetes 中，無(wú)論是變更或者升級(jí)，都更傾向于使用 Recreate 而不是 Restart 的方式進(jìn)行處理。這就導(dǎo)致了在 Deployment 的生命周期中，可能會(huì)出現(xiàn)某一個(gè)時(shí)間，Target 會(huì)由于計(jì)算了 Starting 或者 Stopping 的 Pod 而變得很大。這就會(huì)給 HPA 的計(jì)算帶來(lái)非常大的噪聲，在 HPA Controller 的計(jì)算中，如果發(fā)現(xiàn)當(dāng)前的對(duì)象存在 Starting 或者 Stopping 的 Pod 會(huì)直接跳過(guò)當(dāng)前的計(jì)算周期，等待狀態(tài)都變?yōu)?nbsp;Running 再進(jìn)行計(jì)算。

2. 冷卻周期

在彈性伸縮中，冷卻周期是不能逃避的一個(gè)話題，很多時(shí)候我們期望快速?gòu)棾雠c快速回收，而另一方面，我們又不希望集群震蕩，所以一個(gè)彈性伸縮活動(dòng)冷卻周期的具體數(shù)值是多少，一直被開(kāi)發(fā)者所挑戰(zhàn)。在 HPA 中，默認(rèn)的擴(kuò)容冷卻周期是 3 分鐘，縮容冷卻周期是 5 分鐘。

3. 邊界值計(jì)算

我們回到剛才的計(jì)算公式，第一次我們算出需要彈出的容器數(shù)目是 5，此時(shí)擴(kuò)容后整體的負(fù)載是 42%，但是我們似乎忽略了一個(gè)問(wèn)題：一個(gè)全新的 Pod 啟動(dòng)會(huì)不會(huì)自己就占用了部分資源？此外，8% 的緩沖區(qū)是否就能夠緩解整體的負(fù)載情況？要知道當(dāng)一次彈性擴(kuò)容完成后，下一次擴(kuò)容要最少等待 3 分鐘才可以繼續(xù)擴(kuò)容。為了解決這些問(wèn)題，HPA 引入了邊界值 △，目前在計(jì)算邊界條件時(shí)，會(huì)自動(dòng)加入 10% 的緩沖，這也是為什么在剛才的例子中最終的計(jì)算結(jié)果為 6 的原因。

HPA 的演進(jìn)歷程

在了解了 HPA 的基本原理后，我們來(lái)聊一下 HPA 的演進(jìn)歷程，目前 HPA 已經(jīng)支持了 autoscaling/v1、autoscaling/v1beta1 和 autoscaling/v1beta2 三個(gè)大版本。大部分的開(kāi)發(fā)者目前比較熟悉的是autoscaling/v1 的版本，這個(gè)版本的特點(diǎn)是只支持 CPU 一個(gè)指標(biāo)的彈性伸縮，大致的 yaml 內(nèi)容如下：

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50

接下來(lái)我們?cè)賮?lái)看一下 v2beta1 與 v2beta2 的 yaml，會(huì)發(fā)現(xiàn)里面支持的 metrics 類型增加了很多，結(jié)構(gòu)也復(fù)雜了很多。

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        kind: AverageUtilization
        averageUtilization: 50
  - type: Pods
    pods:
      metric:
        name: packets-per-second
      targetAverageValue: 1k
  - type: Object
    object:
      metric:
        name: requests-per-second
      describedObject:
        apiVersion: extensions/v1beta1
        kind: Ingress
        name: main-route
      target:
        kind: Value
        value: 10k
---
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

而這些變化的產(chǎn)生不得不提的是 Kubernetes 社區(qū)中對(duì)監(jiān)控與監(jiān)控指標(biāo)的認(rèn)識(shí)與轉(zhuǎn)變。在 Kubernetes 中，有兩個(gè)核心的監(jiān)控組件 Heapster 與 Metrics Server。Heapster 是早期 Kubernetes 社區(qū)中唯一的監(jiān)控組件，它所包含的功能很強(qiáng)大，通過(guò)采集 kubelet 提供的 metrics 接口，并支持監(jiān)控?cái)?shù)據(jù)的離線與歸檔。

大致的架構(gòu)圖如上：source 的部分是不同的數(shù)據(jù)來(lái)源，主要是 kubelet 的 common api 與后來(lái)提供的 summary api；processor 的作用是將采集的數(shù)據(jù)進(jìn)行處理，分別在 namespace 級(jí)別、cluster 級(jí)別進(jìn)行聚合，并創(chuàng)建新的聚合類型的監(jiān)控?cái)?shù)據(jù)；sink 的作用是數(shù)據(jù)離線與歸檔，常見(jiàn)的歸檔方式包括 influxdb、kafka 等等。Heapster 組件在相當(dāng)長(zhǎng)時(shí)間成為了 Kubernetes 社區(qū)中監(jiān)控?cái)?shù)據(jù)的唯一來(lái)源，也因此有非常多的和監(jiān)控相關(guān)的組件通過(guò) Heapster 的鏈路進(jìn)行監(jiān)控?cái)?shù)據(jù)的消費(fèi)。但是后來(lái)，Kubernetes 社區(qū)發(fā)現(xiàn)了 Heapster 存在非常嚴(yán)重的幾個(gè)問(wèn)題：

• 強(qiáng)大繁多的 Sink 由不同的 Maintainer 進(jìn)行維護(hù)，50% 以上的 Heapster Issues 都是關(guān)于 Sink 無(wú)法使用的，而由于 Maintainer 的活躍度不同造成 Heapster 社區(qū)有大量的 issues 無(wú)法解決；

• 對(duì)于開(kāi)發(fā)者而言，監(jiān)控?cái)?shù)據(jù)的類型已經(jīng)不再是 CPU、Memory 這么簡(jiǎn)單的幾個(gè)指標(biāo)項(xiàng)了，越來(lái)越多的開(kāi)發(fā)者需要應(yīng)用內(nèi)或者接入層的監(jiān)控指標(biāo)，例如 ingress 的 QPS、應(yīng)用的在線活躍人數(shù)等等。而這些指標(biāo)的獲取是 Heapster 無(wú)法實(shí)現(xiàn)的；

• Prometheus 的成熟讓 Heapster 的生存空間不斷被擠壓，自從 Prometheus 被 CNCF 收錄為孵化項(xiàng)目，Heapster 的不可替代地位被正式移除。

社區(qū)經(jīng)過(guò)反思后，決定將監(jiān)控的指標(biāo)邊界進(jìn)行劃分，分為 Resource、Custom 和 External 三種不同的 Metrics，而 Heapster(Metrics Server) 的定位就只關(guān)心 Resource 這一種指標(biāo)類型。為了解決代碼維護(hù)性的問(wèn)題，Metrics Server 對(duì) Heapster 進(jìn)行了裁剪，裁剪后的架構(gòu)如下：

去掉了 Sink 的機(jī)制，并將調(diào)用方式改為標(biāo)準(zhǔn)的 API 注冊(cè)的方式，這樣的好處是既精簡(jiǎn)了核心代碼的邏輯又提供了替代的可能，也就是說(shuō)此時(shí) Metrics Server 也是可以替代的，只要實(shí)現(xiàn)了相同的 API 接口，并注冊(cè)到 API Server 上，就可以替代 Metrics Server。

接下來(lái)我們解析一下三種不同的 Metrics 與使用的場(chǎng)景：

其中 autoscaling/v2beta1 支持 Resource 與 Custom 兩種指標(biāo)，而 autoscaling/v2beta2 中增加了 External 的指標(biāo)的支持。

HPA 目前已經(jīng)進(jìn)入了 GA 階段，在大體的功能上面不會(huì)進(jìn)行過(guò)多的變化，目前社區(qū)的主要發(fā)力點(diǎn)在如何配置化的調(diào)整細(xì)節(jié)參數(shù)、豐富監(jiān)控 adapter 的實(shí)現(xiàn)等等。

上述就是小編為大家分享的Kubernetes中彈性伸縮最常用組件HPA的原理與演進(jìn)是怎樣的了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。