go服务hpa扩容不能只看cpu 70%，因gc峰值、goroutine阻塞或网络缓冲区打满时cpu可能仅45%就已失能；应优先采用go_goroutines、平均gc pause、错误率与p99延迟等自定义指标，并调低stabilizationwindowseconds以提升扩缩容灵敏度。
HPA 扩容阈值不能只看 CPU 70% —— 实际压测中，Go 服务常因 GC 峰值、goroutine 阻塞或网络缓冲区打满而提前失能，此时 CPU 可能才刚到 45%。
Go 应用压测时为什么 CPU 指标容易误判
Go runtime 的调度模型和 GC 行为会让 CPU 使用率与真实服务能力脱钩。比如：
- 大量短生命周期 goroutine 创建/销毁 →
runtime.sched和runtime.mallocgc占用高 CPU，但业务吞吐未提升 - GC STW 阶段虽短，但会卡住所有 P，导致请求堆积、P99 延迟飙升，此时
top看 CPU 可能反降 - HTTP server 的
net/http.Server.ReadTimeout或WriteTimeout不足时，连接堆积在内核 socket buffer，ss -s显示recv-q持续 > 0，但cpu_usage无明显变化
所以仅靠 metrics-server 上报的 cpu_utilization 做 HPA 判断，大概率扩晚了、扩少了。
Go 服务推荐采集的 HPA 自定义指标
用 Prometheus + prometheus-operator + custom-metrics-apiserver 暴露以下指标，比 CPU 更早反映瓶颈：
-
go_goroutines：持续 > 5000 且增长斜率 > 200/sec，说明协程泄漏或阻塞严重 -
go_gc_duration_seconds_sum/go_gc_duration_seconds_count→ 计算平均 GC pause 时间，> 5ms 就需警惕 -
http_server_requests_total{code=~"5..|429"}+rate(http_server_request_duration_seconds_sum[1m])→ 结合错误率和延迟，比 QPS 更准 -
process_open_fds：接近fs.file-max时，新连接会失败，但 CPU 几乎不涨
注意：custom-metrics-apiserver 的 metricRelistInterval 建议设为 20s，避免指标延迟导致 HPA 决策滞后。
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
HPA behavior 配置必须调低 stabilizationWindowSeconds
Go 服务响应快、扩容后“热启动”快（无 JVM warmup），默认缩容 300 秒太保守，容易在流量回落初期就缩过头：
-
scaleDown.stabilizationWindowSeconds: 60（而非默认 300）—— 缩容更灵敏 -
scaleUp.stabilizationWindowSeconds: 30（而非默认 60）—— 扩容更激进 -
policies中优先用type: Pods而非Percent，例如- type: Pods; value: 3，避免小规模 Deployment（如 minReplicas=2）扩 20% 只加 0.4 个 Pod 导致不扩容
同时确保 metrics-server 的 --metric-resolution=15s，否则 HPA controller 拿不到最新数据。
压测时如何确定真实扩容阈值
不要用单次峰值压测定阈值，要跑三轮：
- 第一轮：固定并发（如 200 RPS），观察
go_goroutines和http_server_request_duration_seconds_p99开始爬升的拐点（比如 RPS=800 时 P99 从 80ms → 220ms） - 第二轮：阶梯式加压（每 30 秒 +100 RPS），记录从拐点到
5xx错误率突破 1% 的区间（比如 800→950 RPS），取中位数 875 作为目标负载 - 第三轮：在目标负载下持续 5 分钟，确认
go_gc_duration_seconds_sum / go_gc_duration_seconds_countprocess_open_fds go_goroutines 稳态波动
最终 HPA 的 averageValue（如 requests_per_second）就设为该稳态 RPS × 1.2，留出缓冲；minReplicas 至少等于压测时达到稳态所需的最小 Pod 数。
真正难的不是写对 YAML，而是让 Go runtime 的行为暴露在指标里——没暴露的指标，HPA 就永远看不见瓶颈在哪。
