HPA默认指标的局限性与自定义指标需求

Kubernetes原生HPA支持CPU和内存两类资源指标，对无状态Web服务够用，但遇到以下场景会失效：

• 消息队列消费者：扩容依据是队列积压长度而非CPU使用率
• HTTP服务：QPS和P99延迟才是真实负载信号
• GPU推理服务：显存占用和请求并发数决定容量

自定义指标HPA将扩缩容决策从资源维度拉到业务维度，实现更精确的容量弹性。

Prometheus Adapter部署与配置

prometheus-adapter是K8s自定义指标HPA的核心组件，将Prometheus查询结果暴露为K8s API的Metrics API。

部署流程：

# Helm安装
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus-adapter prometheus-community/prometheus-adapter \
  --set prometheus.url=http://prometheus.monitoring.svc:9090 \
  --set prometheus.port=9090 \
  --set rules.default=false \
  -n monitoring

关键配置是自定义指标规则，通过ConfigMap或Helm values注入：

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(http_requests_total{namespace="<<.Namespace>>",pod=~"<<.Pod>>"}[2m])) by (pod)'

seriesQuery定义Prometheus中的指标名和标签，resources.overrides将Prometheus标签映射到K8s资源对象，metricsQuery定义实际执行的PromQL。

HPA策略编写与扩缩容行为控制

规则配置完成后，编写HPA对象：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-api-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-api
  minReplicas: 3
  maxReplicas: 50
  metrics:
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "100"  # 每Pod 100 QPS触发扩容
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
        - type: Percent
          value: 100    # 每次最多翻倍
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300  # 缩容冷却5分钟
      policies:
        - type: Percent
          value: 10     # 每次最多缩10%
          periodSeconds: 120

behavior字段是K8s 1.18+的关键特性，解决默认策略扩容太慢缩容太快的抖动问题。stabilizationWindowSeconds设置决策冷却窗口，policies限制单次调整幅度。

消息队列场景的自定义扩缩容

RabbitMQ或Kafka消费者场景，扩容依据是队列深度：

# Prometheus规则：计算每个消费者的消息积压
- seriesQuery: 'rabbitmq_queue_messages{queue=~"order-process.*",namespace!=""}'
  resources:
    overrides:
      namespace: {resource: "namespace"}
  name:
    as: "rabbitmq_queue_messages"
  metricsQuery: 'rabbitmq_queue_messages{namespace="<<.Namespace>>",queue=~"order-process.*"}'

HPA配置：

metrics:
  - type: External
    external:
      metric:
        name: rabbitmq_queue_messages
        selector:
          matchLabels:
            queue: order-process
      target:
        type: AverageValue
        averageValue: "50"  # 每50条积压消息扩一个Pod

注意：消费者扩容不能超过分区数（Kafka）或并发数限制（RabbitMQ），maxReplicas要配合消费者组的分区数设置上限。

验证与排错清单

部署后按顺序验证：

# 1. 检查自定义指标是否注册
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq .

# 2. 查询具体指标值
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/production/pods/*/http_requests_per_second"

# 3. 检查HPA状态
cubectl describe hpa web-api-hpa -n production

# 4. 查看adapter日志
kubectl logs -n monitoring deploy/prometheus-adapter | tail -50

常见问题：指标名不匹配（adapter配置的name和HPA引用的name必须一致）；PromQL返回空值（检查标签匹配和namespace映射）；metricsQuery语法错误（先在Prometheus UI验证PromQL能返回数据）。

生产环境调优建议

扩缩容延迟由三部分叠加：Prometheus采集间隔（默认30s）+ adapter缓存刷新（默认30s）+ HPA评估周期（默认15s）。最坏情况延迟75秒。对延迟敏感的服务，缩短Prometheus scrape_interval到15s，adapter的--metrics-max-age同步调整。

多指标HPA取最大值决策：同时配CPU和QPS两个metric，任一指标超阈值即扩容。这在流量突增但CPU尚未升高时能更快响应。

避免「扩缩容循环」：缩容后Pod减少导致单Pod负载升高再次扩容。解法是拉长缩容冷却窗口（5-10分钟），并设置缩容步长为10%以内。