Go应用在Kubernetes中无法自行扩缩容，必须依赖HPA和Cluster Autoscaler；需暴露/healthz（快速健康检查）、/metrics（Prometheus格式指标）、设置resources.requests（如cpu: 100m, memory: 128Mi），三者缺一不可，否则HPA显示unknown或无法触发扩缩容。
Go 应用在 Kubernetes 中无法自行扩缩容，必须依赖平台能力；你真正要做的，是让服务“可被 HPA 和 Cluster Autoscaler 正确识别和调度”。
HPA 扩容前必须暴露的三个端点
HPA 本身不调用你的 Go 服务，但它依赖的 metrics-server 或 prometheus-adapter 会抓取指标，而 kubelet 的探针会高频调用健康端点。漏掉任一环节，扩容就卡在“Pending”或“NotReady”状态。
-
/healthz：只返回200 OK，不查 DB、不发 HTTP 请求，耗时 livenessProbe -
/readyz：检查数据库连接池、Redis 连通性、配置加载完成等；失败返回503；用于readinessProbe，且initialDelaySeconds必须 > 冷启动耗时（比如 DB 连接 + 配置拉取共 8 秒，这里至少设10） -
/metrics：用promhttp.Handler()暴露，注册http_requests_total等 Prometheus 格式指标；注意：默认 HPA 不认这个路径——它只认metrics-server提供的cpu和memory，自定义指标需额外走prometheus-adapter
resources.requests 不写，HPA 就算不准
HPA 计算利用率（如 averageUtilization: 60）的前提是：Pod 有明确的 requests 值。如果你的 Deployment YAML 里没写 resources.requests.cpu 和 resources.requests.memory，HPA 会跳过该 Pod，kubectl get hpa 显示 unknown 或 <waiting for metrics>。
- 典型错误写法：
resources: {}或完全省略resources字段 - 合理值参考：
cpu: 100m（0.1 核）、memory: 128Mi；必须与实际负载匹配，过大导致扩不及时，过小引发频繁扩缩 - Cluster Autoscaler 同样依赖此字段：若 Pod 申请
cpu: 2，而所有节点剩余 CPU requests？它根本不知道该扩什么
用 client-go 创建 HPA 时 metrics 字段最常填错
不是结构体字段名错了，而是 K8s API 版本对字段要求变了。Kubernetes 1.23+ 已废弃 value，改用 averageValue 或 averageUtilization，但很多人仍按旧文档填。
立即学习“go语言免费学习笔记（深入）”；
- type:
Resource（如 cpu）→ 必须填resource.name+target.type: Utilization+target.averageUtilization - type:
Pods或External→ 必须填target.averageValue（不是value），且external.metricName和external.target缺一不可 - 查错方法：
kubectl describe hpa <name>看 Events 字段，常见报错：failed to get memory utilization: unable to get metrics for resource memory: no metrics returned from resource metrics API（说明 metrics-server 没跑或 RBAC 没开）
优雅关闭超时时间必须 ≤ terminationGracePeriodSeconds
Kubernetes 发 SIGTERM 后，只等 terminationGracePeriodSeconds（默认 30 秒），超时直接 SIGKILL。如果你 Go 代码里 Shutdown() 设了 context.WithTimeout(ctx, 60*time.Second)，进程大概率在清理完前就被强杀，DB 连接池、消息消费者全丢。
- YAML 中设
terminationGracePeriodSeconds: 12→ Go 代码中Shutdown()超时必须 ≤12秒（建议10） - 必须显式关闭资源：
db.Close()、consumer.Close()、ticker.Stop()；别在Shutdown()回调里调os.Exit()或log.Fatal()，那会跳过清理 - 所有异步任务（包括
http.Server处理中的请求）都需接收context.Context并响应取消，否则 goroutine 泄漏会导致缩容后残留连接
最易被忽略的其实是无状态前提：只要 Go 服务里还用 sync.Map 存 session、往本地磁盘写日志文件、或靠内存计数器做限流，横向扩容就只是假象——副本越多，数据越不一致。扩缩容不是加几行代码的事，是整个服务设计的约束条件。
