Go服务被Kubernetes HPA自动扩缩容的关键是暴露Prometheus格式指标端点（如/metrics），并由metrics-server或prometheus-adapter将其转换为Metrics API；HPA本身不拉取指标，仅通过API查询，因此需确保指标名、标签、命名空间在prometheus-adapter规则中精确匹配。
Go 服务要被 Kubernetes HPA（Horizontal Pod Autoscaler）自动扩缩容，关键不是“用 Go 写个适配器”，而是让服务暴露符合 metrics.k8s.io（Resource Metrics API）或 custom.metrics.k8s.io（Custom Metrics API）规范的指标端点，并确保指标能被 metrics-server 或 prometheus-adapter 正确采集。Go 本身不直接参与 HPA 决策逻辑，它只负责提供可被拉取的指标数据。
Go 服务需暴露 Prometheus 格式指标端点
HPA 自身不拉指标，它依赖外部组件（如 metrics-server 或 prometheus-adapter）来获取指标。而这些组件绝大多数都从 Prometheus 兼容的 HTTP 端点（如 /metrics）抓取原始数据。因此你的 Go 服务必须暴露标准 Prometheus 格式指标。
- 使用
prometheus/client_golang库注册指标并启动 HTTP handler - 至少暴露一个 HPA 可用的指标，例如
http_requests_total（计数器）或自定义的go_app_queue_length（Gauge） -
端口需在 Pod 的
container.ports中声明，且 Service 需将该端口暴露（通常走同一端口或通过额外端口） - 避免将指标端点放在需要认证/鉴权的路径下——
metrics-server默认不带 token 或 header 去拉指标
package mainimport ( "log" "net/http" "time"
"github.com/prometheus/client_golang/prometheus" "github.com/prometheus/client_golang/prometheus/promhttp")
var ( queueLength = prometheus.NewGauge(prometheus.GaugeOpts{ Name: "go_app_queue_length", Help: "Current length of request processing queue", }) )
func init() { prometheus.MustRegister(queueLength) }
func main() { http.Handle("/metrics", promhttp.Handler())
go func() { for range time.Tick(1 * time.Second) { queueLength.Set(float64(len(pendingRequests))) // 示例逻辑 } }() log.Println("Starting server on :8080") log.Fatal(http.ListenAndServe(":8080", nil))}
立即学习“go语言免费学习笔记（深入）”；
HPA 要求指标必须通过 metrics-server 或 prometheus-adapter 暴露为 API
即使 Go 服务已暴露
/metrics，HPA 也无法直接读取它。Kubernetes 的 HPA 控制器只查询集群内的 Metrics API（metrics.k8s.io或custom.metrics.k8s.io），这些 API 必须由对应的服务提供。
-
metrics-server：仅支持 CPU/memory 这类资源指标（cpu,memory），不支持你 Go 服务里自定义的go_app_queue_length - 要使用自定义指标（如 QPS、队列长度），必须部署
prometheus-adapter，并配置它从你的 Go 服务（或 Prometheus）拉取指标，再转换为custom.metrics.k8s.ioAPI - 确认
prometheus-adapter的rules配置中包含匹配你指标名和标签的 rule，例如匹配go_app_queue_length{pod=~"my-app-.*"} - 检查
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1"是否返回正常，再查具体指标：kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/*/go_app_queue_length"
编写 HPA YAML 时注意指标类型与 target 类型匹配
HPA 的 metrics 字段写法取决于你用的是资源指标还是自定义指标，也取决于目标值是平均值（AverageValue）、每 Pod 平均值（AverageUtilization）还是绝对值（Value）。写错会导致 HPA 报错 failed to get metric value 或 invalid metric specification。
- 对
metrics-server提供的 CPU 指标，用resource类型 +AverageUtilization（如targetAverageUtilization: 70） - 对
prometheus-adapter提供的自定义指标，必须用object或pods类型；若按 Pod 扩容，选pods，target写averageValue（不是value） - 确保
metric.name和metric.selector.matchLabels（如果用了）与prometheus-adapter规则中定义的完全一致（大小写、下划线）
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: my-go-app-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: my-go-app
minReplicas: 1
maxReplicas: 10
metrics:
- type: Pods
pods:
metric:
name: go_app_queue_length
target:
type: AverageValue
averageValue: 10调试常见失败点：指标查不到、HPA status 显示 unknown 或 missing metrics
HPA 不工作时，90% 的问题出在指标链路断点上，而不是 Go 代码本身。逐层验证比重写 Go 逻辑更有效。
- 确认 Go 服务
/metrics端点可被集群内访问：kubectl exec -it some-pod -- curl -s http://my-go-svc:8080/metrics | grep go_app_queue_length - 确认
prometheus-adapter日志中无 scrape error，且其/readyz返回 200 - 执行
kubectl get hpa my-go-app-hpa -o wide，看AGE列是否更新，CONDITIONS是否含ValidMetricTrue - 若显示
failed to get pod metrics for custom metrics，大概率是prometheus-adapter的 rules 没覆盖到你的指标，或 label 不匹配（比如忘了加{namespace="default"}） - 注意：HPA 每 30 秒同步一次指标，刚部署完等一等，别立刻判定失败
真正卡住的地方往往不在 Go 怎么写指标，而在 prometheus-adapter 的 rules 表达式是否精确匹配了你的指标名、标签和命名空间上下文——少一个花括号或拼错一个下划线，整个链路就静默失效。
