knative 不是配置在 go 服务里的组件，而是通过 knative serving 的 autoscaler 统一调度扩缩容；go 服务需暴露 /healthz 和 /metrics 端点，/healthz 必须返回 http 200 且响应极快。
直接说结论：Knative 不是“配置在 Go 服务里”的东西，而是你把 Go 微服务部署进 Knative 环境后，由 Knative Serving 的 Autoscaler 统一调度扩缩容——Go 代码本身几乎不用改，但必须满足几个硬性接口契约。
暴露 /healthz 和 /metrics 是前提，不是可选项
Knative 的 Autoscaler 和 Activator 都依赖这两个端点做决策：
-
/healthz必须返回 HTTP 200，且响应极快（ -
/metrics不需要自己实现 Prometheus 格式——Knative 的queue-proxy容器会自动采集并上报并发请求数、延迟等核心指标；但如果你用自定义指标（比如业务队列长度），就得用prometheus/client_golang注册并暴露 - 别用
/debug/pprof替代/healthz，它响应慢、路径不标准，Knative 会反复重启你的 Pod
部署时必须加 Revision 级 annotations，否则 KPA 不生效
Knative 默认用 KPA（Knative Pod Autoscaler）而非 Kubernetes 原生 HPA，它的行为由 Revision 的 annotation 控制，不是 Deployment 或 Service 层面的配置：
-
autoscaling.knative.dev/minScale: "1"—— 即使没流量也至少保留 1 个 Pod；设为"0"才启用 scale-to-zero -
autoscaling.knative.dev/maxScale: "10"—— 硬性上限，防止突发流量打爆集群 -
autoscaling.knative.dev/target: "10"—— 这是并发请求数（Concurrency）目标值，不是 CPU 百分比；意思是“每个 Pod 平均处理 10 个并发请求”，KPA 会据此算出需要多少 Pod - 如果想按 QPS 扩缩，得配
metrics.knative.dev/requests-per-second类型指标，并确保 Prometheus 已接入 Knative 的指标 pipeline
Go 服务必须支持优雅退出，否则缩容时丢请求
Knative 缩容时发的是 SIGTERM，不是 SIGKILL。你的 Go 服务必须在收到信号后：
- 立刻关闭 listener，拒绝新连接
- 等待正在处理的 HTTP 请求完成（用
http.Server.Shutdown()，超时建议设 30s） - 向
queue-proxy发送就绪状态变更（通常通过/healthz返回 503 实现） - 别在
main()末尾加os.Exit(0)—— 这会让Shutdown()被跳过，导致连接被粗暴中断
scale-to-zero 场景下，Activator 是必经链路，Go 服务不能绕过它
当 Pod 数为 0 时，所有请求先到 Activator，再由它触发冷启动。这意味着：
- 你的 Go 服务启动时间必须足够短（建议
- 别在
init()里做重 IO（如加载大文件、连外部 DB），这些应移到main()启动后按需懒加载 - Activator 会代理健康检查，所以
/healthz在冷启动期间必须能快速响应 200，哪怕后端还没完全 ready - 如果用了 Istio，确认
istio-sidecar-injector没干扰queue-proxy的指标上报路径
真正容易被忽略的不是怎么写 Go 代码，而是 Knative 的指标采集链路是否完整：从 queue-proxy → autoscaler-metrics → autoscaler，中间任一环节断开（比如 RBAC 权限不足、网络策略拦截、Prometheus 抓取失败），KPA 就会退化成只看 CPU 的模式，失去基于请求的弹性能力。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
