------> 課程視頻同步分享在今日頭條和B站
大家好，我是博哥愛(ài)運(yùn)維，這節(jié)課帶來(lái)k8s的HPA 自動(dòng)水平伸縮pod（ 視頻后面有彩蛋 : ) ）。
我們知道，初始Pod的數(shù)量是可以設(shè)置的，同時(shí)業(yè)務(wù)也分流量高峰和低峰，那么怎么即能不過(guò)多的占用K8s的資源，又能在服務(wù)高峰時(shí)自動(dòng)擴(kuò)容pod的數(shù)量呢，在K8s上的答案是Horizontal Pod Autoscaling，簡(jiǎn)稱HPA 自動(dòng)水平伸縮，這里只以我們常用的CPU計(jì)算型服務(wù)來(lái)作為HPA的測(cè)試，這基本滿足了大部分業(yè)務(wù)服務(wù)需求，其它如vpa縱向擴(kuò)容，還有基于業(yè)務(wù)qps等特殊指標(biāo)擴(kuò)容這個(gè)在后面計(jì)劃會(huì)以獨(dú)立高級(jí)番外篇來(lái)作教程。
自動(dòng)水平伸縮，是指運(yùn)行在k8s上的應(yīng)用負(fù)載(POD)，可以根據(jù)資源使用率進(jìn)行自動(dòng)擴(kuò)容、縮容，它依賴metrics-server服務(wù)pod使用資源指標(biāo)收集；我們知道應(yīng)用的資源使用率通常都有高峰和低谷，所以k8s的HPA特性應(yīng)運(yùn)而生；它也是最能體現(xiàn)區(qū)別于傳統(tǒng)運(yùn)維的優(yōu)勢(shì)之一，不僅能夠彈性伸縮，而且完全自動(dòng)化！
我們?cè)谏a(chǎn)中通常用得最多的就是基于服務(wù)pod的cpu使用率metrics來(lái)自動(dòng)擴(kuò)容pod數(shù)量，下面來(lái)以生產(chǎn)的標(biāo)準(zhǔn)來(lái)實(shí)戰(zhàn)測(cè)試下（注意：使用HPA前我們要確保K8s集群的dns服務(wù)和metrics服務(wù)是正常運(yùn)行的，并且我們所創(chuàng)建的服務(wù)需要配置指標(biāo)分配）
# pod內(nèi)資源分配的配置格式如下：
# 默認(rèn)可以只配置requests，但根據(jù)生產(chǎn)中的經(jīng)驗(yàn)，建議把limits資源限制也加上，因?yàn)閷?duì)K8s來(lái)說(shuō)，只有這兩個(gè)都配置了且配置的值都要一樣，這個(gè)pod資源的優(yōu)先級(jí)才是最高的，在node資源不夠的情況下，首先是把沒(méi)有任何資源分配配置的pod資源給干掉，其次是只配置了requests的，最后才是兩個(gè)都配置的情況，仔細(xì)品品
resources:
limits: # 限制單個(gè)pod最多能使用1核（1000m 毫核）cpu以及2G內(nèi)存
cpu: "1"
memory: 2Gi
requests: # 保證這個(gè)pod初始就能分配這么多資源
cpu: "1"
memory: 2Gi
我們先不做上面配置的改動(dòng)，看看直接創(chuàng)建hpa會(huì)產(chǎn)生什么情況：
# 為deployment資源web創(chuàng)建hpa，pod數(shù)量上限3個(gè)，最低1個(gè)，在pod平均CPU達(dá)到50%后開(kāi)始擴(kuò)容
kubectl autoscale deployment web --max=3 --min=1 --cpu-percent=50
#過(guò)一會(huì)看下這個(gè)hpa資源的描述(截取這下面一部分)
# 下面提示說(shuō)到，HPA缺少最小資源分配的request參數(shù)
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededGetScale the HPA controller was able to get the target's current scale
ScalingActive False FailedGetResourceMetric the HPA was unable to compute the replica count: missing request for cpu
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedComputeMetricsReplicas 3m46s (x12 over 6m33s) horizontal-pod-autoscaler invalid metrics (1 invalid out of 1), first error is: failed to get cpu utilization: missing request for cpu
Warning FailedGetResourceMetric 89s (x21 over 6m33s) horizontal-pod-autoscaler missing request for cpu
我們現(xiàn)在以上面創(chuàng)建的deployment資源web來(lái)實(shí)踐下hpa的效果，首先用我們學(xué)到的方法導(dǎo)出web的yaml配置，并增加資源分配配置增加：
# cat web.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: web
name: web
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- image: nginx:1.21.6
name: nginx
resources:
limits: # 因?yàn)槲疫@里是測(cè)試環(huán)境，所以這里CPU只分配50毫核（0.05核CPU）和20M的內(nèi)存
cpu: "50m"
memory: 20Mi
requests: # 保證這個(gè)pod初始就能分配這么多資源
cpu: "50m"
memory: 20Mi
更新web資源：
# kubectl apply -f web.yaml
deployment.apps/web configured
然后創(chuàng)建hpa：
# kubectl autoscale deployment web --max=3 --min=1 --cpu-percent=50
horizontalpodautoscaler.autoscaling/web autoscaled
# 等待一會(huì)，可以看到相關(guān)的hpa信息（K8s上metrics服務(wù)收集所有pod資源的時(shí)間間隔大概在60s的時(shí)間）
# kubectl get hpa -w
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
web Deployment/web <unknown>/50% 1 3 1 39s
web Deployment/web 0%/50% 1 3 1 76s
我們來(lái)模擬業(yè)務(wù)流量增長(zhǎng)，看看hpa自動(dòng)伸縮的效果：
# 我們啟動(dòng)一個(gè)臨時(shí)pod，來(lái)模擬大量請(qǐng)求
# kubectl run -it --rm busybox --image=registry.cn-shanghai.aliyuncs.com/acs/busybox:v1.29.2 -- sh
/ # while :;do wget -q -O- http://web;done
# 等待2 ~ 3分鐘，注意k8s為了避免頻繁增刪pod，對(duì)副本的增加速度有限制
# kubectl get hpa web -w
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
web Deployment/web 0%/50% 1 3 1 11m
web Deployment/web 102%/50% 1 3 1 14m
web Deployment/web 102%/50% 1 3 3 14m
# 看下hpa的描述信息下面的事件記錄
# kubectl describe hpa web
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
...
Normal SuccessfulRescale 62s horizontal-pod-autoscaler New size: 3; reason: cpu resource utilization (percentage of request) above target
好了，HPA的自動(dòng)擴(kuò)容已經(jīng)見(jiàn)過(guò)了，現(xiàn)在停掉壓測(cè)，觀察下HPA的自動(dòng)收縮功能：
# 可以看到，在業(yè)務(wù)流量高峰下去后，HPA并不急著馬上收縮pod數(shù)量，而是等待5分鐘后，再進(jìn)行收斂，這是穩(wěn)妥的作法，是k8s為了避免頻繁增刪pod的一種手段
# kubectl get hpa web -w
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
web Deployment/web 102%/50% 1 3 3 16m
web Deployment/web 0%/50% 1 3 3 16m
web Deployment/web 0%/50% 1 3 3 20m
web Deployment/web 0%/50% 1 3 1 21m
附：
VPA https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler
KEDA基于自定義api接口伸縮
https://keda.sh/docs/2.12/scalers/metrics-api/
KEDA基于Prometheus指標(biāo)伸縮文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-754104.html
https://keda.sh/docs/2.12/scalers/prometheus/文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-754104.html
到了這里，關(guān)于第15關(guān) K8s HPA：自動(dòng)水平伸縮Pod，實(shí)現(xiàn)彈性擴(kuò)展和資源優(yōu)化的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
