Go生产环境部署需多阶段构建+scratch/alpine+非root用户；禁用CGO并静态编译，避免依赖libc；否则镜像臃肿、攻击面大、启动慢、易OOM或流量异常。
不能只靠 kubectl apply -f 一把梭部署 Go 生产环境应用。镜像没瘦身、探针没分清、资源没设限、监听地址写错——任何一个点都会导致 Pod 启动失败、流量进不来、OOMKill 频发，或者上线当天就被打挂。
Go 镜像必须用多阶段构建 + scratch/alpine + 非 root 用户
很多人直接用 golang:alpine 运行编译好的二进制，结果镜像里还带着 go 命令、apk、sh，既增大攻击面，又拖慢启动。
-
CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-extldflags "-static"' -o main .确保生成纯静态二进制，不依赖 libc - 运行阶段用
FROM scratch（体积常 FROM alpine:latest（需apk add ca-certificates） - 必须加
USER 65532:65532，避免容器逃逸后拿到 root 权限 - 别漏掉
EXPOSE 8080，且 Go 代码里监听地址必须是0.0.0.0:8080，不是127.0.0.1:8080
Deployment 必须显式配 replicas、strategy 和 probe 路径
Kubernetes 不认“进程活着”，只信 HTTP 探针返回码。没暴露 /readyz 或 /livez，Pod 就永远卡在 ContainerCreating 或反复重启。
-
replicas: 3是底线，配合topologySpreadConstraints强制跨节点调度 -
strategy.rollingUpdate.maxUnavailable: 25%，别写0—— 更新时所有 Pod 全被腾空，服务直接中断 -
revisionHistoryLimit: 3，否则kubectl rollout undo找不到上个可用版本 -
readinessProbe和livenessProbe的path必须真实存在，且逻辑分离：/readyz检 DB 连通性，/livez只返回 OK -
initialDelaySeconds得大于冷启动耗时：Spring Boot 类项目建议 ≥60s，Go 应用通常 ≥30s
resources.requests/limits 不是可选项，是准入硬门槛
没设 requests，Kubernetes 调度器根本不知道往哪塞 Pod；没设 limits，一个 goroutine 泄漏就能拖垮整台 Node。
立即学习“go语言免费学习笔记（深入）”；
-
requests.cpu决定调度位置，limits.cpu过低会导致cpu.shares失效、频繁 throttling（查cpu.cfs_quota_us可确认） -
requests.memory建议 256Mi，limits.memory建议 512Mi（1.5–2 倍），给 GC 和临时缓存留余量 - 别信“压测再调”——压测前
Exit Code 137就已刷屏日志 - 用
LimitRange在 namespace 级兜底，防止单个开发忘写就提交上线
ConfigMap/Secret 注入配置，禁止硬编码或命令行传参
数据库密码写进 YAML？镜像 tag 写死 latest？这些操作在生产环境等于裸奔。
- 敏感信息必须走
Secret，且用envFrom或volumes注入，别用env.value明文写 - 非敏感配置走
ConfigMap，比如DATABASE_URL、LOG_LEVEL - 镜像 tag 必须用语义化版本（如
v1.2.3），禁用latest—— 它让部署不可重现、回滚不可控 - Go 代码里用
os.Getenv()读取，别解析命令行参数或读本地文件（除非该文件由 ConfigMap 挂载）
最常被跳过的其实是优雅关闭：Pod 删除时 Kubernetes 发 SIGTERM，Go 必须监听并主动关 HTTP server、断 DB 连接、等 goroutine 收尾。漏掉这步，滚动更新时连接重置、数据写一半就丢，问题比探针失败更难排查。
