HPA全稱是Horizontal Pod Autoscaler，翻譯成中文是POD水平自動伸縮，以下都會用HPA代替Horizontal Pod Autoscaler，HPA可以基于CPU利用率對replication controller、deployment和replicaset中的pod數量進行自動擴縮容(除了CPU利用率也可以基于其他應程序提供的度量指標custom metrics進行自動擴縮容)。pod自動縮放不適用于無法縮放的對象，比如DaemonSets。HPA由Kubernetes API資源和控制器實現。資源決定了控制器的行為。控制器會周期性的獲取平均CPU利用率，并與目標值相比較后來調整replication controller或deployment中的副本數量。

custom metrics詳細介紹參考如下：

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md

?參考官網地址如下：

https://v1-17.docs.kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/

?一、HPA工作原理

HPA的實現是一個控制循環，由controller manager的--horizontal-pod-autoscaler-sync-period參數指定周期(默認值為15秒)。每個周期內，controller manager根據每個HorizontalPodAutoscaler定義中指定的指標查詢資源利用率。controller manager可以從resource metrics API(pod 資源指標)和custom metrics API(自定義指標)獲取指標。

1)對于每個pod的資源指標(如CPU)，控制器從資源指標API中獲取每一個 HorizontalPodAutoscaler指定的pod的指標，然后，如果設置了目標使用率，控制器獲取每個pod中的容器資源使用情況，并計算資源使用率。如果使用原始值，將直接使用原始數據(不再計算百分比)。然后，控制器根據平均的資源使用率或原始值計算出縮放的比例，進而計算出目標副本數。需要注意的是，如果pod某些容器不支持資源采集，那么控制器將不會使用該pod的CPU使用率

2)如果 pod 使用自定義指標，控制器機制與資源指標類似，區別在于自定義指標只使用原始值，而不是使用率。

3)如果pod 使用對象指標和外部指標(每個指標描述一個對象信息)。這個指標將直接跟據目標設定值相比較，并生成一個上面提到的縮放比例。在autoscaling/v2beta2版本API中，這個指標也可以根據pod數量平分后再計算。通常情況下，控制器將從一系列的聚合API(metrics.k8s.io、custom.metrics.k8s.io和external.metrics.k8s.io)中獲取指標數據。metrics.k8s.io API通常由 metrics-server(需要額外啟動)提供。

二、metrics server

metrics-server是一個集群范圍內的資源數據集和工具，同樣的，metrics-server也只是顯示數據，并不提供數據存儲服務，主要關注的是資源度量API的實現，比如CPU、文件描述符、內存、請求延時等指標，metric-server收集數據給k8s集群內使用，如kubectl,hpa,scheduler等

使用HPA前提：

A、部署好metrics-server
B、部署pod時候要設置資源requests

1.部署metrics-server，在k8s的master節點操作

1)通過離線方式獲取鏡像

需要的鏡像是：

k8s.gcr.io/metrics-server-amd64:v0.3.6和 k8s.gcr.io/addon-resizer:1.8.4

?鏡像所在百度網盤地址如下：

鏈接：https://pan.baidu.com/s/1SKpNaskVr_zQJVQuM_GzIQ 提取碼：24yb 鏈接：https://pan.baidu.com/s/1KXOSiSJGGGaUXCjdCHoXjQ 提取碼：yab5

docker load -i metrics-server-amd64_0_3_1.tar.gz
docker load -i addon.tar.gz

2)metrics.yaml文件

cat metrics.yaml

apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata:name: metrics-server:system:auth-delegatorlabels:kubernetes.io/cluster-service: "true"addonmanager.kubernetes.io/mode: Reconcile roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: system:auth-delegator subjects: - kind: ServiceAccountname: metrics-servernamespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata:name: metrics-server-auth-readernamespace: kube-systemlabels:kubernetes.io/cluster-service: "true"addonmanager.kubernetes.io/mode: Reconcile roleRef:apiGroup: rbac.authorization.k8s.iokind: Rolename: extension-apiserver-authentication-reader subjects: - kind: ServiceAccountname: metrics-servernamespace: kube-system --- apiVersion: v1 kind: ServiceAccount metadata:name: metrics-servernamespace: kube-systemlabels:kubernetes.io/cluster-service: "true"addonmanager.kubernetes.io/mode: Reconcile --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata:name: system:metrics-serverlabels:kubernetes.io/cluster-service: "true"addonmanager.kubernetes.io/mode: Reconcile rules: - apiGroups:- ""resources:- pods- nodes- nodes/stats- namespacesverbs:- get- list- watch - apiGroups:- "extensions"resources:- deploymentsverbs:- get- list- update- watch --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata:name: system:metrics-serverlabels:kubernetes.io/cluster-service: "true"addonmanager.kubernetes.io/mode: Reconcile roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: system:metrics-server subjects: - kind: ServiceAccountname: metrics-servernamespace: kube-system --- apiVersion: v1 kind: ConfigMap metadata:name: metrics-server-confignamespace: kube-systemlabels:kubernetes.io/cluster-service: "true"addonmanager.kubernetes.io/mode: EnsureExists data:NannyConfiguration: |-apiVersion: nannyconfig/v1alpha1kind: NannyConfiguration --- apiVersion: apps/v1 kind: Deployment metadata:name: metrics-servernamespace: kube-systemlabels:k8s-app: metrics-serverkubernetes.io/cluster-service: "true"addonmanager.kubernetes.io/mode: Reconcileversion: v0.3.6 spec:selector:matchLabels:k8s-app: metrics-serverversion: v0.3.6template:metadata:name: metrics-serverlabels:k8s-app: metrics-serverversion: v0.3.6annotations:scheduler.alpha.kubernetes.io/critical-pod: ''seccomp.security.alpha.kubernetes.io/pod: 'docker/default'spec:priorityClassName: system-cluster-criticalserviceAccountName: metrics-servercontainers:- name: metrics-serverimage: k8s.gcr.io/metrics-server-amd64:v0.3.6command:- /metrics-server- --metric-resolution=30s- --kubelet-preferred-address-types=InternalIP- --kubelet-insecure-tlsports:- containerPort: 443name: httpsprotocol: TCP- name: metrics-server-nannyimage: k8s.gcr.io/addon-resizer:1.8.4resources:limits:cpu: 100mmemory: 300Mirequests:cpu: 5mmemory: 50Mienv:- name: MY_POD_NAMEvalueFrom:fieldRef:fieldPath: metadata.name- name: MY_POD_NAMESPACEvalueFrom:fieldRef:fieldPath: metadata.namespacevolumeMounts:- name: metrics-server-config-volumemountPath: /etc/configcommand:- /pod_nanny- --config-dir=/etc/config- --cpu=300m- --extra-cpu=20m- --memory=200Mi- --extra-memory=10Mi- --threshold=5- --deployment=metrics-server- --container=metrics-server- --poll-period=300000- --estimator=exponential- --minClusterSize=2volumes:- name: metrics-server-config-volumeconfigMap:name: metrics-server-configtolerations:- key: "CriticalAddonsOnly"operator: "Exists"- key: node-role.kubernetes.io/mastereffect: NoSchedule --- apiVersion: v1 kind: Service metadata:name: metrics-servernamespace: kube-systemlabels:addonmanager.kubernetes.io/mode: Reconcilekubernetes.io/cluster-service: "true"kubernetes.io/name: "Metrics-server" spec:selector:k8s-app: metrics-serverports:- port: 443protocol: TCPtargetPort: https --- apiVersion: apiregistration.k8s.io/v1beta1 kind: APIService metadata:name: v1beta1.metrics.k8s.iolabels:kubernetes.io/cluster-service: "true"addonmanager.kubernetes.io/mode: Reconcile spec:service:name: metrics-servernamespace: kube-systemgroup: metrics.k8s.ioversion: v1beta1insecureSkipTLSVerify: truegroupPriorityMinimum: 100versionPriority: 100
kubectl apply -f metrics.yaml 3)驗證metrics-server是否部署成功 kubectl get pods -n kube-system 顯示如下running狀態說明啟動成功4)測試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

三、HPA API對象

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(額外指標)的縮放。

?四、使用kubectl操作HPA

