go微服务上kubernetes必须解决镜像崩溃、请求丢失、探针误判三大硬性问题：cgo_enabled=0强制静态编译避免alpine下glibc缺失报错；liveness与readiness探针须分离路径与超时；main中需监听sigterm并用context.withtimeout调用shutdown()，再关闭db等依赖；推荐scratch镜像替代alpine以最小化攻击面。
Go 微服务上 Kubernetes，不是“能跑就行”，而是必须解决三个硬性问题：镜像不能崩、服务不能丢请求、探针不能误判。其他都是锦上添花。
CGO_ENABLED=0 为什么必须加在构建命令里
不加就报 standard_init_linux.go:228: exec user process caused: no such file or directory —— 这是 Alpine 镜像找不到 glibc 的典型错误。Alpine 用 musl libc，而默认 go build 启用 CGO 就会链接 glibc。
-
CGO_ENABLED=0强制静态编译，生成的二进制不依赖系统 libc - 哪怕你换 Ubuntu 基础镜像，也建议关掉：镜像体积减少 30–50MB，避免 libc 升级引发兼容抖动
- 配合
GOOS=linux和-ldflags '-s -w'（剥离符号和调试信息），最终二进制更小、更安全 - 多阶段构建中，这一行必须写在 builder 阶段的
RUN里，不能只靠环境变量或 Docker 构建参数
Deployment 中 livenessProbe 和 readinessProbe 必须分离
Kubernetes 默认把两个探针指向同一个路径（比如 /healthz），但这是危险的。liveness 探针失败会直接重启 Pod，readiness 失败只是摘流量 —— 它们语义完全不同。
-
livenessProbe应该只检查进程是否存活（例如/livez，只返回 HTTP 200，不做 DB 查询） -
readinessProbe才该检查真实就绪状态（例如/readyz，查 DB 连接、下游服务连通性） - 两者 timeoutSeconds 建议设为不同值：liveness 通常 1–3 秒，readiness 可设 10 秒以上，避免滚动更新时误摘流量
- 如果共用一个端点，DB 暂时不可用会导致 liveness 失败 → Pod 重启 → 更加重 DB 压力，形成雪崩
main 函数里必须监听 SIGTERM 并调用 http.Server.Shutdown()
不这么做，Kubernetes 发出 SIGTERM 后，Go 进程不会等正在处理的请求结束就退出，导致 5xx 或连接中断。这不是“优雅”问题，是线上故障根因。
- 必须用
signal.Notify(quit, os.Interrupt, syscall.SIGTERM)捕获信号 -
http.Server.Shutdown()要传入 context.WithTimeout，超时时间需略大于最长业务处理时间（比如 30 秒） - Shutdown() 返回后，再关闭 DB 连接池、gRPC 客户端、消息消费者等依赖，顺序不能颠倒
- 别用
os.Exit()或 panic 替代 Shutdown；也不要只 defer 关闭，它无法响应信号
用 scratch 镜像替代 alpine 作为运行阶段基础镜像
Alpine 看似轻量，但自带 apk、shell、证书库等冗余组件。真正最小化的选择是 scratch —— 空镜像，只放你的静态二进制。
- 前提是：构建时已用
CGO_ENABLED=0+GOOS=linux，且没调用任何需要动态库的 syscall（如 getgrouplist） - 从
alpine:latest切到scratch，镜像体积可从 ~12MB 降到 ~8MB，攻击面大幅收窄 - 必须显式
COPY --from=builder /app/main .，且 CMD 必须是绝对路径（["./main"]），不能依赖 PATH - 调试困难：没有 shell，日志全靠应用自身输出；上线前务必验证健康接口和日志格式是否完整
真正卡住上线的，往往不是 YAML 写错字段，而是 CGO_ENABLED 漏了、探针路径混用、或者 Shutdown() 调用位置不对 —— 这些点不验证，压测再好也扛不住真实滚动更新。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
