go应用接入kubernetes hpa需满足：设置resources.requests、暴露/metrics端点、配置就绪/存活探针、确保metrics-server正常运行，hpa才能基于cpu或自定义指标自动扩缩容。
你不需要在 Go 代码里“部署自动扩缩容”，Kubernetes 的扩缩容能力（HPA）是独立控制器，Go 应用只需满足几个关键前提，就能被原生接管。
HPA 要求 Go 服务必须设置 resources.requests
HPA 计算 CPU/内存利用率时，分母是 requests，不是节点总资源，也不是 limits。没设 requests？HPA 直接跳过这个 Pod，压根不参与计算。
-
requests必须写在 Deployment 的containers[].resources.requests下，例如：cpu: 100m、memory: 128Mi - 避免只设
limits不设requests—— 这会导致 HPA 报错failed to get cpu utilization: missing request for cpu - 如果用自定义指标（如 QPS），
requests仍需存在，否则 Pod 可能被 Cluster Autoscaler 拒绝调度
暴露 /metrics 端点才能用自定义指标扩缩
仅靠 CPU 利用率扩缩，对 IO 密集或异步处理型 Go 服务往往失真。想按 QPS、请求延迟或队列长度扩缩，必须让 Prometheus 能采集到指标。
Golang Samber Hot
下载
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 用
prometheus/client_golang在 HTTP server 中注册/metricshandler - 确保该端口在容器内可访问，且 Service 的
targetPort正确指向它 - 若使用
external.metrics（如 Kafka 消息积压），需额外部署prometheus-adapter或keda，并确认其能连通你的指标源
创建 HorizontalPodAutoscaler 时别漏掉 scaleTargetRef 和 metrics 字段
用 client-go 或 kubectl apply 创建 HPA 时，结构体或 YAML 缺一不可。v2 版本（推荐）要求显式声明指标类型和目标值，v1 已弃用。
-
scaleTargetRef必须准确指向同 namespace 下已存在的 Deployment，kind写成Deployment，name不能拼错 - 若
metrics中某项type: External，必须同时提供external.metricName和external.target.averageValue，漏任一字段会报Invalid value: "null" - HPA 默认每 15 秒同步一次状态，首次生效可能有延迟；可通过
kubectl get hpa查看CURRENT和DESIRED是否变化
就绪与存活探针影响扩缩容节奏
HPA 扩容后，新 Pod 必须通过 readinessProbe 才能接收流量；缩容前，Kubernetes 会先等 livenessProbe 失败或收到 SIGTERM 后优雅退出。探针配置不当，会导致扩缩容卡住或误杀。
-
readinessProbe建议指向/healthz，返回 200 表示可服务；避免检查外部依赖（如 DB 连通性），否则扩容时大量 Pod 卡在ContainerCreating状态 -
livenessProbe不宜过于激进（如initialDelaySeconds: 5），否则低负载下可能误重启 - Go 服务需监听
SIGTERM并调用http.Server.Shutdown()，否则缩容时连接被粗暴中断
真正容易被忽略的是：HPA 生效的前提是 metrics-server 正常运行，且 kubectl top pods 能查到数据。很多集群里 metrics-server 没装或证书过期，导致 HPA 一直显示 unknown —— 先验证这个，再调 Go 代码。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