與其他API資源類似，kubectl也支持Pod自動伸縮。我們可以通過kubectl create命令創建一個自動伸縮對象，通過kubectl get hpa命令來獲取所有自動伸縮對象，通過kubectl describe hpa命令來查看自動伸縮對象的詳細信息。最后，可以使用kubectl delete hpa命令刪除對象。此外，還有個簡便的命令kubectl autoscale來創建自動伸縮對象。例如，命令kubectl autoscale rs foo --min=2 ?--max=5 --cpu-percent=80將會為名為foo的replication set創建一個自動伸縮對象，對象目標的CPU使用率為80%，副本數量配置為2到5之間。

五、多指標支持

在Kubernetes1.6+中支持基于多個指標進行縮放。你可以使用autoscaling/v2beta2 API來為HPA指定多個指標。HPA會跟據每個指標計算，并生成一個縮放建議。

六、自定義指標支持

自Kubernetes1.6起，HPA支持使用自定義指標。你可以使用autoscaling/v2beta2 API為HPA指定用戶自定義指標。Kubernetes會通過用戶自定義指標API來獲取相應的指標。

七、測試HPA的autoscaling/v1版-基于CPU的自動擴縮容

用Deployment創建一個php-apache服務，然后利用HPA進行自動擴縮容。步驟如下：

1.通過deployment創建pod，在k8s的master節點操作

1)創建并運行一個php-apache服務

使用dockerfile構建一個新的鏡像，在k8s的master節點構建

cat dockerfile

FROM php:5-apache ADD index.php /var/www/html/index.php RUN chmod a+rx index.php

cat index.php

<?php$x = 0.0001;for ($i = 0; $i <= 1000000;$i++) {$x += sqrt($x);}echo "OK!"; ?>

docker build -t k8s.gcr.io/hpa-example:v1 .

2)打包鏡像

docker save -o hpa-example.tar.gz k8s.gcr.io/hpa-example:v1

3)解壓鏡像

可以把鏡像傳到k8s的各個節點，docker load-i hpa-example.tar.gz進行解壓

4)通過deployment部署一個php-apache服務

cat php-apache.yaml

apiVersion:apps/v1 kind:Deployment metadata:name:php-apache spec:selector:matchLabels:run:php-apachereplicas:1template:metadata:labels:run:php-apachespec:containers:-name:php-apacheimage:k8s.gcr.io/hpa-example:v1ports:-containerPort:80resources:limits:cpu:500mrequests:cpu:200m--- apiVersion: v1 kind:Service metadata:name:php-apachelabels:run:php-apache spec:ports:-port:80selector:run:php-apache

?kubectl apply -f php-apache.yaml

5)驗證php是否部署成功

kubectl get pods

顯示如下，說明php服務部署成功了

NAME READY STATUS RESTARTS AGE php-apache-5694767d56-mmr88 1/1 Running 0 66s

2.創建HPA

php-apache服務正在運行，使用kubectl autoscale創建自動縮放器，實現對php-apache這個deployment創建的pod自動擴縮容，下面的命令將會創建一個HPA，HPA將會根據CPU，內存等資源指標增加或減少副本數，創建一個可以實現如下目的的hpa：

1)讓副本數維持在1-10個之間(這里副本數指的是通過deployment部署的pod的副本數) 2)將所有Pod的平均CPU使用率維持在50％(通過kubectlrun運行的每個pod如果是200毫核，這意味著平均CPU利用率為100毫核)

1)給上面php-apache這個deployment創建HPA

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10

上面命令解釋說明

kubectl autoscale deployment php-apache (php-apache表示deployment的名字) --cpu-percent=50(表示cpu使用率不超過50%) --min=1(最少一個pod) --max=10(最多10個pod)

2)驗證HPA是否創建成功

kubectl get hpa

3.壓測php-apache服務，只是針對CPU做壓測

啟動一個容器，并將無限查詢循環發送到php-apache服務(復制k8s的master節點的終端，也就是打開一個新的終端窗口)：

kubectl run v1 -it --image=busybox /bin/sh

登錄到容器之后，執行如下命令

while true; do wget -q -O- http://php-apache.default.svc.cluster.local; don

在一分鐘左右的時間內，我們通過執行以下命令來看到更高的CPU負載

kubectl get hpa

顯示如下：

上面可以看到，CPU消耗已經達到256％，每個pod的目標cpu使用率是50%，所以，php-apache這個deployment創建的pod副本數將調整為5個副本，為什么是5個副本，因為256/50=5

