go服务在k8s启动失败主因是镜像路径与workdir不匹配、containerport未对齐监听端口、probe未适配健康接口、configmap/secret挂载权限不足，需逐一核验镜像内容、网络声明、文件权限及进程监听行为。
Go服务在K8s里起不来，八成不是代码问题，而是镜像路径、端口声明、探针时机或配置挂载这四点没对齐。直接看怎么修。
镜像启动失败：exec: "app": executable file not found in $PATH
这是最常卡住的第一步——Pod状态是 CrashLoopBackOff，日志就这一行。根本原因不是编译失败，而是容器运行时找不到二进制。
- 用多阶段构建时，确保
COPY --from=builder的源路径和目标路径一致：比如COPY --from=builder /app/app .后，WORKDIR必须是/app，且CMD ["./app"]才能执行 - 别用
scratch镜像却忘了把二进制COPY进去；也别用gcr.io/distroless/static却还在ENTRYPOINT里写sh -c "./app"——它没sh - 本地验证命令：
docker run --rm -it your-image:tag sh -c 'ls -l /app && /app/app --help'，看到文件存在且可执行，才算过第一关
Service连不通：curl超时或503，但Pod是Running
流量压根没进到容器里，不是网络策略或Ingress的问题，而是 targetPort 和 Go 实际监听端口不一致。
Kubernetes Skills
下载
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
- Go 代码里查清监听地址：是
http.ListenAndServe(":8080", nil)？还是net.Listen("tcp", ":3000")？这个端口号就是唯一依据 -
Deployment中的containerPort建议写成相同数字（虽非强制），避免团队误读；Service的targetPort必须严格等于它 -
EXPOSE在 Dockerfile 里只是注释，K8s 完全不认；删掉它或留着都行，但别指望它起作用
Liveness/Readiness探针导致反复重启或502
Pod Running 了，但刚起来就被杀掉，或者 Service 把流量导过去后立刻 502——大概率是探针太急，没等 Go 服务真正就绪。
-
readinessProbe的initialDelaySeconds至少要比 Go 冷启动时间多 3 秒；连 DB + 加载 config.yaml 的服务，设 15–30 更稳妥 -
/healthz或/ready端点必须轻量：不查 DB、不依赖 Redis、不加载大文件；只返回200 OK即可 - 别用
exec探针调ps aux | grep app——容器里没ps，或者权限不够，探针直接失败变成Unknown
ConfigMap挂载后os.Open报permission denied
Go 调用 os.Open("config.yaml") 失败，错误是 permission denied，不是路径错，是权限没配对。
- 默认 ConfigMap 挂载文件权限是
644，但如果容器以非 root 用户运行（推荐做法），而该用户不属于文件所属组，就打不开 - 在
volumeMounts里显式加mode: 0644；同时在securityContext中设runAsUser: 65532（非 root UID） - 更稳的做法：挂载整个目录（如
/etc/app），再让 Go 用绝对路径读，比如os.Open("/etc/app/config.yaml")，避免相对路径受WORKDIR影响
真正难的不是写完 YAML，而是每个字段都要和 Go 进程的实际行为对得上——监听端口、二进制位置、启动耗时、文件权限，缺一不可。随便改一个，就可能让整个部署链路静默失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
