go服务容器化失败主因是路径、端口、权限等运行时约束不匹配：workdir/cmd路径错误致启动失败；containerport与实际监听端口不一致致service连不通；探针配置过激引发误杀；configmap挂载权限及热更新机制不当导致配置失效。
Go服务打包成容器镜像时，main.go路径和WORKDIR不匹配导致启动失败
Go二进制文件本身是自包含的，但Docker镜像里若WORKDIR设错或CMD路径写死，容器会报exec: "server": executable file not found in $PATH或no such file or directory。关键不是“能不能编译”，而是“运行时找不找得到可执行文件”。
- 用
scratch或gcr.io/distroless/static基础镜像时，必须把编译好的二进制显式COPY到根目录（如/app），再WORKDIR /app，然后CMD ["./server"] - 避免在
Dockerfile里用go run main.go——它依赖Go环境，和生产镜像轻量原则冲突 - 交叉编译要加
CGO_ENABLED=0：CGO_ENABLED=0 GOOS=linux go build -a -o server .，否则镜像可能因缺失libc崩溃
Deployment中container.port没暴露，Service连不通
K8s里containerPort只是文档性字段，不实际开防火墙或转发端口；真正决定流量能否进来的是Service的targetPort是否和Pod里进程监听的端口一致。常见错误是Go代码监听:8080，但Deployment写了containerPort: 3000，而Service又配了targetPort: 3000——结果请求全超时。
- Go服务启动时打印监听地址，例如
log.Printf("server started on :8080")，以此为准 -
Deployment里的containerPort建议和实际监听端口严格一致（虽非强制，但能避免团队误读） -
Service的targetPort必须等于Pod内进程绑定的端口，类型为NodePort或ClusterIP不影响该匹配逻辑
Liveness/Readiness探针返回503却不停止滚动更新
Go默认HTTP handler在未初始化完成时直接返回503，但K8s探针如果配置了过低的initialDelaySeconds（比如设成5），而应用冷启动要8秒，就会触发误杀——新Pod还没起来就被删掉，滚动更新卡住。
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
- 用
http.ServeMux或chi等路由库时，别让/healthz路径依赖DB连接或缓存初始化；应单独做轻量检查，例如只返回200 OK -
livenessProbe的failureThreshold别设太小（默认3），否则短暂GC停顿也可能触发重启 - 本地调试可用
kubectl port-forward直连Pod验证curl http://localhost:8080/healthz响应，比看Events更直接
ConfigMap挂载后Go读不到配置文件，或热更新不生效
ConfigMap以卷方式挂载时，默认权限是644，且文件不可写；如果Go代码尝试os.OpenFile(..., os.O_RDWR)就会失败。更隐蔽的问题是：挂载后文件inode不变，Go用os.Stat判断文件是否变更会失效，导致配置热加载逻辑失灵。
- 挂载ConfigMap时，用
subPath指定单个文件（避免整个目录覆盖），并在volumeMounts里设readOnly: true - 不要在Go里轮询
os.Stat改时间——改用fsnotify监听文件系统事件，或干脆接受“重启Pod才生效”的运维约定 - 敏感配置（如API key）优先走
Secret，且通过环境变量注入（envFrom），避免挂载后被其他进程意外读取
Go二进制的静态链接特性让它部署简单，但K8s的声明式抽象容易掩盖底层路径、端口、权限这些硬约束。最常卡住的地方不在YAML语法，而在go build参数和containerPort之间那100毫秒的启动竞争，或者ConfigMap挂载后那个看不见的只读位。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
