本文分享自华为云社区《HPA各关联组件扭转关系以及建议》，作者：可以交个朋友。

一、背景

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

二、HPA各个组件扭转关系

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

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

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

指标是从哪里来的？
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

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

快速扩容，主要防止流量瓶颈；缓慢缩容，主要防止另一个流量高峰。

快速扩容策略配置

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

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

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

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

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

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

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

HorizontalPodAutoscaler API 也支持容器指标源，这时 HPA 可以跟踪记录一组 Pod 中各个容器的资源用量，进而触发扩缩目标对象的操作。特性状态： Kubernetes v1.27 [beta]

如果你有一个 Web 应用和一个执行日志操作的边车容器，你可以基于 Web 应用的资源用量来执行扩缩，忽略边车容器的存在及其资源用量。

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

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

hpa-horizontalpodautoscaler

horizontal autoscaler hpa pod

horizontalpodautoscaler k8s hpa k8

kubernetes工具hpa ab

operator k8s hpa crd

526互联

实践解析HPA各关联组件扭转关系

一、背景

二、HPA各个组件扭转关系

三、指标和指标的来源

四、通过API Aggregation拓展kubernetes API

五、HPA实践建议