Go服务容器化失败主因是镜像路径与WORKDIR不匹配、containerPort未对齐监听端口、Probe未适配程序健康接口、ConfigMap/Secret挂载权限不足，需逐一核验镜像内容、网络声明、文件权限及进程监听行为。
Go 服务打包成容器镜像时，main.go 路径和 WORKDIR 不匹配导致启动失败
Go 程序在容器里跑不起来，最常见的原因是镜像构建时 WORKDIR 和实际执行 go run 或二进制路径不一致。K8s Pod 启动后直接 CrashLoopBackOff，看日志往往是 exec: "app": executable file not found in $PATH 或 no such file or directory。
- 用
go build -o ./bin/app .编译时，确保输出路径在 Dockerfile 的WORKDIR下可访问，比如设WORKDIR /app就别把二进制丢到./bin/后不复制过去 - 推荐静态编译 + 多阶段构建：第一阶段用
golang:1.22-alpine编译，第二阶段用alpine:latest，只 COPY 二进制，不带 Go 环境——体积小、攻击面小 - 检查最终镜像里二进制是否真能执行：
docker run --rm -it your-image:tag sh -c 'ls -l /app/app && /app/app --help'
Deployment 中 container.port 没暴露，Service 流量根本进不来
K8s Service 转发不到 Pod，90% 是因为 Deployment 的 container.ports 没写对，不是 Service 配置的问题。
-
container.ports是声明式提示，不是端口绑定动作；它必须和 Go 程序实际监听的地址一致，比如http.Listen(":8080")，这里就必须写containerPort: 8080 - 不要写
hostPort——它绑的是宿主机端口，在 K8s 里基本不用，还容易冲突 - 如果 Go 用了
net/http.Server{Addr: ":8080"}，但 Deployment 写了containerPort: 3000，Service 会转发，但 Pod 内进程收不到连接
Liveness/Readiness Probe 配置不当，反复重启或流量切不进去
Probe 不是加了就安全，Go 服务没做健康检查适配时，配置再标准也会出问题。
Kubernetes Skills
下载
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
- HTTP 探针路径（如
/healthz）必须由 Go 程序真实响应，且返回 200；别依赖中间件自动加，自己手写一个http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) { w.WriteHeader(200) }) - 避免用
exec探针调curl或ps——容器里没装这些命令，或者权限不够，直接失败 - 初始延迟（
initialDelaySeconds）至少设为比 Go 启动耗时多 2–3 秒；冷启动慢的程序（比如连 DB、加载配置），设太短会触发误杀
ConfigMap/Secret 挂载后文件权限不对，Go 打不开配置文件
Go 程序用 os.Open("config.yaml") 报 permission denied，大概率是 ConfigMap 挂载的文件默认权限是 644，但容器以非 root 用户运行（推荐做法），而该用户不属于文件所属组。
立即学习“go语言免费学习笔记（深入）”；
- 在 Deployment 中显式设置
securityContext.runAsUser: 65532后，用volumeMounts挂载 ConfigMap 时，加上readOnly: true和mode: 0644 - 更稳妥的方式：挂载整个目录，然后在容器启动前用
initContainer把配置 copy 到临时路径并改权限，主容器只读那个副本 - Secret 挂载的文件默认也是 644，同理；不要指望
stringData能绕过权限问题
Go 二进制本身不认 K8s 的抽象概念，它只认文件系统和网络栈。所有“部署失败”，归根结底是镜像内容、Pod 网络声明、文件权限、进程监听行为这四件事没对齐。调试时先盯死这四个点，比翻 YAML 结构快得多。
