概述

Horizontal Pod Autoscaler（HPA，Pod水平自動伸縮），根據(jù)平均 CPU 利用率、平均內(nèi)存利用率或你指定的任何其他自定義指標自動調(diào)整 Deployment 、ReplicaSet 或 StatefulSet 或其他類似資源，實現(xiàn)部署的自動擴展和縮減，讓部署的規(guī)模接近于實際服務的負載。HPA不適用于無法縮放的對象，例如DaemonSet。

官方文檔：https://kubernetes.io/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/

實際生產(chǎn)中，一般使用這四類指標：

• Resource metrics——CPU核 和 內(nèi)存利用率指標。
• Pod metrics——例如網(wǎng)絡利用率和流量。
• Object metrics——特定對象的指標，比如Ingress, 可以按每秒使用請求數(shù)來擴展容器。
• Custom metrics——自定義監(jiān)控，比如通過定義服務響應時間，當響應時間達到一定指標時自動擴容。

安裝 metrics-server

HAP 前提條件

默認情況下，Horizontal Pod Autoscaler 控制器會從一系列的 API 中檢索度量值。集群管理員需要確保下述條件，以保證 HPA 控制器能夠訪問這些 API：

• 對于資源指標，將使用 metrics.k8s.io API，一般由 metrics-server 提供。它可以作為集群插件啟動。
• 對于自定義指標，將使用 custom.metrics.k8s.io API。它由其他度量指標方案廠商的“適配器（Adapter）” API 服務器提供。檢查你的指標管道以查看是否有可用的 Kubernetes 指標適配器。
• 對于外部指標，將使用 external.metrics.k8s.io API。可能由上面的自定義指標適配器提供。

Kubernetes Metrics Server：

• Kubernetes Metrics Server 是 Cluster 的核心監(jiān)控數(shù)據(jù)的聚合器，kubeadm 默認是不部署的。
• Metrics Server 供 Dashboard 等其他組件使用，是一個擴展的 APIServer，依賴于 API Aggregator。所以，在安裝 Metrics Server 之前需要先在 kube-apiserver 中開啟 API Aggregator。
• Metrics API 只可以查詢當前的度量數(shù)據(jù)，并不保存歷史數(shù)據(jù)。
• Metrics API URI 為 /apis/metrics.k8s.io/，在 k8s.io/metrics 下維護。
• 必須部署 metrics-server 才能使用該 API，metrics-server 通過調(diào)用 kubelet Summary API 獲取數(shù)據(jù)。

開啟 API Aggregator

#添加這行
#--enable-aggregator-routing=true
###修改每個 API Server 的 kube-apiserver.yaml 配置開啟 Aggregator Routing：修改 manifests 配置后 API Server 會自動重啟生效。
cat/etc/kubernetes/manifests/kube-apiserver.yaml

開始安裝 metrics-server

GitHub地址：https://github.com/kubernetes-sigs/metrics-server/releases

下載

wgethttps://github.com/kubernetes-sigs/metrics-server/releases/download/metrics-server-helm-chart-3.8.2/components.yaml

修改

...
template:
metadata:
labels:
k8s-app:metrics-server
spec:
containers:
-args:
---cert-dir=/tmp
---secure-port=4443
---kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
---kubelet-use-node-status-port
---kubelet-insecure-tls#加上該啟動參數(shù)，不加可能會報錯
image:registry.aliyuncs.com/google_containers/metrics-server:v0.6.1#鏡像地址根據(jù)情況修改
imagePullPolicy:IfNotPresent
...
metrics-serverpod無法啟動，出現(xiàn)日志unabletofullycollectmetrics:...x509:cannotvalidatecertificateforbecause...itdoesn'tcontainanyIPSANs...

解決方法：在metrics-server中添加--kubelet-insecure-tls參數(shù)跳過證書校驗

開始安裝

kubectlapply-fcomponents.yaml
kubectlgetpod-nkube-system|grepmetrics-server
#查看
kubectlgetpod-nkube-system|grepmetrics-server
#查看node和pod資源使用情況
kubectltopnodes
kubectltoppods

Horizontal Pod Autoscaler 工作原理

原理架構(gòu)圖

• 自動檢測周期由 kube-controller-manager 的 --horizontal-pod-autoscaler-sync-period 參數(shù)設置（默認間隔為 15 秒）。
• metrics-server 提供 metrics.k8s.io API 為pod資源的使用提供支持。
• 15s/周期 -> 查詢metrics.k8s.io API -> 算法計算 -> 調(diào)用scale 調(diào)度 -> 特定的擴縮容策略執(zhí)行。

HPA擴縮容算法

從最基本的角度來看，Pod 水平自動擴縮控制器根據(jù)當前指標和期望指標來計算擴縮比例。

期望副本數(shù)=ceil[當前副本數(shù)*(當前指標/期望指標)]

擴容

