kubernetes中运行golang应用必须监听0.0.0.0:8080、配置分离的readinessprobe与livenessprobe、禁用cgo构建静态二进制、严格匹配service selector与pod labels，并正确处理sigterm以实现优雅终止。
直接结论：Kubernetes 中运行 Golang 应用，核心不是“能不能跑”，而是“会不会被反复重启”“流量进不进得来”“更新时有没有请求丢失”。关键配置缺一不可，漏掉 readinessProbe、监听地址写成 127.0.0.1:8080 或没处理 SIGTERM，上线即故障。
Go 服务必须监听 0.0.0.0:8080，不能是 127.0.0.1:8080
Kubernetes 的 Service 流量通过 Pod IP 转发，而 127.0.0.1 只响应本机回环——Ingress 控制器、其他 Pod、甚至同一节点上的 kube-proxy 都无法访问它。
- 错误写法：
http.ListenAndServe("127.0.0.1:8080", nil)→ 502/503 持续出现 - 正确写法：
http.ListenAndServe(":8080", nil)（冒号开头即监听所有接口） - 验证方式：进 Pod 执行
netstat -tuln | grep :8080，应显示*:8080，不是127.0.0.1:8080
readinessProbe 和 livenessProbe 必须分离路径与语义
共用 /health 是线上高频故障源。Kubernetes 不靠进程存活判断服务状态，只信 HTTP 探针返回码；两个探针目的不同，混用会引发雪崩。
-
readinessProbe：用于摘流量，应检查真实就绪依赖（DB 连接、下游服务、缓存连通性），路径如/readyz，timeoutSeconds: 10 -
livenessProbe：用于重启进程，只检查自身 HTTP 服务是否响应，路径如/livez，timeoutSeconds: 2，不查外部依赖 - Deployment 中若两者都指向
/health，DB 暂时抖动会导致livenessProbe失败 → Pod 重启 → 更多连接打向 DB → 加剧抖动
Dockerfile 必须禁用 CGO 并使用静态二进制
Alpine 镜像无 glibc，若构建时未设 CGO_ENABLED=0，运行时报错 standard_init_linux.go:228: exec user process caused: no such file or directory，Pod 卡在 CrashLoopBackOff。
- 构建阶段务必加：
RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-s -w' -o main . - 基础镜像优先选
scratch（非alpine），体积更小、攻击面更窄；若需调试工具，再退选alpine - 别漏
EXPOSE 8080—— 虽不影响实际通信，但部分 Ingress 控制器或安全扫描工具会校验该字段
Deployment 的 selector 和 Pod template.metadata.labels 必须字面完全一致
这是 Service 能把流量打到 Pod 的前提。Kubernetes 不做模糊匹配，大小写、空格、键名差一个字符都会导致 Service “找不到后端”，表现为 503 或连接拒绝。
- Deployment 中的
selector.matchLabels和 Pod 模板里的metadata.labels必须逐字段、逐值相同 - 常见错误：Deployment 写
app: go-api，Pod 模板写app: go_api（下划线 vs 短横）或APP: go-api（大小写） - 验证命令：
kubectl get pods -l app=go-api和kubectl get service go-api -o wide查看ENDPOINTS是否有 IP:PORT 显示
最易被忽略的其实是 SIGTERM 处理——哪怕所有配置都对，没调 http.Server.Shutdown()，滚动更新时活跃请求就会被硬 kill，用户看到的就是 502 或超时。这不是“优雅”的加分项，是生产环境的强制底线。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
