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等

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-delegator
  labels:
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:auth-delegator
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: metrics-server-auth-reader
  namespace: kube-system
  labels:
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: extension-apiserver-authentication-reader
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: metrics-server
  namespace: kube-system
  labels:
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: system:metrics-server
  labels:
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - nodes
  - nodes/stats
  - namespaces
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - "extensions"
  resources:
  - deployments
  verbs:
  - get
  - list
  - update
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: system:metrics-server
  labels:
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:metrics-server
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: metrics-server-config
  namespace: kube-system
  labels:
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: EnsureExists
data:
  NannyConfiguration: |-
    apiVersion: nannyconfig/v1alpha1
    kind: NannyConfiguration
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: metrics-server
  namespace: kube-system
  labels:
    k8s-app: metrics-server
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
    version: v0.3.6
spec:
  selector:
    matchLabels:
      k8s-app: metrics-server
      version: v0.3.6
  template:
    metadata:
      name: metrics-server
      labels:
        k8s-app: metrics-server
        version: v0.3.6
      annotations:
        scheduler.alpha.kubernetes.io/critical-pod: ''
        seccomp.security.alpha.kubernetes.io/pod: 'docker/default'
    spec:
      priorityClassName: system-cluster-critical
      serviceAccountName: metrics-server
      containers:
      - name: metrics-server
        image: k8s.gcr.io/metrics-server-amd64:v0.3.6
        command:
        - /metrics-server
        - --metric-resolution=30s
        - --kubelet-preferred-address-types=InternalIP
        - --kubelet-insecure-tls
        ports:
        - containerPort: 443
          name: https
          protocol: TCP
      - name: metrics-server-nanny
        image: k8s.gcr.io/addon-resizer:1.8.4
        resources:
          limits:
            cpu: 100m
            memory: 300Mi
          requests:
            cpu: 5m
            memory: 50Mi
        env:
          - name: MY_POD_NAME
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
          - name: MY_POD_NAMESPACE
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
        volumeMounts:
        - name: metrics-server-config-volume
          mountPath: /etc/config
        command:
          - /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=2
      volumes:
        - name: metrics-server-config-volume
          configMap:
            name: metrics-server-config
      tolerations:
        - key: "CriticalAddonsOnly"
          operator: "Exists"
        - key: node-role.kubernetes.io/master
          effect: NoSchedule
---
apiVersion: v1
kind: Service
metadata:
  name: metrics-server
  namespace: kube-system
  labels:
    addonmanager.kubernetes.io/mode: Reconcile
    kubernetes.io/cluster-service: "true"
    kubernetes.io/name: "Metrics-server"
spec:
  selector:
    k8s-app: metrics-server
  ports:
  - port: 443
    protocol: TCP
    targetPort: https
---
apiVersion: apiregistration.k8s.io/v1beta1
kind: APIService
metadata:
  name: v1beta1.metrics.k8s.io
  labels:
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
spec:
  service:
    name: metrics-server
    namespace: kube-system
  group: metrics.k8s.io
  version: v1beta1
  insecureSkipTLSVerify: true
  groupPriorityMinimum: 100
  versionPriority: 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-apache
  replicas:1
  template:
    metadata:
      labels:
        run:php-apache
    spec:
      containers:
      -name:php-apache
        image:k8s.gcr.io/hpa-example:v1
        ports:
        -containerPort:80
        resources:
          limits:
            cpu:500m
          requests:
            cpu:200m

---
apiVersion: v1
kind:Service
metadata:
  name:php-apache
  labels:
    run:php-apache
spec:
  ports:
  -port:80
  selector:
    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: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.9.1
        ports:
        - containerPort: 80
          name: http
          protocol: TCP
        resources:
          requests:
            cpu: 0.01
            memory: 25Mi
          limits:
            cpu: 0.05
            memory: 60Mi
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  selector:
    app: nginx
  type: NodePort
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 30080
 
kubectl 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.01
      memory: 25Mi
    limits:
       cpu: 0.05
       memory: 60Mi

3.建立一個hpa

cat hpa-v1.yaml

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
    maxReplicas: 10
    minReplicas: 1
    scaleTargetRef:
      apiVersion:apps/v1
      kind: Deployment
      name: nginx-hpa
    metrics:
    - type: Resource
      resource:
        name: memory
       targetAverageUtilization: 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-apache
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
status:
  observedGeneration: 1
  lastScaleTime: <some-time>
  currentReplicas: 1
  desiredReplicas: 1
  currentMetrics:
  - type: Resource
    resource:
      name: cpu
      current:
        averageUtilization: 0
        averageValue: 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-second
  target:
    type: AverageValue
    averageValue: 1k

第二種可選的度量指標型別是物件度量指標。相對於描述Pod，這些度量指標用於描述一個在相同名字空間(namespace)中的其他物件。請注意這些度量指標用於描述這些物件，並非從物件中獲取。物件度量指標支援的target型別包括Value和AverageValue。如果是Value型別，target值將直接與API返回的度量指標比較，而AverageValue型別，API返回的度量指標將按照Pod數量拆分，然後再與target值比較。下面的YAML檔案展示了一個表示requests-per-second的度量指標。

type: Object
object:
  metric:
    name: requests-per-second
  describedObject:
    apiVersion: networking.k8s.io/v1beta1
    kind: Ingress
    name: main-route
  target:
    type: Value
    value: 2k

如果你指定了多個上述型別的度量指標，HorizontalPodAutoscaler將會依次考量各個指標。HorizontalPodAutoscaler將會計算每一個指標所提議的副本數量，然後最終選擇一個最高值。比如，如果你的監控系統能夠提供網路流量資料，你可以通過kubectl edit命令將上述Horizontal Pod Autoscaler的定義更改為：

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: AverageUtilization
        averageUtilization: 50
  - type: Pods
    pods:
      metric:
        name: packets-per-second
      targetAverageValue: 1k
  - type: Object
    object:
      metric:
        name: requests-per-second
      describedObject:
        apiVersion: networking.k8s.io/v1beta1
        kind: Ingress
        name: main-route
      target:
        kind: Value
        value: 10k
status:
  observedGeneration: 1
  lastScaleTime: <some-time>
  currentReplicas: 1
  desiredReplicas: 1
  currentMetrics:
  - type: Resource
    resource:
      name: cpu
    current:
      averageUtilization: 0
      averageValue: 0
  - type: Object
    object:
      metric:
        name: requests-per-second
      describedObject:
        apiVersion: networking.k8s.io/v1beta1
        kind: Ingress
        name: main-route
      current:
        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:External
  external:
    metric:
      name:queue_messages_ready
      selector:"queue=worker_tasks"
    target:
      type:AverageValue
      averageValue:30

還是推薦custommetric而不是externalmetrics，因為這便於讓系統管理員加固custommetricsAPI。而externalmetricsAPI可以允許訪問所有的度量指標，當暴露這些服務時，系統管理員需要仔細考慮這個問題。

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