《Kubernetes in action》Kubernetes 自动扩缩容HPA

pod的横向自动伸缩

了解自动伸缩过程

自动伸缩 的过程可以分为三个步骤：

• 获取被伸缩资源对象所管理的所有pod度量。
• 计算使度量数值到达（或接近）所指定目标数值所需的pod数量。
• 更新被伸缩资源的replicas字段。

获取pod度量

Autoscaler本身并不负责采集pod度量数据 ， 而是从另外的来源获取。 pod与节点度量数据是由运行在每个节点的kubelet之上， 名为cAdvisor的agent采集的；这些数据将由 集群级的组件Heapster聚合。 HPA控制器向Heapster 发起REST调用来获取 所有pod度量数据。

计算所需的 pod 数量

一 旦Autoscaler获得了它所调整的资源(Deployment、 ReplicaSet、ReplicationController或StatefulSet)所辖pod的全部度量， 它便可以利用这些度量计算出所需的副本数量。 它需要计算出一个合适的副本数量， 以使所有副本上度量的平均值尽量接近配置的目标值。 该计算的输入是一组pod度量（每个pod可能有多个）， 输出则是一个整数(pod副本数量）。
当Autoscaler配置为只考虑单个度量时， 计算所需 副本数很简单。 只要将所有pod的度量求和后除以HPA资源上配置的目标值， 再向上取整即可。 实际的计算稍微复杂一些； Autoscaler还保证了度量数值不稳定、 迅速抖动时不会导致系统抖动Ct缸ash)。
基于多个pod度量的自动伸缩（例如： CPU使用率和每秒查询率[QPS])的计算也并不复杂。 Autoscaler单独计算每个度量的副本数， 然后取最大值（例如：如果需要4个pod达到目标CPU使用率， 以及需要3个pod来达到目标QPS, 那么Autoscaler 将扩展到4个pod)。

更新被伸缩资源的副本数

自动伸缩操作的最后 一 步是更新被伸缩资源对象（比如ReplicaSet)上的副本数字段 然后让ReplicaSet控制器负责启动更多pod或者删除多余的pod。Autoscaler控制器通过Scale子资源来修改被伸缩资源的rep巨cas字段。 这样Autoscaler不必了解它所管理资源的细节，而只需要通过Scale子资源暴露的界面，就可以完成它的工作了

Scale子资源的资源有:

• Deployment
• ReplicaSet
• ReplicationController
• StatefulSet

了解整个自动伸缩过程

从pod指向 cAdvisor, 再经过Heapster , 而最终到达HPA的箭头代表度量数据的流向。 值得注意的是， 每个组件从其他组件拉取数据的动作是周期性的 （即cAdvisor用 一个无限循环从pod中采集数据； Heapster与HPA控制器亦是如此）。这意味着度量数据的传播与相应动作的触发都需要相当一段时间， 不是立即发生的。

基于CPU使用率进行自动伸缩

metric-service搭建

Kubernetes Version: v1.16.6
HPA收集pod指标的方式由heapster变为了Metric
直接通过helm包进行下载安装

[root@SHPL009049015 metrics-server]# helm repo list
NAME  	URL                                             
stable	https://kubernetes-charts.storage.googleapis.com
local 	http://127.0.0.1:8879/charts                    
[root@SHPL009049015 metrics-server]# helm fetch stable/metrics-server

测试HPA部署

yaml文件中的镜像使用在https://hub.docker.com/上搜索, 并替换我的私人镜像

相关hpa指标的yaml文件

cat test-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kubia
spec:
  replicas: 3
  selector:
    matchLabels:
      app: kubia
  template:
    metadata:
      name: kubia
      labels:
        app: kubia
    spec:
      containers:
      - image: eilinge/kubia:v1
        imagePullPolicy: IfNotPresent
        name: nodejs
        resources:
          requests:
            cpu: 100m
            memory: 1000Mi

cat kubia-svc.yaml

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: "2020-05-13T06:56:16Z"
  name: kubia
spec:
  clusterIP: 10.236.55.26
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: kubia
  sessionAffinity: None
  type: ClusterIP

cat metrics-hpa-bp.yaml

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: kubia
  namespace: default
spec:
  maxReplicas: 20
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: kubia
  targetCPUUtilizationPercentage: 80

测试cpu的pod: loadgenertor.yaml

