Go应用在Kubernetes中部署需兼顾稳、快、省、可观察：必须用CGO_ENABLED=0和-ldflags="-s -w"多阶段构建；liveness/readiness探针要分设端点并合理配置initialDelaySeconds；resources需同时设置requests和limits；必须监听SIGTERM并用带超时的context.Shutdown实现优雅终止。
Go 应用在 Kubernetes 中部署不慢，但默认写法容易踩坑——镜像臃肿、启动失败、探针误杀、资源争抢是高频问题。关键不在“能不能跑”，而在“是否稳、快、省、可观察”。
多阶段构建必须禁用 CGO 且加 -ldflags="-s -w"
很多团队用 golang:alpine 构建后直接 COPY 二进制到 alpine 运行镜像，结果容器启动报 standard_init_linux.go:228: exec user process caused: no such file or directory。这不是路径错，是动态链接失败。
-
CGO_ENABLED=0是硬性前提：否则 Go 会链接宿主机的 libc，而scratch或精简alpine不含这些库 -
-ldflags="-s -w"必须加：去掉符号表和调试信息，二进制体积常减少 30%–50%，启动加载更快 - 别信
go build -a：它已废弃，-installsuffix cgo也多余，CGO_ENABLED=0足够 - 示例构建命令：
CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o app ./cmd/api
livenessProbe 和 readinessProbe 的 initialDelaySeconds 不能拍脑袋设
Go 程序启动快，但不代表 HTTP server 立刻能响应。常见错误是把 initialDelaySeconds 设成 1 或 3，结果 Pod 反复重启——Kubernetes 在 server 还没 ListenAndServe 完就发探测请求，返回 404 或连接拒绝，触发 kill + restart 循环。
-
readinessProbe.initialDelaySeconds建议 ≥ 5：留给日志初始化、DB 连接池建立、配置热加载等耗时操作 -
livenessProbe.initialDelaySeconds建议 ≥ 30：避免因临时 GC 停顿、慢查询或依赖服务抖动被误判为崩溃 - 不要共用同一个健康端点：/health 做 liveness，/ready 做 readiness，语义分离更可控
- 务必实现 handler 返回 200 且无副作用，别在里面查 Redis 主从延迟或调第三方 API
Deployment 的 resources limits 必须设，但 requests 要保守
不设 limits，Pod 可能吃光节点内存被 OOMKilled；只设 limits 不设 requests，Kubernetes 调度器无法判断该塞几个 Pod 到节点上，导致资源碎片或调度失败。
立即学习“go语言免费学习笔记（深入）”；
-
requests.cpu按典型负载设（如"100m"），不是峰值：它影响调度和 CPU 时间片分配，设太高浪费，太低导致被 throttled -
limits.memory必须略高于实测 RSS（如压测中看到 90Mi，设"128Mi"）：Go 的 GC 会预留额外内存，超限立即 OOMKilled - 绝对不要设
limits.cpu > 1000m且不配runtimeClassName: "gvisor"或类似隔离：Go 的 goroutine 调度器对 CPU 时间片敏感，超限会导致大量 goroutine 饥饿 - 验证方式：
kubectl top pods看实际 usage，再对比kubectl describe pod中的 events 是否有OOMKilled或ExceededQuota
优雅终止必须监听 SIGTERM 并用 context.WithTimeout 控制 Shutdown
默认情况下，Kubernetes 发送 SIGTERM 后等 30 秒（terminationGracePeriodSeconds 默认值）就发 SIGKILL 强杀。如果 Go 没做任何处理，HTTP 连接被粗暴中断，正在处理的请求丢数据、DB 事务未提交、消息未 ACK。
- 必须显式监听信号：
signal.Notify(c, os.Interrupt, syscall.SIGTERM) -
server.Shutdown()要传带 timeout 的 context，不能只用context.Background()：否则可能永远等不到连接关闭 - Shutdown 前建议先关闭 listener：
server.Close()阻止新连接，再调server.Shutdown()处理存量 - 别忘了 defer cancel()：避免 context 泄漏，尤其在长周期 goroutine 中
最易被忽略的是 probe 配置和 terminationGracePeriodSeconds 的协同——前者决定“何时开始关”，后者决定“最多给多久关”。这两个数字不匹配，再好的优雅关闭逻辑也白搭。
