Go微服务在Kubernetes中稳定运行的关键在于代码与YAML协同配合：需实现SIGTERM响应和Shutdown优雅退出，分离轻量级/healthz与依赖感知的/readyz探针，使用CGO_ENABLED=0静态编译镜像，并确保YAML中port、labels、env等字段精确匹配运行时约束。
Go 微服务本身不“使用” Kubernetes，Kubernetes 也不主动“管理” Go 程序——真正起作用的是：你的 Go 代码是否配合 K8s 的生命周期约定，以及 YAML 配置是否准确反映运行时依赖。不改代码、只堆 YAML，大概率 Pod 卡在 ContainerCreating 或反复 CrashLoopBackOff。
Go 服务必须实现 SIGTERM 响应和 http.Server.Shutdown()
Kubernetes 发送 SIGTERM 后，若 Go 进程直接退出，正在处理的 HTTP 请求会被强制中断。这不是“没写完”，而是根本没给机会收尾。
- 不能只写
http.ListenAndServe(":8080", nil)—— 它是阻塞调用，且无退出钩子 - 必须显式创建
*http.Server实例，启动 goroutine 调用srv.ListenAndServe() - 用
signal.Notify(quit, syscall.SIGTERM, os.Interrupt)捕获信号，收到后调用srv.Shutdown(context.WithTimeout(...)) -
Shutdown()返回后，再关闭数据库连接池、gRPC client、消息消费者等依赖资源，顺序不能颠倒
健康与就绪探针端点必须分离且轻量
/healthz 和 /readyz 不是可选功能，是 Kubernetes 判断 Pod 是否能接收流量的唯一依据。混用或缺失会导致流量打到未初始化完成、或已开始关闭的实例上。
-
/healthz只检查进程存活（返回200即可），不要查 DB、Redis 等外部依赖 -
/readyz必须检查真实依赖项，比如db.PingContext()、grpcConn.Ready()，任一失败就返回非200 - 两个端点要独立注册，避免被中间件（如 auth、logging）拦截或修改状态码
- 监听端口必须和 Deployment 中
containerPort一致，否则 probe 请求根本发不到你的服务
Dockerfile 多阶段构建必须关掉 CGO 并用静态二进制
镜像里留着 glibc 或 Go 编译环境，不是“更通用”，而是让 Alpine/scratch 镜像启动时报 no such file or directory —— 因为 musl libc 找不到 glibc 符号。
立即学习“go语言免费学习笔记（深入）”；
- 构建阶段用
golang:1.22-alpine，但编译命令必须加CGO_ENABLED=0 GOOS=linux - 运行阶段优先选
scratch，若用了 cgo（如 SQLite、某些 crypto 库），才退而用alpine:latest并apk add对应库 - 别在镜像里
go run main.go，这会打包整个 Go 工具链，体积大且不安全 - 入口用
ENTRYPOINT ["/main"]，确保 PID 1 是你的服务进程，否则SIGTERM无法透传
Deployment YAML 里最容易漏掉的三个字段
很多团队把 YAML 写得巨长，却卡在最基础的字段缺失上。Kubernetes 不报错，但 Pod 就是起不来或 probe 失败。
-
spec.template.spec.containers[0].livenessProbe.httpGet.port必须填数字（如8080），不能填字符串"http"或空 -
spec.selector.matchLabels和spec.template.metadata.labels必须完全一致，否则 Deployment 创建后找不到 Pod，报field is immutable -
spec.template.spec.containers[0].env要显式声明所有配置项，比如PORT、DB_HOST，不能依赖代码里硬编码的默认值
复杂点不在 YAML 语法，而在每个字段背后对应的真实运行约束：端口绑定时机、信号转发路径、cgroup 内存限制与 Go runtime 的交互——这些稍有错位，表现就是 Pod 状态飘忽、日志里只有 terminated with signal 15 却查不到原因。
