Go服务在Kubernetes中启动失败主因是镜像构建、PID 1信号处理及探针配置不当：需用exec格式启动、分离liveness/readiness端点、采用scratch镜像、合理设置资源限制与GOMEMLIMIT。
Go 服务在 Kubernetes 中跑不起来，大概率不是 Go 写得有问题，而是容器镜像构建方式、进程生命周期管理或健康探针配置没对上。
Go 程序必须用 exec 方式启动，不能靠 shell 包装
Kubernetes 的容器生命周期依赖 PID 1 进程直接接收信号（如 SIGTERM）。如果 Dockerfile 里写成 CMD ["sh", "-c", "./app"]，实际 PID 1 是 sh，Go 进程变成子进程，收不到终止信号，导致 kubectl delete 或滚动更新时卡住、超时、连接被重置。
- ✅ 正确：使用 exec 格式，
CMD ["./app"]或ENTRYPOINT ["./app"] - ❌ 错误：使用 shell 格式，
CMD ./app或CMD sh -c "./app" - Go 程序内部建议用
signal.Notify显式监听os.Interrupt和syscall.SIGTERM，并做 graceful shutdown（比如关闭 HTTP server、等待活跃请求完成）
LivenessProbe 和 ReadinessProbe 别共用同一个 HTTP 端点
很多 Go 服务只暴露一个 /health，然后在 Deployment 里把 liveness 和 readiness 都指向它——这会导致 Kubernetes 在服务还没 ready 时就反复重启（liveness 失败触发 kill），形成恶性循环。
- ✅ 建议分离：用
/readyz做 readiness（检查依赖 DB、Redis 是否连通），用/livez做 liveness（只检查进程是否还在响应 HTTP） - Go 里可用
http.HandleFunc("/livez", func(w http.ResponseWriter, r *http.Request) { w.WriteHeader(http.StatusOK) })实现轻量存活检查 - 避免在
/livez里加数据库查询；否则 DB 慢会导致整个 Pod 被误杀 - readiness probe 的
initialDelaySeconds建议设为 5–10s，给 Go 应用完成初始化留出时间（比如加载配置、建立连接池）
镜像体积和运行时安全：优先用 scratch 或 distroless 基础镜像
Go 编译产物是静态二进制，不需要 libc、bash、甚至 /bin/sh。用 alpine 虽小，但带了包管理器和 shell，增加攻击面；用 ubuntu:22.04 更是浪费资源。
立即学习“go语言免费学习笔记（深入）”；
- ✅ 推荐：多阶段构建 +
FROM scratch，例如：
FROM golang:1.22-alpine AS builder WORKDIR /app COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-extldflags "-static"' -o app . <p>FROM scratch COPY --from=builder /app/app /app CMD ["/app"]
- ⚠️ 注意：
scratch镜像里没有strace、ls、sh，调试困难。上线前务必确认日志输出到 stdout/stderr（Kubernetes 默认采集），且错误信息足够明确 - 如果需要调试能力，可用
gcr.io/distroless/static:nonroot替代scratch，它提供最小化工具集且默认以非 root 用户运行
资源限制没设或设得太紧，导致 OOMKilled 或 CPU 节流
Go runtime 对内存回收敏感，requests 和 limits 不匹配时，Kubernetes 可能因 RSS 超限直接 kill 容器（OOMKilled），而 Go 的 GC 却以为还有空间可分配。
- ✅ 设置
resources.limits.memory后，务必同步设置GOMEMLIMIT环境变量（Go 1.19+），例如GOMEMLIMIT="800MiB"，让 runtime 主动限频 GC，避免突发分配触发 OOM - Go 默认会尝试使用全部可用 CPU，但 Kubernetes 的
limits.cpu是 CFS 配额，不是核数。若设limits.cpu: "500m"，Go runtime 仍可能并发调度过多 goroutine，导致上下文切换开销大；建议显式设GOMAXPROCS，值 ≈limits.cpu * 1.2（向上取整） - 不要只设
limits不设requests：Kubernetes 调度器靠requests分配节点，没设等于 0，可能挤在同一个节点上互相争抢
最常被忽略的是 GOMEMLIMIT 和 PID 1 信号转发——这两个点不出问题时一切正常，一出就是服务不可用、升级卡死、监控失真，而且现象分散，不容易关联到根本原因。
