AKS中如何实现基于每秒请求数的HPA自动扩缩容

首先明确：AKS默认捆绑的Metrics Server无法直接实现基于每秒请求数（RPS）的扩缩容，但有成熟的生产可用方案可以满足需求，不需要侵入修改集群托管组件。

为什么默认Metrics Server不支持该能力 #

Metrics Server是Kubernetes官方的核心指标采集组件，仅负责采集节点、Pod维度的CPU、内存利用率这类基础资源指标，本身不具备采集、存储业务层/接入层请求量、RPS这类自定义指标的能力，所以原生HPA默认只提供CPU、内存的扩缩容配置入口，不是配置缺失，是组件本身的能力边界决定的。

不要尝试手动修改AKS托管的Metrics Server配置强行接入自定义指标，该组件是AKS全托管的系统组件，手动修改的配置会在集群版本升级、补丁更新时被自动重置，还可能引发核心指标采集异常，影响集群基础弹性能力。

可落地的实现路径 #

方案1：启用KEDA加载项（官方推荐，运维成本最低） #

KEDA是CNCF毕业的Kubernetes事件驱动弹性组件，AKS已经提供官方托管的KEDA集群扩展，不需要手动部署维护，是实现RPS扩缩容的首选方案：

• 直接在AKS集群上启用KEDA扩展，组件升级、可用性都由Azure托管
• 如果你使用AKS自带的Nginx Ingress、Application Gateway入口控制器（AGIC），这类组件默认会暴露每个后端服务的RPS监控指标，KEDA可以直接拉取这类指标作为扩缩容判断依据
• 如果你是自行部署的服务，只要服务本身暴露Prometheus格式的RPS接口指标，KEDA也可以直接对接Prometheus服务抓取指标
• 不需要使用原生HPA资源，只需要创建ScaledObject自定义资源，配置最小/最大副本数、单Pod RPS阈值、扩缩容冷却窗口即可完成配置，示例配置片段如下：

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: api-service-rps-scaler
spec:
  scaleTargetRef:
    name: api-service # 要扩缩容的工作负载名称
  minReplicaCount: 2
  maxReplicaCount: 20
  triggers:
  - type: prometheus # 可替换为你实际使用的Ingress对应触发器类型
    metadata:
      serverAddress: http://kube-prometheus-stack-prometheus.monitoring.svc.cluster.local:9090
      metricName: http_requests_per_second
      threshold: "100" # 单Pod承载100RPS时触发扩容
      query: sum(rate(http_requests_total{service="api-service"}[1m]))

方案2：部署自定义指标适配器对接原生HPA #

如果你希望继续使用原生HPA而不是KEDA，可以部署对应指标体系的自定义指标适配器（比如Prometheus Adapter），将RPS指标注册到Kubernetes的自定义指标API组，配置完成后原生HPA就可以像配置CPU阈值一样，直接指定RPS作为扩缩容判断指标。
该方案需要你自行维护指标采集链路、适配器组件的可用性和版本兼容，运维复杂度比直接启用KEDA托管加载项高，适合对现有弹性管线有强定制需求的场景。

内容的提问来源于stack exchange，提问作者GilliVilla