Golang高并发服务在Kubernetes上跑不稳，90%问题出在探针配置、监听地址、资源限制三处：readiness/liveness需分端口分路径独立暴露；监听地址必须为0.0.0.0:8080而非127.0.0.1；resources需设requests=limits确保Guaranteed QoS。
直接上结论：Golang高并发服务在 Kubernetes 上跑不稳，90% 的问题出在探针配置、监听地址、资源限制三处，不是代码写得不够快，而是没对齐 Pod 生命周期。
readinessProbe 和 livenessProbe 必须分端口、分路径、分逻辑
Kubernetes 不看你的 goroutine 数量，只认 HTTP 返回码。用 Gin/Echo 之类框架把 /healthz 和 /readyz 塞进主路由链里，等于把健康检查交给中间件、日志、鉴权甚至 DB 连接池——一旦中间件卡住或 DB 暂时不可达，readinessProbe 就失败，流量被切走，但实际服务可能只是慢了一点。
- 正确做法是启动一个独立的
http.ServeMux，监听另一个端口（比如:8081），只挂两个 handler：/healthz立即返回 200，/readyz做最小依赖检查（如本地 channel 是否可写、gRPC 连接是否 active） - Deployment 中必须显式声明两个
containerPort，并在探针中指定port: 8081 - 避免复用同一路径：liveness 不该检查 DB，否则一次数据库抖动就触发重启；readiness 必须检查真实依赖，否则扩容后立刻涌入流量导致雪崩
监听地址必须是 0.0.0.0:8080，不是 127.0.0.1:8080
Pod 的 IP 是网卡地址，Kubernetes Service 流量通过 iptables 或 eBPF 转发到 Pod IP + 端口。如果你的 Go 服务只监听 127.0.0.1:8080，那外部流量根本进不来，readinessProbe 永远超时，Pod 卡在 ContainerCreating 或反复重启。
- 检查代码中
http.ListenAndServe的第一个参数：必须是":8080"或"0.0.0.0:8080"，不能带127.0.0.1 - 如果用了
net/http.Server，确认Addr字段没硬编码为 loopback - 本地测试时用
curl http://localhost:8080成功 ≠ Kubernetes 内可用，得进容器curl http://127.0.0.1:8080和curl http://<pod-ip>:8080</pod-ip>都通才算
资源 requests/limits 设置不当会放大并发抖动
Golang 的 GC 和调度器对 CPU 时间片很敏感。设了 limits.cpu: "100m" 但没设 requests，Kubernetes 可能把它塞进一个满载节点，CPU 被抢占，goroutine 调度延迟飙升，pprof 显示大量 GC sweep wait 和 netpoll block。
立即学习“go语言免费学习笔记（深入）”；
- 高并发场景下，
requests和limits最好一致，例如cpu: "500m"+memory: "256Mi"，确保 QoS class 是Guaranteed - 内存 limit 别设太紧：Golang runtime 会预留额外空间用于 GC heap metadata，
runtime.ReadMemStats中的Sys通常比Alloc高 30%～50% - 别信“Go 很轻量”就随便设
memory: "64Mi"——一个带 TLS 的 HTTP server 启动后常驻内存就超 40Mi
Dockerfile 用 scratch 镜像但忘了禁用 CGO
用 FROM scratch 是为了安全和体积，但如果编译时没关 CGO_ENABLED=0，二进制会动态链接 libc，运行时报错 standard_init_linux.go:228: exec user process caused: no such file or directory，Pod 直接 CrashLoopBackOff。
- 构建阶段必须加
CGO_ENABLED=0 GOOS=linux go build，且GOOS=linux不能省——macOS 或 Windows 上交叉编译必须显式指定 - 别用
alpine当运行镜像来“绕过”这个问题：alpine 用的是 musl libc，和标准 glibc ABI 不兼容，某些 cgo 依赖（如 sqlite、openssl）会静默失败 - 验证方式：进容器执行
ldd /main，输出应为not a dynamic executable
最易被忽略的一点：HPA（Horizontal Pod Autoscaler）扩缩容依据的是 CPU 或内存指标，但 Golang 高并发服务的真实瓶颈常是 goroutine 阻塞、channel 积压或 netpoll 超时——这些不会反映在 CPU 使用率上。真要靠并发量扩缩，得暴露自定义指标（如 http_in_flight_requests）并接入 Prometheus + kube-metrics-adapter，而不是只盯着 cpu.utilization。
