HPA 要求 Go 应用 Deployment 必须声明 resources.requests，否则 HPA 无法工作并显示 Unknown 状态；必须使用 autoscaling/v2 API 支持多指标与 behavior 防抖；Go 服务需通过 prometheus/client_golang 暴露 /metrics 并正确打点 http_requests_total，配合 Prometheus Adapter 才能实现基于 QPS 的扩缩容。
HPA 要求 Go 应用 Deployment 必须声明 resources.requests
HPA 无法对未设置 resources.requests 的 Pod 做 CPU/内存扩缩容——这不是 bug，是 Kubernetes 的硬性要求。如果你的 Go 服务 Deployment 没配 requests，执行 kubectl autoscale 或应用 HPA YAML 后，kubectl get hpa 会显示 Unknown 状态，且 Conditions 中提示 MetricsNotAvailable。
必须在容器 spec 中至少声明 cpu 和/或 memory 的 requests：
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 512Mi
- 只设
limits不设requests无效 -
requests值不一定要精准，但必须存在；它用于归一化计算利用率（例如 CPU 利用率 = 实际使用 / request） - Go 服务通常轻量，
100mCPU 和128Mi内存是安全起点
用 autoscaling/v2 配置 HPA 才能支持多指标和 behavior 控制
别用已弃用的 autoscaling/v1。v1 只支持 CPU，且无法配置缩容延迟、扩容步长等关键参数，极易引发抖动。生产环境必须用 autoscaling/v2。
典型配置示例（同时监控 CPU 和自定义 QPS）：
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: go-app-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: go-app
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 60
- type: Pods
pods:
metric:
name: http_requests_per_second
target:
type: AverageValue
averageValue: 100
behavior:
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Percent
value: 10
periodSeconds: 60
scaleUp:
stabilizationWindowSeconds: 60
policies:
- type: Percent
value: 100
periodSeconds: 60
-
behavior是防抖核心：缩容慢（5 分钟稳定窗口）、扩容快（1 分钟），避免流量尖峰后立刻缩容又立刻扩容 -
Pods类型指标需配合 Prometheus Adapter 或 KEDA；Go 服务需暴露http_requests_total并用rate()计算 QPS - 两个指标独立触发伸缩，HPA 取「最激进」结果（即最终副本数 = max(各指标建议值)）
Go 服务必须暴露 Prometheus 指标才能用自定义 QPS 扩缩容
仅靠 HPA 配置无法让 http_requests_per_second 生效——Go 进程本身得提供可采集的指标端点。否则 Prometheus Adapter 查询不到数据，HPA 会持续报 FailedGetMetrics。
最小可行实践：
- 引入
prometheus/client_golang，在 HTTP server 中注册/metricshandler - 用
promhttp.Handler()暴露标准指标，同时手动记录业务指标，例如：httpRequestsTotal := prometheus.NewCounterVec(...) - 在 HTTP middleware 中调用
httpRequestsTotal.WithLabelValues(method, path).Inc() - 确保容器内
curl http://localhost:8080/metrics能返回文本格式指标（含http_requests_total行）
验证是否被 Prometheus 正确抓取：kubectl port-forward svc/prometheus 9090 → 浏览器打开 http://localhost:9090 → 输入表达式 sum(rate(http_requests_total[2m]))，应有非零数值。
HPA 不会立即响应，等待周期和指标延迟是常态
从负载上升到 HPA 触发扩容，通常要经历：指标采集间隔（Metrics Server 默认 60s）→ HPA 检查周期（默认 15s）→ 计算 + API 调用 → Deployment 更新 → 新 Pod 启动就绪。整个链路至少 2–3 分钟，不是秒级反应。
常见误判场景：
- 刚加完 HPA 就压测，
kubectl get hpa显示Current CPU Utilization: <unknown></unknown>→ 等 1–2 分钟再查 - 压测停止后立刻查 Pod 数，发现没缩容 → 缩容有 5 分钟稳定窗口（
stabilizationWindowSeconds: 300），耐心等 - QPS 指标值始终为 0 → 检查 Go 服务是否真在打点、Prometheus 是否抓到、Adapter 是否把指标名映射正确（如
http_requests_per_secondvshttp_requests_total）
真正难的不是写 YAML，而是让指标流端到端连通、延迟可控、语义准确——每个环节断掉，HPA 就只是个摆设。
