真正能跑通的 Dockerfile 需多阶段构建：第一阶段用 golang:1.22-alpine + CGO_ENABLED=0 静态编译，第二阶段用 alpine 或 scratch 镜像，仅复制二进制和必要证书，禁用 sh -c 启动，显式创建非 root 用户并切换，确保信号转发与权限合规。
怎么写一个真正能跑通的 Dockerfile？
很多 Go 服务本地能跑，一进 Kubernetes 就 CrashLoopBackOff，八成卡在镜像构建这步。关键不是“能不能编译”，而是“运行时有没有依赖、权限是否合理”。
- 必须用多阶段构建：第一阶段用
golang:1.22-alpine编译，禁用CGO_ENABLED=0，确保生成静态二进制；第二阶段用alpine:latest或更极致的scratch，只复制二进制和必要证书（如/etc/ssl/certs/ca-certificates.crt） - 别用
sh -c "./main"启动——它会绕过信号转发，导致SIGTERM无法被 Go 程序捕获，优雅关闭失效 - 显式指定非 root 用户：
RUN adduser -D -u 1001 app && chown -R app:app /root，再USER app，否则 Kubernetes PodSecurityPolicy 或 PodSecurity Admission 会直接拒绝创建
Deployment 里哪些字段改错会导致滚动更新失败？
最常见的“更新了镜像但 Pod 没变”问题，往往不是镜像没拉到，而是 Deployment 的声明式约束锁死了更新路径。
-
spec.selector.matchLabels和spec.template.metadata.labels必须完全一致，且一旦创建就不可修改——改了会报field is immutable - 镜像拉取策略默认是
IfNotPresent，CI/CD 流水线中务必显式设为imagePullPolicy: Always，否则旧镜像可能被复用 - 资源
requests和limits不只是性能建议：Kubernetes 调度器靠requests分配节点，limits触发 OOMKilled；Go 服务内存常“虚高”，建议从memory: "64Mi"起步，配合pprof实测后调优
健康探针为什么总超时或误杀？
readinessProbe 和 livenessProbe 不是加了就完事，它们的参数组合直接影响服务能否接入流量、会不会被反复重启。
-
initialDelaySeconds必须大于 Go 服务初始化耗时：比如加载大配置、连 DB、预热缓存。硬写5秒，而实际要 8 秒，Pod 就永远进不了 Ready 状态 -
httpGet探针路径应严格分离语义：/healthz只检查进程存活（返回 200 即可），/readyz才检查 DB 连通性、依赖服务可用性——后者失败不该触发重启，只该摘流量 - 别在探针 handler 里做重操作（如查数据库全表），否则
periodSeconds: 10下高频探测会拖垮服务；用连接池状态、本地健康标记等轻量判断替代
如何让 Go 服务真正支持滚动更新不丢请求？
滚动更新不是 Kubernetes 自动完成的，它依赖 Go 代码对信号和 HTTP Server 生命周期的正确响应。
立即学习“go语言免费学习笔记（深入）”；
- 必须监听
SIGTERM：用signal.Notify注册，收到后调用srv.Shutdown()，并等待活跃连接自然结束（设ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)） - HTTP Server 启动前，先确保端口已监听、探针接口已就绪，再把
readinessProbe切换为 true——否则新 Pod 可能还没准备好就被 Service 加入负载均衡 - Service 的
type: ClusterIP是默认选项，但若需外部访问，NodePort易暴露端口范围，LoadBalancer依赖云厂商；生产环境更推荐Ingress+ingress-nginx，统一 TLS 终止和路由规则
最常被忽略的是：所有环境变量（如 DB_URL）、配置项（如日志级别）、证书文件，都该通过 ConfigMap 或 Secret 挂载，而不是打进镜像。否则一次配置变更就得重新构建、推送、部署——这会让“快速迭代”变成“不敢改”。