如果計算出的擴縮比例接近 1.0, 將會放棄本次擴縮, 度量指標 / 期望指標接近1.0。

縮容

冷卻/延遲: 如果延遲（冷卻）時間設置的太短，那么副本數(shù)量有可能跟以前一樣出現(xiàn)抖動。默認值是 5 分鐘（5m0s）--horizontal-pod-autoscaler-downscale-stabilization

特殊處理

• 丟失度量值：縮小時假設這些 Pod 消耗了目標值的 100%， 在需要放大時假設這些 Pod 消耗了 0% 目標值。這可以在一定程度上抑制擴縮的幅度。
• 存在未就緒的pod的時候：我們保守地假設尚未就緒的 Pod 消耗了期望指標的 0%，從而進一步降低了擴縮的幅度。
• 未就緒的 Pod 和缺少指標的 Pod 考慮進來再次計算使用率。如果新的比率與擴縮方向相反，或者在容忍范圍內(nèi)，則跳過擴縮。否則，我們使用新的擴縮比例。指定了多個指標， 那么會按照每個指標分別計算擴縮副本數(shù)，取最大值進行擴縮。

HPA 對象定義

apiVersion:autoscaling/v2beta2
kind:HorizontalPodAutoscaler
metadata:
name:nginx
spec:
behavior:
scaleDown:
policies:
-type:Pods
value:4
periodSeconds:60
-type:Percent
value:10
periodSeconds:60
stabilizationWindowSeconds:300

scaleTargetRef:
apiVersion:apps/v1
kind:Deployment
name:nginx
minReplicas:1
maxReplicas:10
metrics:
-type:Resource
resource:
name:cpu
target:
type:Utilization
averageUtilization:50

HPA對象默認行為

behavior:
scaleDown:
stabilizationWindowSeconds:300
policies:
-type:Percent
value:100
periodSeconds:15
scaleUp:
stabilizationWindowSeconds:0
policies:
-type:Percent
value:100
periodSeconds:15
-type:Pods
value:4
periodSeconds:15
selectPolicy:Max

示例演示

編排yaml

apiVersion:autoscaling/v2
kind:HorizontalPodAutoscaler
metadata:
name:hap-nginx
spec:
maxReplicas:10#最大擴容到10個節(jié)點（pod）
minReplicas:1#最小擴容1個節(jié)點（pod）
metrics:
-resource:
name:cpu
target:
averageUtilization:40#CPU平局資源使用率達到40%就開始擴容，低于40%就是縮容
#設置內(nèi)存
# AverageValue：40
type:Utilization
type:Resource
scaleTargetRef:
apiVersion:apps/v1
kind:Deployment
name:hap-nginx
---
apiVersion:v1
kind:Service
metadata:
name:hap-nginx
spec:
type:NodePort
ports:
-name:"http"
port:80
targetPort:80
nodePort:30080
selector:
service:hap-nginx
---
apiVersion:apps/v1
kind:Deployment
metadata:
name:hap-nginx
spec:
replicas:1
selector:
matchLabels:
service:hap-nginx
template:
metadata:
labels:
service:hap-nginx
spec:
containers:
-name:hap-nginx
image:nginx:latest
resources:
requests:
cpu:100m
memory:100Mi
limits:
cpu:200m
memory:200Mi

主要參數(shù)解釋如下：

• scaleTargetRef：目標作用對象，可以是Deployment、ReplicationController或ReplicaSet。
• minReplicas和maxReplicas：Pod副本數(shù)量的最小值和最大值，系統(tǒng)將在這個范圍內(nèi)進行自動擴縮容操作，并維持每個Pod的內(nèi)存使用率為40%，這個值就是上面設置的閾值averageUtilization。
• metrics：目標指標值。在metrics中通過參數(shù)type定義指標的類型；通過參數(shù)target定義相應的指標目標值，系統(tǒng)將在指標數(shù)據(jù)達到目標值時（考慮容忍度的區(qū)間，見前面算法部分的說明）觸發(fā)擴縮容操作。
• 對于CPU使用率，在target參數(shù)中設置averageUtilization定義目標平均CPU使用率。
• 對于內(nèi)存資源，在target參數(shù)中設置AverageValue定義目標平均內(nèi)存使用值。

執(zhí)行

kubectlapply-ftest.yaml

使用 ab 工具進行壓測

進入apache官網(wǎng) http://httpd.apache.org/ 下載apache即可，或者直接通過yum安裝apache都行，這里選擇最簡單的方式y(tǒng)um安裝

yuminstallhttpd-y

開始壓測

ab-n100000-c800http://local-168-182-112:30080/

#-c：并發(fā)數(shù)
#-n：總請求數(shù)

從上圖發(fā)現(xiàn)已經(jīng)實現(xiàn)了根據(jù)CPU 動態(tài)擴容了，關(guān)于更多 HAP相關(guān)的知識點，可以先查看官方文檔。