Kubernetes学习之HPA控制器

一、认识HPA
　　Deployment、ReplicaSet、Replication Controller或StatefulSet控制器资源管控的Pod副本数量支持手动方式的运行时调整，从而更好地匹配业务规模的实际需求。不过，手动调整的方式依赖于用户深度参与监控容器应用的资源压力并且需要计算出合理的值进行调整，存在一定的程度的滞后性。为此，Kubernetes提供了多种自动弹性伸缩（Auto Scaling）工具。具体如下：
　　HPA：全称为Horizontal Pod Autoscaler，一种支持控制器对象下Pod规模弹性伸缩的工具，目前有两个版本的实现，分别称为HPA和HPA（v2），前一种仅支持把CPU指标作为评估基准，而新版本支持可从资源指标API和自定义指标API中获取指标数据。HPA控制器的示意图如下：

　　CA：全称Cluster Autoscaler，是集群规模自动弹性伸缩工具，能自动增减GCP、AWS或Azure集群上部署的Kubernetes集群的节点数量，CA版本自Kubernetes 1.8起可用。
　　VPA：全称为Vertical Pod Autoscaler，是Pod应用垂直伸缩工具，它通过调整Pod对象的CPU和内存资源需求量完成扩展或收缩，目前仍处于alpha阶段。
　　AR：全称为Addon Resizer，是一个简化版本的Pod应用垂直伸缩工具，它基于集群中的节点数量来调整附加组件的资源需求量，当前仍处于beta级别。
　　尽管Cluster Autoscaler高度依赖基础云计算环境的底层功能，但HPA、VPA和AR可以独立于IaaS或PaaS云环境运行。HPA可作为Kubernetes API资源和控制器实现，它基于采集到的资源指标数据来调整控制器的行为，控制器会定期调整ReplicaSets或Deployment控制器对象中的副本数，以使得观察到的平均CPU利用率于用户指定的目标相匹配。
　　HPA自身是一个控制循环（control loop）的实现，其周期由controller-manager的--horizontal-pod-autoscaler-sync-period选项来定义，默认为30秒。在每个周期内，controller-manager将根据每个HPA定义中指定的指标查询相应的资源利用率。controller-manager从资源指标API（针对每个Pod资源指标）或自定义指标API（针对所有其他指标）中获取指标数据。
　　对于每个Pod资源指标（如CPU），控制器都将从HAP定位到的每个Pod的资源指标API中获取指标数据。若设置了目标利用率（target utilization）标准，则直接使用原始指标值。然后控制器获取所有目标Pod对象的利用率或原始值的均值（取决于指定的目标类型），并生成一个用于缩放所需的副本数的比率。不过，对于未定义资源需求量的Pod对象，HPA控制器将无法定义该容器的CPU利用率，并且不会为该指标采取任何操作。
　　对于每个Pod对象的自定义指标，HPA控制器的功能与每个Pod资源指标的处理机制类型，只是它仅能够处理原始值而非利用率。
　　不过，使用HPA控制器管理Pod对象副本规模时，由于所评估指标的动态变动特性，副本数量可能会频繁波动，这种现象有时也称为"抖动"。从Kubernetes 1.6版本开始，集群管理员可以通过调整kube-controller-manager的选项定义其变动延迟时长来缓解此问题。目前，默认的缩容延迟时长为5分钟，而扩容时长为3分钟。
　　HAP控制器可以通过两种不同的方式获取指标：Heapster和REST客户端接口。使用直接Heapster获取指标数据时，HPA直接通过API服务器的服务代理子资源向Heapster发起查询请求，因此，Heapster需要事先部署在集群上并在kube-system名称空间中运行。使用REST客户端接口获取指标时，需要事先部署好资源指标API及其API Server，必要时，还应该部署好自定义指标API及其相关的API Server。

二、HPA（v1）控制器
　　HPA也是标准的Kubernetes API资源，其基于资源配置清单的管理方式同其他资源相同。另外，它还有一个特别的"kubectl autoscale"命令用于快速创建HPA控制器。例如，首先创建一个名为myapp的Deployment控制器，而后通过一个同名的HPA控制器自动管控其Pod副本规模：

1）编写创建myapp控制器的资源文件

]# cat myapp.yaml 
apiVersion: apps/v1
kind: Deployment
metadata: 
  name: myapp
  namespace: default
spec: 
  replicas: 2
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: ikubernetes/myapp:v1
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 80
        resources:
          requests:
            cpu: "50m"
            memory: "256Mi"
          limits:
            cpu: "50m"
            memory: "256Mi"

]# kubectl apply -f myapp.yaml 
deployment.apps/myapp created

2）查看myapp控制器信息

]# kubectl get deploy -o wide 
NAME    READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES                 SELECTOR
myapp   2/2     2            2           6s    myapp        ikubernetes/myapp:v1   app=myapp

]# kubectl describe deploy myapp
Name:                   myapp
Namespace:              default
CreationTimestamp:      Sun, 22 Nov 2020 15:07:50 +0800
Labels:                 <none>
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               app=myapp
Replicas:               2 desired | 2 updated | 2 total | 2 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=myapp
  Containers:
   myapp:
    Image:      ikubernetes/myapp:v1
    Port:       80/TCP
    Host Port:  0/TCP
    Limits:
      cpu:     50m
      memory:  256Mi
    Requests:
      cpu:        50m
      memory:     256Mi
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   myapp-8b4858b4d (2/2 replicas created)
Events:
  Type    Reason             Age    From                   Message
  ----    ------             ----   ----                   -------
  Normal  ScalingReplicaSet  4m27s  deployment-controller  Scaled up replica