Kubernetes--k8s--进阶--全面了解HPA--部署HPA实现高可用和成本控制
什么是HPA
我們的k8s集群 如果是 針對node層面是有Cluster Autoscaler彈性伸縮來做高可用和成本控制的優(yōu)化的。
也就是說 我們一開始 沒有pod任務(wù)在運行的時候 不需要node節(jié)點時，k8s的集群可以只啟動少量node節(jié)點來做常駐服務(wù)pod的部署。 當(dāng) 有大批量的任務(wù)pod 需要運行時， k8s集群會根據(jù) 每個pod需要的資源狀態(tài)來 申請啟動新的node節(jié)點。 當(dāng)任務(wù)高峰期過后，pod運行的數(shù)量減少，node的數(shù)量就會收縮，不使用的node會被回收，保證 k8s集群的高可用低成本運行。
那么問題來了，常駐服務(wù)用來提供給外部的pod又怎么實現(xiàn)高可用呢？ 我們一般會使用Deployment中的replicas參數(shù)，設(shè)置多個副本集來保證 服務(wù)的高可用，但是 這是一個固定的值，比如 我們設(shè)置10個副本，這個常駐服務(wù)就會 啟動10個pod 同時running來提供服務(wù)。
如果 這個服務(wù) 平時流量很少的時候，也是10個pod同時在running，而 流量突然暴增時，又可能出現(xiàn)10個pod不夠用的情況。
針對這樣的場景，k8s有一個組件可以解決這個問題。
Horizontal Pod Autoscaling（POD水平自動伸縮）可以根據(jù)指標(biāo)自動伸縮一個Replication Controller、Deployment 或者Replica Set中的Pod數(shù)量
HPA（Horizontal Pod Autoscaler）是kubernetes（以下簡稱k8s）的一種資源對象，能夠根據(jù)某些指標(biāo)對在statefulSet、replicaController、replicaSet等集合中的pod數(shù)量進行動態(tài)伸縮，使運行在上面的服務(wù)對指標(biāo)的變化有一定的自適應(yīng)能力,實現(xiàn)pod層面的自動伸縮。pod自動縮放不適用于無法縮放的對象，比如DaemonSets。
HPA目前支持四種類型的指標(biāo)，分別是Resource、Object、External、Pods。其中在穩(wěn)定版本autoscaling/v1中只支持對CPU指標(biāo)的動態(tài)伸縮，在測試版本autoscaling/v2beta2中支持memory和自定義指標(biāo)的動態(tài)伸縮，并以annotation的方式工作在autoscaling/v1版本中。
HPA的原理
HPA是根據(jù)指標(biāo)來進行自動伸縮的，目前HPA有兩個版本–v1和v2beta
支持的指標(biāo)
HPA的API有三個版本，通過kubectl api-versions | grep autoscal可看到
autoscaling/v1
autoscaling/v2beta1
autoscaling/v2beta2
autoscaling/v1只支持基于CPU指標(biāo)的縮放；
autoscaling/v2beta1支持Resource Metrics（資源指標(biāo)，如pod的CPU，內(nèi)存）和Custom Metrics（自定義指標(biāo)）的縮放；
autoscaling/v2beta2支持Resource Metrics（資源指標(biāo)，如pod的CPU，內(nèi)存）和Custom Metrics（自定義指標(biāo)）和ExternalMetrics（額外指標(biāo)）的縮放，但是目前也僅僅是處于beta階段
指標(biāo)從哪里來
資源監(jiān)控系統(tǒng)是容器編排系統(tǒng)必不可少的組件，它為用戶提供了快速了解系統(tǒng)資源分配和利用狀態(tài)的有效途徑，同時也是系統(tǒng)編排賴以實現(xiàn)的基礎(chǔ)要件。
老的版本使用Heapster進行集群各項資源指標(biāo)數(shù)據(jù)的采集，從kubernetes1.11開始Heapster被廢棄不在使用，metrics-server 替代了heapster。
K8S從1.8版本開始，CPU、內(nèi)存等資源的metrics信息可以通過 Metrics API來獲取，用戶可以直接獲取這些metrics信息（例如通過執(zhí)行kubect top命令），HPA使用這些metics信息來實現(xiàn)動態(tài)伸縮。
本文介紹K8S集群基于metric server的HPA。在開始之前我們需要了解一下Metrics API和Metrics Server
Metrics API：
1、通過Metrics API我們可以獲取到指定node或者pod的當(dāng)前資源使用情況，API本身不存儲任何信息，所以我們不可能通過API來獲取資源的歷史使用情況。
2、Metrics API的獲取路徑位于：/apis/metrics.k8s.io/
3、獲取Metrics API的前提條件是metrics server要在K8S集群中成功部署
4、更多的metrics資料請參考：https://github.com/kubernetes/metrics
Metrics server：
1、Metrics server是K8S集群資源使用情況的聚合器
2、從1.8版本開始，Metrics server默認(rèn)可以通過kube-up.sh 腳本以deployment的方式進行部署，也可以通過yaml文件的方式進行部署
3、Metrics server收集所有node節(jié)點的metrics信息
HPA如何運作
Horizontal Pod AutoScaler被實現(xiàn)為一個控制循環(huán)，周期由控制器管理器的–Horizontal Pod AutoScaler sync period標(biāo)志（默認(rèn)值為15秒）控制。
在每個期間，控制器管理器都會根據(jù)每個HorizontalPodAutoScaler定義中指定的度量來查詢資源利用率。控制器管理器從資源度量api（針對每個pod的資源度量）或自定義度量api（針對所有其他度量）獲取度量。
對于每個pod的資源度量（如cpu），控制器從horizontalpodautoscaler針對每個pod的資源度量api獲取度量。然后，如果設(shè)置了目標(biāo)利用率值，則控制器將利用率值計算為每個pod中容器上等效資源請求的百分比。如果設(shè)置了目標(biāo)原始值，則直接使用原始度量值。然后，控制器獲取所有目標(biāo)pod的利用率平均值或原始值（取決于指定的目標(biāo)類型），并生成用于縮放所需副本數(shù)量的比率。
HPA自動伸縮的過程:
HPA伸縮過程敘述
HPA的伸縮主要流程如下：
1、判斷當(dāng)前pod數(shù)量是否在HPA設(shè)定的pod數(shù)量區(qū)間中，如果不在，過小返回最小值，過大返回最大值，結(jié)束伸縮。
2、判斷指標(biāo)的類型，并向api server發(fā)送對應(yīng)的請求，拿到設(shè)定的監(jiān)控指標(biāo)。一般來說指標(biāo)會根據(jù)預(yù)先設(shè)定的指標(biāo)從以下三個aggregated APIs中獲取：metrics.k8s.io、custom.metrics.k8s.io、 external.metrics.k8s.io。其中metrics.k8s.io一般由k8s自帶的metrics-server來提供，主要是cpu，memory使用率指標(biāo)，另外兩種需要第三方的adapter來提供。custom.metrics.k8s.io提供自定義指標(biāo)數(shù)據(jù)，一般跟k8s集群有關(guān)，比如跟特定的pod相關(guān)。external.metrics.k8s.io同樣提供自定義指標(biāo)數(shù)據(jù)，但一般跟k8s集群無關(guān)。許多知名的第三方監(jiān)控平臺提供了adapter實現(xiàn)了上述api（如prometheus），可以將監(jiān)控和adapter一同部署在k8s集群中提供服務(wù)，甚至能夠替換原來的metrics-server來提供上述三類api指標(biāo)，達到深度定制監(jiān)控數(shù)據(jù)的目的。
3、根據(jù)獲得的指標(biāo)，應(yīng)用相應(yīng)的算法算出一個伸縮系數(shù)，并乘以目前pod數(shù)量獲得期望pod數(shù)量。系數(shù)是指標(biāo)的期望值與目前值的比值，如果大于1表示擴容，小于1表示縮容。指標(biāo)數(shù)值有平均值（AverageValue）、平均使用率（Utilization）、裸值（Value）三種類型，每種類型的數(shù)值都有對應(yīng)的算法。以下幾點值得注意：如果系數(shù)有小數(shù)點，統(tǒng)一進一；系數(shù)如果未達到某個容忍值，HPA認(rèn)為變化太小，會忽略這次變化，容忍值默認(rèn)為0.1。
HPA擴容算法是一個非常保守的算法。如果出現(xiàn)獲取不到指標(biāo)的情況，擴容時算最小值，縮容時算最大值；如果需要計算平均值，出現(xiàn)pod沒準(zhǔn)備好的情況，平均數(shù)的分母不計入該pod。
一個HPA支持多個指標(biāo)的監(jiān)控，HPA會循環(huán)獲取所有的指標(biāo)，并計算期望的pod數(shù)量，并從期望結(jié)果中獲得最大的pod數(shù)量作為最終的伸縮的pod數(shù)量。一個伸縮對象在k8s中允許對應(yīng)多個HPA，但是只是k8s不會報錯而已，事實上HPA彼此不知道自己監(jiān)控的是同一個伸縮對象，在這個伸縮對象中的pod會被多個HPA無意義地來回修改pod數(shù)量，給系統(tǒng)增加消耗，如果想要指定多個監(jiān)控指標(biāo)，可以如上述所說，在一個HPA中添加多個監(jiān)控指標(biāo)。
4、檢查最終的pod數(shù)量是否在HPA設(shè)定的pod數(shù)量范圍的區(qū)間，如果超過最大值或不足最小值都會修改為最大值或最小值。然后向k8s發(fā)出請求，修改伸縮對象的子對象scale的pod數(shù)量，結(jié)束一個HPA的檢查，獲取下一個HPA，完成一個伸縮流程。
為什么v1正式版本使用的指標(biāo)是 cpu？
v1的模板可能是大家平時見到最多的也是最簡單的，v1版本的HPA只支持一種指標(biāo) —— CPU。傳統(tǒng)意義上，彈性伸縮最少也會支持CPU與Memory兩種指標(biāo)，為什么在Kubernetes中只放開了CPU呢？其實最早的HPA是計劃同時支持這兩種指標(biāo)的，但是實際的開發(fā)測試中發(fā)現(xiàn)，內(nèi)存不是一個非常好的彈性伸縮判斷條件。因為和CPU不同，很多內(nèi)存型的應(yīng)用，并不會因為HPA彈出新的容器而帶來內(nèi)存的快速回收，因為很多應(yīng)用的內(nèi)存都要交給語言層面的VM進行管理，也就是內(nèi)存的回收是由VM的GC來決定的。這就有可能因為GC時間的差異導(dǎo)致HPA在不恰當(dāng)?shù)臅r間點震蕩，因此在v1的版本中，HPA就只支持了CPU一種指標(biāo)。
HPA與rolling update的區(qū)別
目前在kubernetes中，可以通過直接管理復(fù)制控制器來執(zhí)行滾動更新，也可以使用deployment對象來管理底層副本集。HPA只支持后一種方法：HPA綁定到部署對象，設(shè)置部署對象的大小，部署負責(zé)設(shè)置底層副本集的大小。
HPA不能使用復(fù)制控制器的直接操作進行滾動更新，即不能將HPA綁定到復(fù)制控制器并進行滾動更新（例如，使用Kubectl滾動更新）。這不起作用的原因是，當(dāng)滾動更新創(chuàng)建新的復(fù)制控制器時，HPA將不會綁定到新的復(fù)制控制器。
HPA的應(yīng)用場景
HPA的特性結(jié)合第三方的監(jiān)控應(yīng)用，使得部署在HPA伸縮對象（statefulSet、replicaController、replicaSet）上的服務(wù)有了非常靈活的自適應(yīng)能力，能夠在一定限度內(nèi)復(fù)制多個副本來應(yīng)對某個指標(biāo)的急劇飆升，也可以在某個指標(biāo)較小的情況下刪除副本來讓出計算資源給其他更需要資源的應(yīng)用使用，維持整個系統(tǒng)的穩(wěn)定。非常適合于一些流量波動大，機器資源吃緊，服務(wù)數(shù)量多的業(yè)務(wù)場景，如：電商服務(wù)、搶票服務(wù)、金融服務(wù)等。
使用HPA的前提–部署metrics-server
嘗試運行kubectl top命令
Metrics-server正常安裝完成后就可以使用kubectl top命令顯示節(jié)點和pod對象的資源使用信息。
# 顯示各節(jié)點的資源使用信息 # kubectl top nodes NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% master01.dayi123.com 200m 10% 1106Mi 64% node01.dayi123.com 44m 4% 649Mi 46% node02.dayi123.com 84m 4% 929Mi 54% # 顯示符合條件的pod的資源使用信息 # kubectl top pods -n kube-system -l k8s-app=kubernetes-dashboard NAME CPU(cores) MEMORY(bytes) kubernetes-dashboard-76479d66bb-9xhkf 1m 20Mi如果已經(jīng)能夠使用kubectl top命令，則可跳過安裝Metrics-server。
否則可以參考以下步驟安裝:
拉取資源,替換可用鏡像
# git clone https://github.com/kubernetes-incubator/metrics-server# 替換metrics-server/deploy/1.8+/metrics-server-deployment.yaml的鏡像地址為deploy/1.8+/metrics-server-deployment.yaml# sed -i "s#k8s.gcr.io/metrics-server-amd64:v0.3.3#mirrorgooglecontainers/metrics-server-amd64:v0.3.1#g" /tmp/metrics-server/deploy/1.8+/metrics-server-deployment.yaml去除https驗證
由于metrics-server默認(rèn)使用節(jié)點hostname通過kubelet 10250端口獲取數(shù)據(jù)，但是coredns里面沒有該數(shù)據(jù)無法解析，所以可在metrics server啟動命令添加參數(shù) --kubelet-preferred-address-types=InternalIP 直接使用節(jié)點IP地址獲取數(shù)據(jù)；同時由于kubelet 的10250端口使用的是https協(xié)議，連接需要驗證tls證書。可以在metrics server啟動命令添加參數(shù)–kubelet-insecure-tls不驗證客戶端證書。
# 在配置文件metrics-server/deploy/1.8+/metrics-server-deployment.yaml添加啟動參數(shù) command: - /metrics-server - --metric-resolution=30s - --kubelet-insecure-tls - --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP創(chuàng)建資源
# kubectl create -f metrics-server/deploy/1.8+/metrics-server-deployment.yaml serviceaccount/metrics-server created deployment.extensions/metrics-server created驗證metrics-server是否部署成功
kubectl get pods -n kube-system顯示如下running狀態(tài)說明啟動成功
測試kubectl top命令
metrics-server組件安裝成功之后，就可以使用kubectl top命令了
kubectl top nodes 顯示如下： NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% k8s-master 660m 16% 1608Mi 20% k8s-node 348m 8% 1046Mi 28% kubectl top pods -n kube-system 顯示如下： NAME CPU(cores) MEMORY(bytes) calico-node-9wkmr 100m 26Mi calico-node-sp5m6 162m 35Mi coredns-6955765f44-j2xrl 8m 8Mi coredns-6955765f44-th2sb 10m 8Mi etcd-k8s-master 48m 44Mi kube-apiserver-k8s-master 128m 286Mi kube-controller-manager-k8s-master 79m 38Mi kube-proxy-9s48h 2m 17Mi kube-proxy-vcx2s 2m 10Mi kube-scheduler-k8s-master 12m 15Mi metrics-server-5cf9669fbf-jmrdx 3m 17Mi通過api驗證metrics-server可用方式
# 讓metrics api可訪問 # kubectl proxy --port=8080 Starting to serve on 127.0.0.1:8080另開一個窗口檢查node節(jié)點可用性
# curl http://localhost:8080/apis/metrics.k8s.io/v1beta1/nodes {"kind": "NodeMetricsList","apiVersion": "metrics.k8s.io/v1beta1","metadata": {"selfLink": "/apis/metrics.k8s.io/v1beta1/nodes"},"items": [{"metadata": {"name": "master01.dayi123.com","selfLink": "/apis/metrics.k8s.io/v1beta1/nodes/master01.dayi123.com","creationTimestamp": "2019-06-13T11:02:57Z"},"timestamp": "2019-06-13T11:03:19Z","window": "30s","usage": {"cpu": "222451436n","memory": "1129748Ki"}獲取集群上所有pod對象的相關(guān)資源消耗數(shù)據(jù)
# curl http://localhost:8080/apis/metrics.k8s.io/v1beta1/pods給我們的服務(wù)加上HPA部署—以nginx為例
需要注意:部署pod時候要設(shè)置資源requests
使用HPA–v1版本控制器
HPA v1 只支持根據(jù)cpu來進行自動伸縮，使用的方式也很簡單，不需要修改服務(wù)本身的yaml
使用命令如下:
# 先創(chuàng)建一個deployment控制器 # kubectl run mynginx --image=nginx:1.12 --replicas=2 --requests='cpu=5m,memory=128Mi' --limits='cpu=50m,memory=128Mi' --labels='app=mynginx' --expose --port=80# 或者使用yaml 進行創(chuàng)建 kubectl create -f mynginx.yaml# 創(chuàng)建HPA控制器自動管控Pod副本 # kubectl autoscale deploy mynginx --min=2 --max=5 --cpu-percent=60# 驗證HPA是否創(chuàng)建成功 # kubectl get hpa參數(shù)解釋:
–cpu-percent=60（表示cpu使用率不超過60%,出現(xiàn)cpu超過60%時則進行自動伸縮）
–min=2（最少兩個pod）
–max=5（最多5個pod）
使用HPA–v2版本控制器
測試HPA autoscaling/v2beta1版本-基于內(nèi)存的自動擴縮容
創(chuàng)建一個nginx的Deployment
vi nginx.yaml內(nèi)容如下:
apiVersion:apps/v1 kind: Deployment metadata:name:nginx-hpa spec:selector:matchLabels:app: nginxreplicas: 1template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.9.1ports:- containerPort: 80name: httpprotocol: TCPresources:requests:cpu: 0.01memory: 25Milimits:cpu: 0.05memory: 60Mi --- apiVersion: v1 kind: Service metadata:name: nginxlabels:app: nginx spec:selector:app: nginxtype: NodePortports:- name: httpprotocol: TCPport: 80targetPort: 80nodePort: 30080創(chuàng)建nginx
kubectl apply -f nginx.yaml驗證nginx是否運行
kubectl get pods顯示如下，說明nginx的pod正常運行：
NAME READY STATUS RESTARTS AGE nginx-hpa-bb598885d-j4kcp 1/1 Running 0 17m注意：nginx的pod里需要有如下字段，否則hpa會采集不到內(nèi)存指標(biāo)
resources:requests:cpu: 0.01memory: 25Milimits:cpu: 0.05memory: 60Mi創(chuàng)建一個hpa
創(chuàng)建yaml
vi hpa-v2.yaml內(nèi)容如下:
apiVersion: autoscaling/v2beta1 kind: HorizontalPodAutoscaler metadata:name: nginx-hpa spec:maxReplicas: 10minReplicas: 1scaleTargetRef:apiVersion:apps/v1kind: Deploymentname: nginx-hpametrics:- type: Resourceresource:name: cputargetAverageUtilization: 50- type: Resourceresource:name: memorytargetAverageUtilization: 60官方完整yaml示例如下:
apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata:name: php-apachenamespace: default spec:# HPA的伸縮對象描述，HPA會動態(tài)修改該對象的pod數(shù)量scaleTargetRef:apiVersion: apps/v1kind: Deploymentname: php-apache# HPA的最小pod數(shù)量和最大pod數(shù)量minReplicas: 1maxReplicas: 10# 監(jiān)控的指標(biāo)數(shù)組，支持多種類型的指標(biāo)共存metrics:# Object類型的指標(biāo)- type: Objectobject:metric:# 指標(biāo)名稱name: requests-per-second# 監(jiān)控指標(biāo)的對象描述，指標(biāo)數(shù)據(jù)來源于該對象describedObject:apiVersion: networking.k8s.io/v1beta1kind: Ingressname: main-route# Value類型的目標(biāo)值，Object類型的指標(biāo)只支持Value和AverageValue類型的目標(biāo)值target:type: Valuevalue: 10k# Resource類型的指標(biāo)- type: Resourceresource:name: cpu# Utilization類型的目標(biāo)值，Resource類型的指標(biāo)只支持Utilization和AverageValue類型的目標(biāo)值target:type: UtilizationaverageUtilization: 50# Pods類型的指標(biāo)- type: Podspods:metric:name: packets-per-second# AverageValue類型的目標(biāo)值，Pods指標(biāo)類型下只支持AverageValue類型的目標(biāo)值target:type: AverageValueaverageValue: 1k# External類型的指標(biāo)- type: Externalexternal:metric:name: queue_messages_ready# 該字段與第三方的指標(biāo)標(biāo)簽相關(guān)聯(lián)，（此處官方文檔有問題，正確的寫法如下）selector:matchLabels:env: "stage"app: "myapp"# External指標(biāo)類型下只支持Value和AverageValue類型的目標(biāo)值target:type: AverageValueaverageValue: 30參數(shù)解釋:
spec中嵌套的個字段的說明如下：
（1）maxReplicas：自動伸縮可擴展至Pod副本數(shù)的上限
（2）minReplicas：自動伸縮pod副本數(shù)下限
（3）scaleTargetRef：要伸縮的目標(biāo)資源
（4）metrics：用于計算所需的Pod副本數(shù)量的指標(biāo)列表
（5）external：用于應(yīng)用非附屬于任何對象的全局指標(biāo)
（6）object：應(yīng)用描述集群中某單一對象的特定指標(biāo)
（7）pods：應(yīng)用被彈性伸縮的pod對象的特定指標(biāo)
（8）resource：應(yīng)用資源指標(biāo)，即當(dāng)前被彈性伸縮的pod對象中容器的requests和limits中定義的指標(biāo)。
（9）type：標(biāo)識指標(biāo)源的類型
創(chuàng)建hpa
kubectl apply -f hpa-v2.yaml查看創(chuàng)建狀態(tài)
kubectl get hpa顯示如下：
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE nginx-hpa Deployment/nginx-hpa 5%/60% 1 10 1 20s壓測nginx的內(nèi)存，hpa會對pod自動擴縮容
登錄到上面通過pod創(chuàng)建的nginx，并生成一個文件，增加內(nèi)存
kubectl exec -it nginx-hpa-bb598885d-j4kcp – /bin/sh
在pod中使用命令進行壓測：
ddif=/dev/zero of=/tmp/a打開新的終端：
kubectl get hpa顯示如下：
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE nginx-hpa Deployment/nginx-hpa 200%/60% 1 10 3 12m上面的targets列可看到200%/60%，200%表示當(dāng)前cpu使用率，60%表示所有pod的cpu使用率維持在60%，現(xiàn)在cpu使用率達到200%，所以pod增加到4個
kubectl get deployment顯示如下：
NAME READY UP-TO-DATE AVAILABLE AGE nginx-hpa 4/4 4 4 25m取消對nginx內(nèi)存的壓測，hpa會對pod自動縮容
kubectl exec -it nginx-hpa-bb598885d-j4kcp -- /bin/sh刪除/tmp/a這個文件
rm -rf /tmp/a在新終端中使用命令
kubectl get hpa顯示如下,可看到內(nèi)存使用率已經(jīng)降到5%:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE nginx-hpa Deployment/nginx-hpa 5%/60% 1 10 1 26m查看deployment
kubectl get deployment顯示如下，deployment的pod又恢復(fù)到1個了：
NAME READY UP-TO-DATE AVAILABLE AGE nginx-hpa 1/1 1 1 38m基于多項指標(biāo)和自定義指標(biāo)的自動縮放
可以通過使用autoscaling/v2beta2 API版本 來創(chuàng)建 根據(jù) 其他度量指標(biāo)（metrics）進行自動伸縮的deployment。
使用yaml如下:
apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata:name: php-apachenamespace:default spec:scaleTargetRef:apiVersion: apps/v1kind: Deploymentname: php-apacheminReplicas: 1maxReplicas: 10metrics:- type: Resourceresource:name: cputarget:type: UtilizationaverageUtilization: 50 status:observedGeneration: 1lastScaleTime: <some-time>currentReplicas: 1desiredReplicas: 1currentMetrics:- type: Resourceresource:name: cpucurrent:averageUtilization: 0averageValue: 0targetCPUUtilizationPercentage字段由metrics所取代，CPU利用率這個度量指標(biāo)是一個resource metric(資源度量指標(biāo))，因為它表示容器上指定資源的百分比。
除CPU外，你還可以指定其他資源度量指標(biāo)。
默認(rèn)情況下，目前唯一支持的其他資源度量指標(biāo)為內(nèi)存。
只要metrics.k8s.io API存在，這些資源度量指標(biāo)就是可用的，并且他們不會在不同的Kubernetes集群中改變名稱。
你還可以指定資源度量指標(biāo)使用絕對數(shù)值，而不是百分比，你需要將target類型AverageUtilization替換成AverageValue，同時將target.averageUtilization替換成target.averageValue并設(shè)定相應(yīng)的值。
還有兩種其他類型的度量指標(biāo)，他們被認(rèn)為是custom metrics（自定義度量指標(biāo)）： 即Pod度量指標(biāo)和對象度量指標(biāo)（pod metrics and object metrics）。
這些度量指標(biāo)可能具有特定于集群的名稱，并且需要更高級的集群監(jiān)控設(shè)置。
使用度量指標(biāo)類型—Pod度量指標(biāo)
第一種可選的度量指標(biāo)類型是Pod度量指標(biāo)。這些指標(biāo)從某一方面描述了Pod，在不同Pod之間進行平均，并通過與一個目標(biāo)值比對來確定副本的數(shù)量。
它們的工作方式與資源度量指標(biāo)非常相像，差別是它們僅支持target類型為AverageValue。
Pod 度量指標(biāo)通過如下代碼塊定義
type: Pods pods:metric:name: packets-per-secondtarget:type: AverageValueaverageValue: 1k使用度量指標(biāo)類型—對象度量指標(biāo)
第二種可選的度量指標(biāo)類型是對象度量指標(biāo)。
相對于描述Pod，這些度量指標(biāo)用于描述一個在相同名字空間(namespace)中的其他對象。
請注意這些度量指標(biāo)用于描述這些對象，并非從對象中獲取。
對象度量指標(biāo)支持的target類型包括Value和AverageValue。
如果是Value類型，target值將直接與API返回的度量指標(biāo)比較，而AverageValue類型，API返回的度量指標(biāo)將按照Pod數(shù)量拆分，然后再與target值比較。
下面的YAML文件展示了一個表示requests-per-second的度量指標(biāo)。
type: Object object:metric:name: requests-per-seconddescribedObject:apiVersion: networking.k8s.io/v1beta1kind: Ingressname: main-routetarget:type: Valuevalue: 2k如果你指定了多個上述類型的度量指標(biāo)，HorizontalPodAutoscaler將會依次考量各個指標(biāo)
HorizontalPodAutoscaler將會計算每一個指標(biāo)所提議的副本數(shù)量，然后最終選擇一個最高值。
比如，如果你的監(jiān)控系統(tǒng)能夠提供網(wǎng)絡(luò)流量數(shù)據(jù)，你可以通過kubectl edit命令將上述Horizontal Pod Autoscaler的定義更改為：
apiVersion: autoscaling/v2beta1 kind: HorizontalPodAutoscaler metadata:name: php-apachenamespace:default spec:scaleTargetRef:apiVersion: apps/v1kind: Deploymentname: php-apacheminReplicas: 1maxReplicas: 10metrics:- type: Resourceresource:name: cputarget:type: AverageUtilizationaverageUtilization: 50- type: Podspods:metric:name: packets-per-secondtargetAverageValue: 1k- type: Objectobject:metric:name: requests-per-seconddescribedObject:apiVersion: networking.k8s.io/v1beta1kind: Ingressname: main-routetarget:kind: Valuevalue: 10k status:observedGeneration: 1lastScaleTime: <some-time>currentReplicas: 1desiredReplicas: 1currentMetrics:- type: Resourceresource:name: cpucurrent:averageUtilization: 0averageValue: 0- type: Objectobject:metric:name: requests-per-seconddescribedObject:apiVersion: networking.k8s.io/v1beta1kind: Ingressname: main-routecurrent:value: 10k然后，你的HorizontalPodAutoscaler將會嘗試確保每個Pod的CPU利用率在50%以內(nèi)，每秒能夠服務(wù)1000個數(shù)據(jù)包請求，并確保所有在Ingress后的Pod每秒能夠服務(wù)的請求總數(shù)達到10000個。
在更多指定指標(biāo)下的自動伸縮
許多度量管道允許你通過名稱或附加的_labels_來描述度量指標(biāo)。
對于所有非資源類型度量指標(biāo)(pod、object和后面將介紹的external)，可以額外指定一個標(biāo)簽選擇器。
例如，如果你希望收集包含verb標(biāo)簽的http_requests度量指標(biāo)， 你可以在GET請求中指定需要的度量指標(biāo)，如下所示：
type:Object object:metric:name:`http_requests`selector:`verb=GET`這個選擇器使用與Kubernetes標(biāo)簽選擇器相同的語法。如果名稱和標(biāo)簽選擇器匹配到多個系列，監(jiān)測管道會決定如何將多個系列合并成單個值。選擇器是附加的，它不會選擇目標(biāo)以外的對象（類型為Pods的目標(biāo)和類型為Object的目標(biāo)）。
基于kubernetes對象以外的度量指標(biāo)自動擴縮容
運行在Kubernetes上的應(yīng)用程序可能需要基于與Kubernetes集群中的任何對象沒有明顯關(guān)系的度量指標(biāo)進行自動伸縮，例如那些描述不在Kubernetes任何namespaces服務(wù)的度量指標(biāo)。
使用外部的度量指標(biāo)，需要了解你使用的監(jiān)控系統(tǒng)，相關(guān)的設(shè)置與使用自定義指標(biāo)類似。
External metrics可以使用你的監(jiān)控系統(tǒng)的任何指標(biāo)來自動伸縮你的集群。
你只需要在metric塊中提供name和selector，同時將類型由Object改為External。
如果metricSelector匹配到多個度量指標(biāo)，HorizontalPodAutoscaler將會把它們加和。
External metrics同時支持Value和AverageValue類型，這與Object類型的度量指標(biāo)相同。
例如，如果你的應(yīng)用程序處理主機上的消息隊列， 為了讓每30個任務(wù)有1個worker，你可以將下面的內(nèi)容添加到 HorizontalPodAutoscaler 的配置中。
-type:Externalexternal:metric:name:queue_messages_readyselector:"queue=worker_tasks"target:type:AverageValueaverageValue:30還是推薦custom metric而不是external metrics，因為這便于讓系統(tǒng)管理員加固custom metrics API。而external metrics API可以允許訪問所有的度量指標(biāo)，當(dāng)暴露這些服務(wù)時，系統(tǒng)管理員需要仔細考慮這個問題。
HPA常用命令
kubectl get hpakubectl describe hpa tomcat-shopxx-hpa關(guān)于HPA的思考
在某些熱點新聞的高流量下2分鐘內(nèi)就需要擴容上千臺機器，k8s 默認(rèn)的彈性擴容是解決不了這個問題的 (因為默認(rèn)的調(diào)度機制是串行的，需要做 hack 才可以)。
之前螞蟻的人介紹他們的雙十一架構(gòu)，可以很短的時間擴容幾千個機器，怎么做到的呢？ 把 k8s 默認(rèn)的調(diào)度算法從原來的順序的調(diào)度改為了批量的調(diào)度，滿足了這個大促的場景。
另外最重要的一點是如何判斷觸發(fā)擴容縮容的時機，今天從網(wǎng)上的一個 2015 年的論文里找到了一個方法論，介紹了如何用工業(yè)界的 質(zhì)量控制圖 和 區(qū)間法則找出了異常的數(shù)據(jù)波段，并進行擴容或縮容。大體上微博的做法也和這個類似，因此了解下這個論文還是很有幫助的。
總之，k8s HPA 的這個功能只能處理非常簡單的場景，距離真正線上應(yīng)用使用還很遙遠，而且這個功能和 k8s 平臺關(guān)系不大，應(yīng)該在非 k8s 環(huán)境下就要能夠做到甄別出應(yīng)用的異常流量。
參考鏈接
https://www.jianshu.com/p/7842437235f2
https://zhuanlan.zhihu.com/p/89453704
https://blog.csdn.net/textdemo123/article/details/100654364
https://www.cnblogs.com/zjz20/p/13397668.html
總結(jié)
以上是生活随笔為你收集整理的Kubernetes--k8s--进阶--全面了解HPA--部署HPA实现高可用和成本控制的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 品优购商城——列表页
- 下一篇： P2P对等网络技术原理整合