《从CPU到RPS：HPA避坑指南，让弹性伸缩不再“空转”》
在云原生时代，Horizontal Pod Autoscaler (HPA) 是实现应用弹性的核心组件。我们习惯了基于 CPU 或内存使用率来触发扩容，这看似简单有效，但你是否遇到过这样的场景：CPU 使用率早已飙升，自动扩容的 Pod 也已就绪，但用户依然抱怨网站卡顿、接口超时？
这就是典型的“指标失真”问题。CPU 高涨，很可能只是因为应用正在费力地处理堆积的请求，其本身已经成为瓶颈。此时扩容，虽然分担了部分负载，但用户体验的损伤已经发生。我们只是在弥补，而非预防。
是时候将目光转向应用层指标了，而 RPS 是一个绝佳的起点。
RPS代表每秒请求数，它直接反映了应用的真实流量压力。基于 RPS 的 HPA 策略，意味着我们可以在流量洪峰真正压垮应用之前就提前扩容。例如，当单个 Pod 的 RPS 从平时的 50 平稳升至 100 时，即可触发扩容动作，此时系统仍有充足的余量来处理扩容期间的流量增长，实现丝滑般的用户体验。
如何实现？
- 部署 Metrics Server：这是基础，用于采集核心资源指标。
- 集成 Prometheus 与 Prometheus Adapter：Prometheus 负责收集应用暴露的自定义指标（如 Nginx/应用自身的 RPS），Adapter 则负责将这些指标转换成 Kubernetes API 能够识别的格式。
- 配置 HPA：不再只依赖
resource类型，而是创建基于object或pods类型的 HPA。
一个示例 HPA YAML 片段如下：
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: my-app-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: my-app
minReplicas: 2
maxReplicas: 10
metrics:
- type: Object
object:
metric:
name: requests_per_second
describedObject:
apiVersion: v1
kind: Service
name: my-app-service
target:
type: Value
value: 100 # 当该Service对应的RPS总值超过100时，开始扩容
总结
从资源层指标（CPU）转向应用层指标（RPS），是运维理念的一次重要升级。它让弹性伸缩从“事后补救”变为“主动防御”，真正保障了业务的流畅与稳定。下次配置 HPA 时，不妨问自己一句：我是在缩放“机器”，还是在缩放“业务”？
