本文分享自华为云社区《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/v2kind: HorizontalPodAutoscalermetadata:  name: php-apachespec:  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: ContainerResourcecontainerResource:  name: cpu  container: application  target:    type: Utilization    averageUtilization: 60

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

点击关注，第一时间了解华为云新鲜技术~