kubectl get pod

顯示如下：

NAME READY STATUS RESTARTS AGE php-apache-5694767d56-b2kd7 1/1 Running 0 18s php-apache-5694767d56-f9vzm 1/1 Running 0 2s php-apache-5694767d56-hpgb5 1/1 Running 0 18s php-apache-5694767d56-mmr88 1/1 Running 0 4h13m php-apache-5694767d56-zljkd 1/1 Running 0 18s

kubectl get deployment php-apache

顯示如下：

kubectl get deployment php-apache 顯示如下：

?注意：可能需要幾分鐘來穩定副本數。由于不以任何方式控制負載量，因此最終副本數可能會與此示例不同。

4.停止對php-apache服務壓測，HPA會自動對php-apache這個deployment創建的pod做縮容

停止向php-apache這個服務發送查詢請求，在busybox鏡像創建容器的終端中，通過<Ctrl>+ C把剛才while請求停止，然后，我們將驗證結果狀態(大約一分鐘后)：

kubectl get hpa

......

通過上面可以看到，CPU利用率下降到0，因此HPA自動將副本數縮減到1。注意：自動縮放副本可能需要幾分鐘。

八、測試HPA autoscaling/v2beta1版本-基于內存的自動擴縮容

1.創建一個nginx的pod

cat 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: 30080kubectl apply -f nginx.yaml

2.驗證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

3.創建一個hpa

cat hpa-v1.yaml

apiVersion: autoscaling/v2beta1 kind: HorizontalPodAutoscaler metadata:name: nginx-hpa spec:maxReplicas: 10minReplicas: 1scaleTargetRef:apiVersion:apps/v1kind: Deploymentname: nginx-hpametrics:- type: Resourceresource:name: memorytargetAverageUtilization: 60

kubectl get hpa

顯示如下：

NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE nginx-hpa Deployment/nginx-hpa 5%/60% 1 10 1 20s

4.壓測nginx的內存，hpa會對pod自動擴縮容

登錄到上面通過pod創建的nginx，并生成一個文件，增加內存

kubectl exec -it nginx-hpa-bb598885d-j4kcp -- /bin/sh

?壓測：

dd if=/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

?5.取消對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

kubectl get deployment

顯示如下，deployment的pod又恢復到1個了：

NAME READY UP-TO-DATE AVAILABLE AGE nginx-hpa 1/1 1 1 38m

九、基于多項指標和自定義指標的自動縮放

可以通過使用autoscaling/v2beta2 API版本來介紹在自動縮放php-apache這個deployment時使用的其他度量指標(metrics)。

獲取autoscaling/v2beta2 API版本HPA的yaml文件

kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml

在編輯器打開文件/tmp/hpa-v2.yaml，刪除掉一些不需要要的字段，可看到如下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: 0

targetCPUUtilizationPercentage字段由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之間進行平均，并通過與一個目標值比對來確定副本的數量。它們的工作方式與資源度量指標非常相像，差別是它們僅支持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可以允許訪問所有的度量指標，當暴露這些服務時，系統管理員需要仔細考慮這個問題。

?十二、經驗

1、部署deployment? pod

kubectl create deployment java-web3 --image=java-demo:v1

命令行方式創建的pod，沒有對資源做出限制，導致

kubectl edit hpa java-web2 沒有相應的images、containters字段，沒有辦法修改requests。

正解：修改deployment/pod? request 字段

kubectl edit deployments.apps java-web2.... spec:containers:- image: java-demo:v1imagePullPolicy: IfNotPresentname: java-demoresources:limits:cpu: "1"requests:cpu: 500m ......

創建java-web3 pod 的 hpa

kubectl autoscale deployment java-web3 --min=3 --max=7 --cpu-percent=70

暴露pod服務

kubectl expose deployment java-web3 --port=80 --target-port=8080

?獲取server?? ip

[root@master ~]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE java-web2 ClusterIP 10.106.10.163 <none> 80/TCP 50m

人為增大訪問量

for i in {1..10000};do curl 10.106.10.163; done

測試

kubectl get hpa

https://mp.weixin.qq.com/s/6uy1fvzz2Y34DB7ugZ0PAQ

java-web3

總結

以上是生活随笔為你收集整理的kubernetes HPA的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。