Kubernetes--k8s--进阶--全面了解HPA--部署HPA实现高可用和成本控制
什么是HPA
我們的k8s集群 如果是 針對node層面是有Cluster Autoscaler彈性伸縮來做高可用和成本控制的優化的。
也就是說 我們一開始 沒有pod任務在運行的時候 不需要node節點時，k8s的集群可以只啟動少量node節點來做常駐服務pod的部署。 當 有大批量的任務pod 需要運行時， k8s集群會根據 每個pod需要的資源狀態來 申請啟動新的node節點。 當任務高峰期過后，pod運行的數量減少，node的數量就會收縮，不使用的node會被回收，保證 k8s集群的高可用低成本運行。
那么問題來了，常駐服務用來提供給外部的pod又怎么實現高可用呢？ 我們一般會使用Deployment中的replicas參數，設置多個副本集來保證 服務的高可用，但是 這是一個固定的值，比如 我們設置10個副本，這個常駐服務就會 啟動10個pod 同時running來提供服務。
如果 這個服務 平時流量很少的時候，也是10個pod同時在running，而 流量突然暴增時，又可能出現10個pod不夠用的情況。
針對這樣的場景，k8s有一個組件可以解決這個問題。
Horizontal Pod Autoscaling（POD水平自動伸縮）可以根據指標自動伸縮一個Replication Controller、Deployment 或者Replica Set中的Pod數量
HPA（Horizontal Pod Autoscaler）是kubernetes（以下簡稱k8s）的一種資源對象，能夠根據某些指標對在statefulSet、replicaController、replicaSet等集合中的pod數量進行動態伸縮，使運行在上面的服務對指標的變化有一定的自適應能力,實現pod層面的自動伸縮。pod自動縮放不適用于無法縮放的對象，比如DaemonSets。
HPA目前支持四種類型的指標，分別是Resource、Object、External、Pods。其中在穩定版本autoscaling/v1中只支持對CPU指標的動態伸縮，在測試版本autoscaling/v2beta2中支持memory和自定義指標的動態伸縮，并以annotation的方式工作在autoscaling/v1版本中。
HPA的原理
HPA是根據指標來進行自動伸縮的，目前HPA有兩個版本–v1和v2beta
支持的指標
HPA的API有三個版本，通過kubectl api-versions | grep autoscal可看到
autoscaling/v1
autoscaling/v2beta1
autoscaling/v2beta2
autoscaling/v1只支持基于CPU指標的縮放；
autoscaling/v2beta1支持Resource Metrics（資源指標，如pod的CPU，內存）和Custom Metrics（自定義指標）的縮放；
autoscaling/v2beta2支持Resource Metrics（資源指標，如pod的CPU，內存）和Custom Metrics（自定義指標）和ExternalMetrics（額外指標）的縮放，但是目前也僅僅是處于beta階段
指標從哪里來
資源監控系統是容器編排系統必不可少的組件，它為用戶提供了快速了解系統資源分配和利用狀態的有效途徑，同時也是系統編排賴以實現的基礎要件。
老的版本使用Heapster進行集群各項資源指標數據的采集，從kubernetes1.11開始Heapster被廢棄不在使用，metrics-server 替代了heapster。
K8S從1.8版本開始，CPU、內存等資源的metrics信息可以通過 Metrics API來獲取，用戶可以直接獲取這些metrics信息（例如通過執行kubect top命令），HPA使用這些metics信息來實現動態伸縮。
本文介紹K8S集群基于metric server的HPA。在開始之前我們需要了解一下Metrics API和Metrics Server
Metrics API：
1、通過Metrics API我們可以獲取到指定node或者pod的當前資源使用情況，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默認可以通過kube-up.sh 腳本以deployment的方式進行部署，也可以通過yaml文件的方式進行部署
3、Metrics server收集所有node節點的metrics信息
HPA如何運作
Horizontal Pod AutoScaler被實現為一個控制循環，周期由控制器管理器的–Horizontal Pod AutoScaler sync period標志（默認值為15秒）控制。
在每個期間，控制器管理器都會根據每個HorizontalPodAutoScaler定義中指定的度量來查詢資源利用率。控制器管理器從資源度量api（針對每個pod的資源度量）或自定義度量api（針對所有其他度量）獲取度量。
對于每個pod的資源度量（如cpu），控制器從horizontalpodautoscaler針對每個pod的資源度量api獲取度量。然后，如果設置了目標利用率值，則控制器將利用率值計算為每個pod中容器上等效資源請求的百分比。如果設置了目標原始值，則直接使用原始度量值。然后，控制器獲取所有目標pod的利用率平均值或原始值（取決于指定的目標類型），并生成用于縮放所需副本數量的比率。
HPA自動伸縮的過程:
HPA伸縮過程敘述
HPA的伸縮主要流程如下：
1、判斷當前pod數量是否在HPA設定的pod數量區間中，如果不在，過小返回最小值，過大返回最大值，結束伸縮。
2、判斷指標的類型，并向api server發送對應的請求，拿到設定的監控指標。一般來說指標會根據預先設定的指標從以下三個aggregated APIs中獲取：metrics.k8s.io、custom.metrics.k8s.io、 external.metrics.k8s.io。其中metrics.k8s.io一般由k8s自帶的metrics-server來提供，主要是cpu，memory使用率指標，另外兩種需要第三方的adapter來提供。custom.metrics.k8s.io提供自定義指標數據，一般跟k8s集群有關，比如跟特定的pod相關。external.metrics.k8s.io同樣提供自定義指標數據，但一般跟k8s集群無關。許多知名的第三方監控平臺提供了adapter實現了上述api（如prometheus），可以將監控和adapter一同部署在k8s集群中提供服務，甚至能夠替換原來的metrics-server來提供上述三類api指標，達到深度定制監控數據的目的。
3、根據獲得的指標，應用相應的算法算出一個伸縮系數，并乘以目前pod數量獲得期望pod數量。系數是指標的期望值與目前值的比值，如果大于1表示擴容，小于1表示縮容。指標數值有平均值（AverageValue）、平均使用率（Utilization）、裸值（Value）三種類型，每種類型的數值都有對應的算法。以下幾點值得注意：如果系數有小數點，統一進一；系數如果未達到某個容忍值，HPA認為變化太小，會忽略這次變化，容忍值默認為0.1。
HPA擴容算法是一個非常保守的算法。如果出現獲取不到指標的情況，擴容時算最小值，縮容時算最大值；如果需要計算平均值，出現pod沒準備好的情況，平均數的分母不計入該pod。
一個HPA支持多個指標的監控，HPA會循環獲取所有的指標，并計算期望的pod數量，并從期望結果中獲得最大的pod數量作為最終的伸縮的pod數量。一個伸縮對象在k8s中允許對應多個HPA，但是只是k8s不會報錯而已，事實上HPA彼此不知道自己監控的是同一個伸縮對象，在這個伸縮對象中的pod會被多個HPA無意義地來回修改pod數量，給系統增加消耗，如果想要指定多個監控指標，可以如上述所說，在一個HPA中添加多個監控指標。
4、檢查最終的pod數量是否在HPA設定的pod數量范圍的區間，如果超過最大值或不足最小值都會修改為最大值或最小值。然后向k8s發出請求，修改伸縮對象的子對象scale的pod數量，結束一個HPA的檢查，獲取下一個HPA，完成一個伸縮流程。
為什么v1正式版本使用的指標是 cpu？
v1的模板可能是大家平時見到最多的也是最簡單的，v1版本的HPA只支持一種指標 —— CPU。傳統意義上，彈性伸縮最少也會支持CPU與Memory兩種指標，為什么在Kubernetes中只放開了CPU呢？其實最早的HPA是計劃同時支持這兩種指標的，但是實際的開發測試中發現，內存不是一個非常好的彈性伸縮判斷條件。因為和CPU不同，很多內存型的應用，并不會因為HPA彈出新的容器而帶來內存的快速回收，因為很多應用的內存都要交給語言層面的VM進行管理，也就是內存的回收是由VM的GC來決定的。這就有可能因為GC時間的差異導致HPA在不恰當的時間點震蕩，因此在v1的版本中，HPA就只支持了CPU一種指標。
HPA與rolling update的區別
目前在kubernetes中，可以通過直接管理復制控制器來執行滾動更新，也可以使用deployment對象來管理底層副本集。HPA只支持后一種方法：HPA綁定到部署對象，設置部署對象的大小，部署負責設置底層副本集的大小。
HPA不能使用復制控制器的直接操作進行滾動更新，即不能將HPA綁定到復制控制器并進行滾動更新（例如，使用Kubectl滾動更新）。這不起作用的原因是，當滾動更新創建新的復制控制器時，HPA將不會綁定到新的復制控制器。
HPA的應用場景
HPA的特性結合第三方的監控應用，使得部署在HPA伸縮對象（statefulSet、replicaController、replicaSet）上的服務有了非常靈活的自適應能力，能夠在一定限度內復制多個副本來應對某個指標的急劇飆升，也可以在某個指標較小的情況下刪除副本來讓出計算資源給其他更需要資源的應用使用，維持整個系統的穩定。非常適合于一些流量波動大，機器資源吃緊，服務數量多的業務場景，如：電商服務、搶票服務、金融服務等。
使用HPA的前提–部署metrics-server
嘗試運行kubectl top命令
Metrics-server正常安裝完成后就可以使用kubectl top命令顯示節點和pod對象的資源使用信息。
# 顯示各節點的資源使用信息 # 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如果已經能夠使用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默認使用節點hostname通過kubelet 10250端口獲取數據，但是coredns里面沒有該數據無法解析，所以可在metrics server啟動命令添加參數 --kubelet-preferred-address-types=InternalIP 直接使用節點IP地址獲取數據；同時由于kubelet 的10250端口使用的是https協議，連接需要驗證tls證書。可以在metrics server啟動命令添加參數–kubelet-insecure-tls不驗證客戶端證書。
# 在配置文件metrics-server/deploy/1.8+/metrics-server-deployment.yaml添加啟動參數 command: - /metrics-server - --metric-resolution=30s - --kubelet-insecure-tls - --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP創建資源
# 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狀態說明啟動成功
測試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節點可用性
# 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對象的相關資源消耗數據
# curl http://localhost:8080/apis/metrics.k8s.io/v1beta1/pods給我們的服務加上HPA部署—以nginx為例
需要注意:部署pod時候要設置資源requests
使用HPA–v1版本控制器
HPA v1 只支持根據cpu來進行自動伸縮，使用的方式也很簡單，不需要修改服務本身的yaml
使用命令如下:
# 先創建一個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 進行創建 kubectl create -f mynginx.yaml# 創建HPA控制器自動管控Pod副本 # kubectl autoscale deploy mynginx --min=2 --max=5 --cpu-percent=60# 驗證HPA是否創建成功 # kubectl get hpa參數解釋:
–cpu-percent=60（表示cpu使用率不超過60%,出現cpu超過60%時則進行自動伸縮）
–min=2（最少兩個pod）
–max=5（最多5個pod）
使用HPA–v2版本控制器
測試HPA autoscaling/v2beta1版本-基于內存的自動擴縮容
創建一個nginx的Deployment
vi nginx.yaml內容如下:
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創建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會采集不到內存指標
resources:requests:cpu: 0.01memory: 25Milimits:cpu: 0.05memory: 60Mi創建一個hpa
創建yaml
vi hpa-v2.yaml內容如下:
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會動態修改該對象的pod數量scaleTargetRef:apiVersion: apps/v1kind: Deploymentname: php-apache# HPA的最小pod數量和最大pod數量minReplicas: 1maxReplicas: 10# 監控的指標數組，支持多種類型的指標共存metrics:# Object類型的指標- type: Objectobject:metric:# 指標名稱name: requests-per-second# 監控指標的對象描述，指標數據來源于該對象describedObject:apiVersion: networking.k8s.io/v1beta1kind: Ingressname: main-route# Value類型的目標值，Object類型的指標只支持Value和AverageValue類型的目標值target:type: Valuevalue: 10k# Resource類型的指標- type: Resourceresource:name: cpu# Utilization類型的目標值，Resource類型的指標只支持Utilization和AverageValue類型的目標值target:type: UtilizationaverageUtilization: 50# Pods類型的指標- type: Podspods:metric:name: packets-per-second# AverageValue類型的目標值，Pods指標類型下只支持AverageValue類型的目標值target:type: AverageValueaverageValue: 1k# External類型的指標- type: Externalexternal:metric:name: queue_messages_ready# 該字段與第三方的指標標簽相關聯，（此處官方文檔有問題，正確的寫法如下）selector:matchLabels:env: "stage"app: "myapp"# External指標類型下只支持Value和AverageValue類型的目標值target:type: AverageValueaverageValue: 30參數解釋:
spec中嵌套的個字段的說明如下：
（1）maxReplicas：自動伸縮可擴展至Pod副本數的上限
（2）minReplicas：自動伸縮pod副本數下限
（3）scaleTargetRef：要伸縮的目標資源
（4）metrics：用于計算所需的Pod副本數量的指標列表
（5）external：用于應用非附屬于任何對象的全局指標
（6）object：應用描述集群中某單一對象的特定指標
（7）pods：應用被彈性伸縮的pod對象的特定指標
（8）resource：應用資源指標，即當前被彈性伸縮的pod對象中容器的requests和limits中定義的指標。
（9）type：標識指標源的類型
創建hpa
kubectl apply -f hpa-v2.yaml查看創建狀態
kubectl get hpa顯示如下：
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE nginx-hpa Deployment/nginx-hpa 5%/60% 1 10 1 20s壓測nginx的內存，hpa會對pod自動擴縮容
登錄到上面通過pod創建的nginx，并生成一個文件，增加內存
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%表示當前cpu使用率，60%表示所有pod的cpu使用率維持在60%，現在cpu使用率達到200%，所以pod增加到4個
kubectl get deployment顯示如下：
NAME READY UP-TO-DATE AVAILABLE AGE nginx-hpa 4/4 4 4 25m取消對nginx內存的壓測，hpa會對pod自動縮容
kubectl exec -it nginx-hpa-bb598885d-j4kcp -- /bin/sh刪除/tmp/a這個文件
rm -rf /tmp/a在新終端中使用命令
kubectl get hpa顯示如下,可看到內存使用率已經降到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又恢復到1個了：
NAME READY UP-TO-DATE AVAILABLE AGE nginx-hpa 1/1 1 1 38m基于多項指標和自定義指標的自動縮放
可以通過使用autoscaling/v2beta2 API版本 來創建 根據 其他度量指標（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利用率這個度量指標是一個resource metric(資源度量指標)，因為它表示容器上指定資源的百分比。
除CPU外，你還可以指定其他資源度量指標。
默認情況下，目前唯一支持的其他資源度量指標為內存。
只要metrics.k8s.io API存在，這些資源度量指標就是可用的，并且他們不會在不同的Kubernetes集群中改變名稱。
你還可以指定資源度量指標使用絕對數值，而不是百分比，你需要將target類型AverageUtilization替換成AverageValue，同時將target.averageUtilization替換成target.averageValue并設定相應的值。
還有兩種其他類型的度量指標，他們被認為是custom metrics（自定義度量指標）： 即Pod度量指標和對象度量指標（pod metrics and object metrics）。
這些度量指標可能具有特定于集群的名稱，并且需要更高級的集群監控設置。
使用度量指標類型—Pod度量指標
第一種可選的度量指標類型是Pod度量指標。這些指標從某一方面描述了Pod，在不同Pod之間進行平均，并通過與一個目標值比對來確定副本的數量。
它們的工作方式與資源度量指標非常相像，差別是它們僅支持target類型為AverageValue。
Pod 度量指標通過如下代碼塊定義
type: Pods pods:metric:name: packets-per-secondtarget:type: AverageValueaverageValue: 1k使用度量指標類型—對象度量指標
第二種可選的度量指標類型是對象度量指標。
相對于描述Pod，這些度量指標用于描述一個在相同名字空間(namespace)中的其他對象。
請注意這些度量指標用于描述這些對象，并非從對象中獲取。
對象度量指標支持的target類型包括Value和AverageValue。
如果是Value類型，target值將直接與API返回的度量指標比較，而AverageValue類型，API返回的度量指標將按照Pod數量拆分，然后再與target值比較。
下面的YAML文件展示了一個表示requests-per-second的度量指標。
type: Object object:metric:name: requests-per-seconddescribedObject:apiVersion: networking.k8s.io/v1beta1kind: Ingressname: main-routetarget:type: Valuevalue: 2k如果你指定了多個上述類型的度量指標，HorizontalPodAutoscaler將會依次考量各個指標
HorizontalPodAutoscaler將會計算每一個指標所提議的副本數量，然后最終選擇一個最高值。
比如，如果你的監控系統能夠提供網絡流量數據，你可以通過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%以內，每秒能夠服務1000個數據包請求，并確保所有在Ingress后的Pod每秒能夠服務的請求總數達到10000個。
在更多指定指標下的自動伸縮
許多度量管道允許你通過名稱或附加的_labels_來描述度量指標。
對于所有非資源類型度量指標(pod、object和后面將介紹的external)，可以額外指定一個標簽選擇器。
例如，如果你希望收集包含verb標簽的http_requests度量指標， 你可以在GET請求中指定需要的度量指標，如下所示：
type:Object object:metric:name:`http_requests`selector:`verb=GET`這個選擇器使用與Kubernetes標簽選擇器相同的語法。如果名稱和標簽選擇器匹配到多個系列，監測管道會決定如何將多個系列合并成單個值。選擇器是附加的，它不會選擇目標以外的對象（類型為Pods的目標和類型為Object的目標）。
基于kubernetes對象以外的度量指標自動擴縮容
運行在Kubernetes上的應用程序可能需要基于與Kubernetes集群中的任何對象沒有明顯關系的度量指標進行自動伸縮，例如那些描述不在Kubernetes任何namespaces服務的度量指標。
使用外部的度量指標，需要了解你使用的監控系統，相關的設置與使用自定義指標類似。
External metrics可以使用你的監控系統的任何指標來自動伸縮你的集群。
你只需要在metric塊中提供name和selector，同時將類型由Object改為External。
如果metricSelector匹配到多個度量指標，HorizontalPodAutoscaler將會把它們加和。
External metrics同時支持Value和AverageValue類型，這與Object類型的度量指標相同。
例如，如果你的應用程序處理主機上的消息隊列， 為了讓每30個任務有1個worker，你可以將下面的內容添加到 HorizontalPodAutoscaler 的配置中。
-type:Externalexternal:metric:name:queue_messages_readyselector:"queue=worker_tasks"target:type:AverageValueaverageValue:30還是推薦custom metric而不是external metrics，因為這便于讓系統管理員加固custom metrics API。而external metrics API可以允許訪問所有的度量指標，當暴露這些服務時，系統管理員需要仔細考慮這個問題。
HPA常用命令
kubectl get hpakubectl describe hpa tomcat-shopxx-hpa關于HPA的思考
在某些熱點新聞的高流量下2分鐘內就需要擴容上千臺機器，k8s 默認的彈性擴容是解決不了這個問題的 (因為默認的調度機制是串行的，需要做 hack 才可以)。
之前螞蟻的人介紹他們的雙十一架構，可以很短的時間擴容幾千個機器，怎么做到的呢？ 把 k8s 默認的調度算法從原來的順序的調度改為了批量的調度，滿足了這個大促的場景。
另外最重要的一點是如何判斷觸發擴容縮容的時機，今天從網上的一個 2015 年的論文里找到了一個方法論，介紹了如何用工業界的 質量控制圖 和 區間法則找出了異常的數據波段，并進行擴容或縮容。大體上微博的做法也和這個類似，因此了解下這個論文還是很有幫助的。
總之，k8s HPA 的這個功能只能處理非常簡單的場景，距離真正線上應用使用還很遙遠，而且這個功能和 k8s 平臺關系不大，應該在非 k8s 環境下就要能夠做到甄別出應用的異常流量。
參考鏈接
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
總結
以上是生活随笔為你收集整理的Kubernetes--k8s--进阶--全面了解HPA--部署HPA实现高可用和成本控制的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 品优购商城——列表页
- 下一篇： P2P对等网络技术原理整合