Kubernetes HPA自定义指标扩缩容：从Prometheus Adapter到生产部署全流程

HPA默认指标的局限性

Kubernetes自带的Horizontal Pod Autoscaler基于CPU和内存利用率做扩缩容，对于Web应用和REST API场景基本够用。但在实际网站运维中，很多业务的关键指标不是CPU而是请求延迟、队列深度、连接数等。一个消息消费服务CPU利用率只有30%，但消息积压已经超过10万条——默认HPA完全感知不到这种压力。

DevOps实践要求扩缩容策略与业务指标强绑定，而不是和资源利用率绑定。自定义指标HPA是解决这个问题的标准方案。

架构：Prometheus Adapter + HPA的数据链路

自定义指标HPA的完整数据链路：

应用暴露指标 → Prometheus采集 → Prometheus Adapter转换为自定义指标API → HPA Controller查询并决策扩缩

Prometheus Adapter是整个链路的核心组件，它实现了Kubernetes的custom.metrics.k8s.io API，把Prometheus中的指标数据映射为Kubernetes可识别的自定义指标。

部署Prometheus Adapter

使用Helm部署是最省事的方式：

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm install prometheus-adapter prometheus-community/prometheus-adapter \
  --namespace monitoring \
  --create-namespace \
  --set prometheus.url=http://prometheus-server.monitoring.svc \
  --set prometheus.port=80

kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1 | jq .

配置自定义指标映射规则

Prometheus Adapter的核心配置是规则映射，定义如何把PromQL查询结果转换为Kubernetes自定义指标：

rules:
  custom:
    - seriesQuery: 'http_requests_total{namespace!="",pod!=""}'
      resources:
        overrides:
          namespace: {resource: "namespace"}
          pod: {resource: "pod"}
      name:
        matches: "http_requests_total"
        as: "http_requests_per_second"
      metricsQuery: 'sum(rate(<<.Series>>{<<.LabelMatchers>>},[2m])) by (<<.GroupBy>>)'

配置更新后重启Adapter Pod：

kubectl rollout restart deployment/prometheus-adapter -n monitoring
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/*/http_requests_per_second" | jq .

创建自定义指标HPA

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-server-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "500"
    - type: Pods
      pods:
        metric:
          name: http_request_p99_latency
        target:
          type: AverageValue
          averageValue: "0.5"
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Pods
          value: 1
          periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Pods
          value: 4
          periodSeconds: 60
        - type: Percent
          value: 100
          periodSeconds: 60

混沌工程验证扩缩容效果

扩缩容策略上线前，用混沌工程注入流量峰值验证HPA响应速度：

helm install chaos-mesh chaos-mesh/chaos-mesh \
  --namespace chaos-testing --create-namespace

观察HPA事件日志：

kubectl get hpa api-server-hpa -w
kubectl describe hpa api-server-hpa | grep -A10 Events

常见问题与排查路径

HPA无法获取自定义指标

kubectl api-resources | grep custom.metrics
kubectl logs -n monitoring -l app=prometheus-adapter --tail=100

扩缩容抖动

指标波动导致频繁扩缩容，通过behavior字段配置冷却期和步长限制是标准解法。另外，PromQL中使用rate()或avg_over_time()做时间窗口平滑也能有效降低波动。

监控告警体系：HPA自身也需要监控

- alert: HPAReachedMaxReplicas
  expr: |
    kube_hpa_status_current_replicas == kube_hpa_status_desired_replicas
    and kube_hpa_status_desired_replicas == kube_hpa_spec_max_replicas
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: "HPA已达到最大副本数"

自定义指标HPA从部署到稳定运行，核心工作量不在安装配置而在指标规则调试。建议先用kubectl get --raw反复验证Adapter返回的指标值是否符合预期，再创建HPA对象。故障应急响应时，HPA的扩容决策日志是定位容量问题的第一手数据。