kubernetes HPA-超详细中文官方文档

时间  2020-05-15
标签 kubernetes hpa 详细 中文 官方 文档 繁體版
原文   原文链接

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中的副本数量。php

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/

1、HPA工做原理

kubernetes HPA-超详细中文官方文档

HPA的实现是一个控制循环，由controller manager的--horizontal-pod-autoscaler-sync-period参数指定周期（默认值为15秒）。每一个周期内，controller manager根据每一个HorizontalPodAutoscaler定义中指定的指标查询资源利用率。controller manager能够从resource metrics API（pod 资源指标）和custom metrics API（自定义指标）获取指标。html

1）对于每一个pod的资源指标（如CPU），控制器从资源指标API中获取每个 HorizontalPodAutoscaler指定的pod的指标，而后，若是设置了目标使用率，控制器获取每一个pod中的容器资源使用状况，并计算资源使用率。若是使用原始值，将直接使用原始数据（再也不计算百分比）。而后，控制器根据平均的资源使用率或原始值计算出缩放的比例，进而计算出目标副本数。须要注意的是，若是pod某些容器不支持资源采集，那么控制器将不会使用该pod的CPU使用率node

2）若是 pod 使用自定义指标，控制器机制与资源指标相似，区别在于自定义指标只使用原始值，而不是使用率。nginx

3）若是pod 使用对象指标和外部指标（每一个指标描述一个对象信息）。这个指标将直接跟据目标设定值相比较，并生成一个上面提到的缩放比例。在autoscaling/v2beta2版本API中，这个指标也能够根据pod数量平分后再计算。一般状况下，控制器将从一系列的聚合API（metrics.k8s.io、custom.metrics.k8s.io和external.metrics.k8s.io）中获取指标数据。metrics.k8s.io API一般由 metrics-server（须要额外启动）提供。git

2、metrics server

metrics-server是一个集群范围内的资源数据集和工具，一样的，metrics-server也只是显示数据，并不提供数据存储服务，主要关注的是资源度量API的实现，好比CPU、文件描述符、内存、请求延时等指标，metric-server收集数据给k8s集群内使用，如kubectl,hpa,scheduler等github

1.部署metrics-server，在k8s的master节点操做

1）经过离线方式获取镜像

须要的镜像是：docker

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

镜像所在百度网盘地址以下：apache

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

若是你们机器不能访问外部网络，能够把镜像上传到k8s的各个节点，按以下方法手动解压api

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状态说明启动成功
kubernetes HPA-超详细中文官方文档

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

3、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（额外指标）的缩放。

4、使用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之间。

5、多指标支持

在Kubernetes1.6+中支持基于多个指标进行缩放。你可使用autoscaling/v2beta2 API来为HPA指定多个指标。HPA会跟据每一个指标计算，并生成一个缩放建议。

6、自定义指标支持

自Kubernetes1.6起，HPA支持使用自定义指标。你可使用autoscaling/v2beta2 API为HPA指定用户自定义指标。Kubernetes会经过用户自定义指标API来获取相应的指标。

7、测试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

显示以下说明建立成功：
kubernetes HPA-超详细中文官方文档
注：因为咱们没有向服务器发送任何请求，所以当前CPU消耗为0％（TARGET列显示了由相应的deployment控制的全部Pod的平均值）。

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; done

在一分钟左右的时间内，咱们经过执行如下命令来看到更高的CPU负载

kubectl get hpa

显示以下：
kubernetes 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
显示以下：

NAME         READY   UP-TO-DATE   AVAILABLE   AGE
php-apache   5/5     5            5           2h1m

注意：可能须要几分钟来稳定副本数。因为不以任何方式控制负载量，所以最终副本数可能会与此示例不一样。

4.中止对php-apache服务压测，HPA会自动对php-apache这个deployment建立的pod作缩容

中止向php-apache这个服务发送查询请求，在busybox镜像建立容器的终端中，经过<Ctrl>+ C把刚才while请求中止，而后，咱们将验证结果状态（大约一分钟后）：

kubectl get hpa
显示以下：
kubernetes HPA-超详细中文官方文档

kubectl get deployment php-apache

显示以下：
kubernetes HPA-超详细中文官方文档

经过上面能够看到，CPU利用率降低到0，所以HPA自动将副本数缩减到1。

注意：自动缩放副本可能须要几分钟。

8、测试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

kubectl get pods

显示以下:

NAME                          READY   STATUS    RESTARTS   AGE
nginx-hpa-bb598885d-j4kcp     1/1     Running   0          25m
nginx-hpa-bb598885d-rj5hk     1/1     Running   0          63s
nginx-hpa-bb598885d-twv9c     1/1     Running   0          18s
nginx-hpa-bb598885d-v9ft5     1/1     Running   0          63s

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

9、基于多项指标和自定义指标的自动缩放

能够经过使用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个。

10、在更多指定指标下的自动伸缩

许多度量管道容许你经过名称或附加的_labels_来描述度量指标。对于全部非资源类型度量指标(pod、object和后面将介绍的external)，能够额外指定一个标签选择器。例如，若是你但愿收集包含verb标签的http_requests度量指标， 你能够在GET请求中指定须要的度量指标，以下所示：

type:Object
object:
  metric:
    name:`http_requests`
    selector:`verb=GET`

这个选择器使用与Kubernetes标签选择器相同的语法。若是名称和标签选择器匹配到多个系列，监测管道会决定如何将多个系列合并成单个值。选择器是附加的，它不会选择目标之外的对象（类型为Pods的目标和类型为Object的目标）。

11、基于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
仍是推荐custom metric而不是external metrics，由于这便于让系统管理员加固custom metrics API。而external metrics API能够容许访问全部的度量指标，当暴露这些服务时，系统管理员须要仔细考虑这个问题。

想要了解kubernetes、微服务、DevOps更多知识和生产案例，获取免费视频，可按以下方式获取哈~~~
kubernetes HPA-超详细中文官方文档

微信：luckylucky421302

kubernetes HPA-超详细中文官方文档
kubernetes HPA-超详细中文官方文档

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程