golang项目上kubernetes部署失败的核心卡点是镜像未静态编译（cgo_enabled=0缺失）、探针路径不存在或混用、监听地址非0.0.0.0、未捕获sigterm实现优雅关闭，任一出错即导致pod反复重启、5xx错误或服务不可达。
直接上结论：Golang项目上 Kubernetes 不是“写完代码 push 就完事”，核心卡点在镜像构建是否静态、探针路径是否存在、监听地址是否为 0.0.0.0、以及进程是否响应 SIGTERM。四个环节任一出错，都会导致 Pod 反复重启、流量 5xx、滚动更新失败或服务不可达。
CGO_ENABLED=0 必须出现在构建命令里，不能只靠环境变量
常见错误现象：standard_init_linux.go:228: exec user process caused: no such file or directory——这是 Alpine 镜像找不到 glibc 的典型报错。很多团队用 golang:alpine 构建，却没关 CGO，结果二进制依赖 glibc，而 Alpine 用的是 musl libc。
正确做法是把 CGO_ENABLED=0 明确写进 RUN 指令中：
FROM golang:1.22-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-s -w' -o main .
-
GOOS=linux确保跨平台兼容（即使本地是 macOS/Windows） -
-s -w剥离调试符号和 DWARF 信息，体积减少 30%+，且防逆向 - 别信 Docker 构建参数（如
--build-arg CGO_ENABLED=0），它不保证生效；必须在RUN中显式设置
readinessProbe 和 livenessProbe 路径必须分离且真实存在
Deployment 里两个探针共用 /healthz 是高频误配。Kubernetes 不会区分语义，只要 HTTP 返回非 2xx 就按配置动作：liveness 失败 → 重启 Pod，readiness 失败 → 摘流量。
你代码里至少得暴露两个独立端点：
http.HandleFunc("/livez", func(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(http.StatusOK)
})
http.HandleFunc("/readyz", func(w http.ResponseWriter, r *http.Request) {
// 这里可加 DB ping、下游健康检查等逻辑
if err := db.Ping(); err != nil {
http.Error(w, "DB unreachable", http.StatusServiceUnavailable)
return
}
w.WriteHeader(http.StatusOK)
})
-
livenessProbe应轻量、快速、只判进程存活（比如/livez），timeoutSeconds建议设为 1–2 秒 -
readinessProbe可重一点（比如/readyz），initialDelaySeconds至少 5 秒，避免启动未完成就被标记就绪 - 千万别让 readiness 检查失败触发 liveness 重启——DB 临时抖动就会引发雪崩
Go 服务必须监听 0.0.0.0:8080，且捕获 SIGTERM 做 graceful shutdown
错误写法：http.ListenAndServe("127.0.0.1:8080", nil) 或 http.ListenAndServe(":8080", nil)（后者在某些 Go 版本下仍可能绑定到 loopback）。
必须显式指定：
srv := &http.Server{
Addr: "0.0.0.0:8080",
Handler: mux,
}
go func() {
if err := srv.ListenAndServe(); err != http.ErrServerClosed {
log.Fatal(err)
}
}()
quit := make(chan os.Signal, 1)
signal.Notify(quit, os.Interrupt, syscall.SIGTERM)
- 监听
0.0.0.0是为了让 Kubernetes 的 kube-proxy 能把流量转发进来；Pod IP 是网卡地址，不是 localhost -
srv.Shutdown()必须带 context 超时，否则可能卡住；超时值要略大于最长请求处理时间（如 30 秒） - Shutdown 返回后，再关闭 DB 连接池、Redis 客户端等资源；顺序颠倒会导致 panic 或连接泄漏
Deployment 配置里最容易漏掉的三项硬性要求
很多人写了 Deployment YAML 就以为齐活了，但以下三项不填，上线后必踩坑：
-
resources.requests和resources.limits必须同时设：Kubernetes 调度器靠requests分配节点，limits控制 OOM Kill 边界；只设一个等于没设 -
securityContext.runAsNonRoot: true+runAsUser：scratch 镜像没有 root 用户，不设这个会卡在CreateContainerConfigError -
terminationGracePeriodSeconds: 45：默认 30 秒不够 Shutdown 走完，尤其有长连接或批量任务时；设成 45–60 更稳妥
真正麻烦的从来不是“怎么部署”，而是“为什么部署后不工作”——问题往往藏在静态编译开关、探针路径拼写、监听地址、信号处理这四条线上，每一条都得亲手验证，不能靠经验跳过。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
