从CPU到RPS：HPA避坑指南，让弹性伸缩不再“空转”

《从CPU到RPS：HPA避坑指南，让弹性伸缩不再“空转”》

在云原生时代，Horizontal Pod Autoscaler (HPA) 是实现应用弹性的核心组件。我们习惯了基于 CPU 或内存使用率来触发扩容，这看似简单有效，但你是否遇到过这样的场景：CPU 使用率早已飙升，自动扩容的 Pod 也已就绪，但用户依然抱怨网站卡顿、接口超时？

这就是典型的“指标失真”问题。CPU 高涨，很可能只是因为应用正在费力地处理堆积的请求，其本身已经成为瓶颈。此时扩容，虽然分担了部分负载，但用户体验的损伤已经发生。我们只是在弥补，而非预防。

是时候将目光转向应用层指标了，而 RPS 是一个绝佳的起点。

RPS代表每秒请求数，它直接反映了应用的真实流量压力。基于 RPS 的 HPA 策略，意味着我们可以在流量洪峰真正压垮应用之前就提前扩容。例如，当单个 Pod 的 RPS 从平时的 50 平稳升至 100 时，即可触发扩容动作，此时系统仍有充足的余量来处理扩容期间的流量增长，实现丝滑般的用户体验。

如何实现？

1. 部署 Metrics Server：这是基础，用于采集核心资源指标。
2. 集成 Prometheus 与 Prometheus Adapter：Prometheus 负责收集应用暴露的自定义指标（如 Nginx/应用自身的 RPS），Adapter 则负责将这些指标转换成 Kubernetes API 能够识别的格式。
3. 配置 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 时，不妨问自己一句：我是在缩放“机器”，还是在缩放“业务”？