本文分享自华为云社区《HPA各关联组件扭转关系以及建议》，作者：可以交个朋友。
一、背景
应用程序的使用存在波峰波谷现象，在应用流量处于低谷期间，可以释放因过多的Pod而浪费的硬件资源。在应用流量高峰期提供弹性足够的Pod处理流量。
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: 60HPA 控制器会对目标对象执行扩缩操作以确保所有 Pod 中 application 容器的平均 CPU 用量为 60%。