一、背景

       应用程序的使用存在波峰波谷现象，在应用流量处于低谷期间，可以释放因过多的Pod而浪费的硬件资源。在应用流量高峰期提供弹性足够的Pod处理流量。

二、HPA各个组件扭转关系

     kubernetes使用者通过创建一个hpa资源（horizontalpodautoscaler）用于定义对某个负载比如deployment的弹性策略，策略中说明基于什么指标、指标的阈值以及弹性的最大值、最小值。hpa资源创建后，kube-controller-manager中的hpa-controller协程开始工作，大致工作步骤如下：

1. 调用kube-apiserver，获取HPA 资源关联负载的指标
2. 用负载当前的指标和HPA中规定的阈值比较，结合逻辑判断是增加、减少或者不修改负载的示例数
3. 根据步骤2的计算结果，调用kube-apiserver修改负载的示例数

     需要理解的关键卡点问题是

1. 指标是从哪里来的？
2. kube-apiserver本身代码里面不提供指标的API，为啥调用kube-apiserver接口能获取到指标？
   

三、指标和指标的来源

    指标均由业务API提供，一般业界指标标准URL为/metrics。kubernetes生态中，主要通过Metrics server和Prometheus获取指标：

• metrics server：metrics-server作为集群组件，用于收集和聚合从每个kubelet中提取的资源指标。本质上只是做了数据的中转和聚合，通过调用kubelet的api接口获取数据。kubelet 作为用于管理容器资源的节点代理，可以使用 /metrics/resource 接口访问资源指标。
• Prometheus：在某些场景下，prometheus采集的指标可能需要重命名或者重新计算，由Prometheus-adapter组件提供转换能力。

     在kubernetes中指标分为core metric（核心指标）和custom metric（自定义指标）：

• Core metrics（核心指标）：Metrics server通过调用各个节点kubelet 10250端口，由kubelet内部cAdvisor模块获取度量指标，对应指标实现由kubelet提供，使用者无法修改，然后返回给HPA。

• Custom Metrics（自定义指标）：通过Prometheus获取对应的业务指标，具体指标内容有业务自己实现。

四、通过API Aggregation拓展kubernetes API

      API Aggregation 允许在不修改 Kubernetes 核心代码的同时扩展 Kubernetes API，即将第三方服务注册到 Kubernetes API 中，这样就可以通过 Kubernetes API 来访问外部服务。

      如下图示例，通过APIService资源新增 /apis/metrics.k8s.io/v1beta1 和 /apis/custom.metrics.k8s.io/v1beta1。当kube-apiserver收到对应URL请求后，会将请求转发给APIService资源中spec.service指定的服务，URL为 /apis/metrics.k8s.io/v1beta1的请求转发给metrics-server服务处理，URL为/apis/custom.metrics.k8s.io/v1beta1的请求转发给custom-metrics-apiserver服务（本质上就是Prometheus-adapter，服务名称为custom-metrics-apiserver而已）。如此，便可以通过直接访问kube-apiserver端口，获取对应的指标数据。  

# 比如获取核心指标
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/namespaces/${yourNamespace}/pods"

# 获取自定义指标：
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/${yourNamespace}/x"

    如此，kube-controller-manager就可以通过调用kube-apiserver接口获取相关业务的指标了。

五、HPA实践建议

HorizontalPodAutoscaler 是 Kubernetes autoscaling API 组中的 API 资源。 当前的稳定版本可以在 autoscaling/v2 API 版本中找到，其中包括对基于内存和自定义指标执行扩缩的支持。 在使用 autoscaling/v1 时，autoscaling/v2 中引入的新字段作为注释保留。可配置的扩缩行为(behavior)在之前的 autoscaling/v2beta2 API 版本将此功能作为 beta 功能提供。1.23 kubernetes及以上可参考yaml：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
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
  behavior:
    scaleDown:
      policies:
      - type: Pods
        value: 4
        periodSeconds: 60
      - type: Percent
        value: 10
        periodSeconds: 60

1. 核心指标弹性，一般建议采用cpu指标进行弹性，memory因为不太敏感而且跟开发语言相关，大多数语言都有内存池以及内置GC机制导致进程内存监控不准确

2. 对于HPA场景，建议负载资源的requests:limits = 1:1；k8s从业务稳定性角度出发，定义HPA Pod利用率 = Pod当前使用量/Pod request；但是监控（华为云AOM、Prometheus监控）从用户习惯出发，定义Pod利用率 = Pod当前使用量 /Pod limits。对于HPA场景，建议Pod的limits和request设置为1:1，则既能保证业务集群稳定，同时兼顾使用者观测习惯。对于非HPA类场景业务，建议request：limit在1:1.5以内
3. 快速扩容，主要防止流量瓶颈；缓慢缩容，主要防止另一个流量高峰。
   

1. 1. 快速扩容策略配置

      behavior:           #通过behavior单独配置扩缩行为
        scaleUp:
          stabilizationWindowSeconds: 0  # 扩容没有稳定窗口,满足条件 立刻扩容
          policies:
          - type: Percent     #以下策略表示在15s内，最多扩容当前实例数的9倍
            value:  900
            periodSeconds: 15

   2. 快速扩容，缓慢缩容；业务在流量高峰期后，并发量骤降的场景中，如果使用默认的缩容策略，几分钟后Pod的数量也会随着骤降，此时如果又迎来流量高峰，扩容过程需要一段时间，这段时间内造成业务后端处理能力达到瓶颈，将导致部分请求失败。可以为HPA配置behavior缩容策略，快速缩容之后缓慢缩容。

      behavior:                # 通过该字段单独配置扩缩行为
        scaleDown:
          policies:
          - type: Pods        #表示每600s删除一个pod
            value: 1
            periodSeconds: 600
        scaleUp:
          policies:
          - type: Percent        #表示在15s之内，扩容当前实例数的9倍
            value: 900
            periodSeconds: 15

   3. 禁止自动缩容。对于扩容后需要禁止自动缩容的关键业务应用，需要人工干预或者其他方式进行缩容，可以使用如下策略禁止缩容

      behavior:                  #通过该字段单独配置扩缩行为
        scaleDown:
          selectPolicy: Disabled    #selectPolicy 的值 Disabled 会关闭对给定方向的缩容，使用该策略，将会阻止缩容

   4. 延长缩容时间窗。缩容的稳定窗口默认是5分钟，如果需要延长时间窗口以避免一些流量毛刺，可以配置以下策略

      behavior:      #通过该字段可单独配置扩缩行为
        scaleDown:
          stabilizationWindowSeconds: 600   #等待600s后 在开始缩容
          policies:
          - type: Pods
            value: 5    # 每次只缩容5个Pod

      
      

      ---

2.  HorizontalPodAutoscaler API 也支持容器指标源，这时 HPA 可以跟踪记录一组 Pod 中各个容器的资源用量，进而触发扩缩目标对象的操作。  特性状态： Kubernetes v1.27 [beta]
   1. 如果你有一个 Web 应用和一个执行日志操作的边车容器，你可以基于 Web 应   用的资源用量来执行扩缩，忽略边车容器的存在及其资源用量。

      type: ContainerResource
      containerResource:
        name: cpu
        container: application
        target:
          type: Utilization
          averageUtilization: 60

      HPA 控制器会对目标对象执行扩缩操作以确保所有 Pod 中 application 容器的平均 CPU 用量为 60%。