kubectl get  svc
NAME            TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
kubia           ClusterIP   10.236.55.26   <none>        80/TCP         2d23h

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: loadgenertor
  name: loadgenertor
spec:
  containers:
  - args:
    - sh
    - -c
    - while true; do wget -o - -q http://10.236.55.26:80; done #kubia-svc的clusterIp:port
    image: eilinge/busybox:latest
    imagePullPolicy: IfNotPresent
    name: loadgenertor

通过watch kubectl get hpa,deploy -n big-data 监听cpu、pod副本数的变化

NAME                                        REFERENCE          TARGETS           MINPODS   MAXPODS   RE
PLICAS   AGE
horizontalpodautoscaler.autoscaling/kubia   Deployment/kubia   78%/80%   1         20        5
         3d2h

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/algorv3         0/1     1            0           2d14h
deployment.apps/kubia           5/5     5            5           3d2h
deployment.apps/test-q-0o84gq   1/1     1            1           22d

基于内存使用进行自动伸缩

Kubernetes版本为v1.16.x 默认的apiVersion: autoscaling/v1不支持Memory当指标进行扩容的，创建yaml文件时, 需要修改apiVersion

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: kubia
  namespace: big-data
  selfLink: /apis/autoscaling/v1/namespaces/default/horizontalpodautoscalers/kubia
  uid: 85301f19-4812-4923-a566-c50c63a6fbaa
spec:
  maxReplicas: 20
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: kubia
  metrics:
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 50
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 80

同时使用了Memory与Cpu时, 当其中一个指标阈值满足时, 为已当前pod的副本数量为准

NAME                                        REFERENCE          TARGETS           MINPODS   MAXPODS   RE
PLICAS   AGE
horizontalpodautoscaler.autoscaling/kubia   Deployment/kubia   5%/50%, 72%/80%   1         20        5

也可以使用自定义资源指标: kubernetes api

确定哪些度量适合用于自动伸缩

不是所有度量都适合作为自动伸缩的基础。正如之前提到的， pod中容器的内存占用并不是自动伸缩的一个好度量。如果增加副本数不能导致被观测度量平均值的线性（或者至少接近线性）下降 ，那么 autoscaler 就不能正常工作方说，如果你只有 pod 实例，度量数值为 ，这时 utoscaler 扩容到了个副本，度量数值就需要落在接近 X/ 位置 每秒查询次数 QPS ）就是这么一种自定义度量，对 we 应用而 即为应用每秒接收的请求数。增大副本数总会导致QPS 成比例下降，因为同样多的请求数现在被更多数量的 pod 处理了。在你决定基于应用自有的自定义度量来伸缩它之前，一定要思考 pod 数量增加或减少时，它的值会如何变化。

缩容到0个副本

HPA 目前不允许设置 inReplicas 宇段为0，所以 autoscaler 永远不会缩容0个副本，即便 pod 什么都没做也不会。
Kubernetes 目前暂时没有提供这个特性，但在未来会实 。可 以检查 Kubernetes文档来看看空载特性有没有被实现。

自动配置资源请求

如果新创建的pod的容器没有明确设置CPU与内存请求， 该特性即 会代为设置。 这一特性由一 个叫作lnitialResources的准入控制(Admission Control)插件提供。 当一个没有资源请求的pod被 创建时， 该插件 会根据pod容器的历史资源使用数据（随容器镜像、tag而变）来设置资源请求。
可以不用指定资源请求就部署pod, 而靠Kubemetes来最终得出每个容器的资源需求有多少。 实质上， Kubemetes是在 纵向伸缩这些pod。 比方说， 如果一个容器总是内存不足， 下次创建一个包含该容器镜像的pod的时候， 它的内存 资源请求就会被自动调高了。

本章小结

本章向你展示了Kubemetes能够如何伸缩你的pod以及节点。 你学到了

• 配置pod的自动横向伸缩很简单，只要创建一个HorizontalpodAutoscaler对象，将它指向一个Deployment、ReplicaSet、ReplicationController, 并设置pod的目标CPU使用率即可。
• 除了让HPA基于pod的CPU使用率进行伸缩操作， 还可以配置它基千应用自身提供的自定义度量，或者在集群中部署的其他对象的度量来自动伸缩。
• 目前还不能进行纵向pod自动伸缩。
• 可以用带有-it和–rm选项的kubectl run命令在pod中运行一次性的进程， 并在按下CTRL+C组合键时自动停止并删除该临时pod。