go服务kubernetes部署关键在于镜像精简（cgo_enabled=0+goos=linux多阶段构建）、探针合理（readiness与liveness的initialdelayseconds需差异化设置）、资源限制科学（requests需覆盖冷启动内存尖峰，limits设为1.5–2倍），且代码须显式处理sigterm。
Go 服务容器化部署到 Kubernetes，关键不在“能不能”，而在“镜像够不够瘦、探针配得对不对、资源限制设得合不合理”——三者任一出问题，都会导致 Pod 反复 Crash 或无法就绪。
多阶段构建时 CGO_ENABLED=0 和 GOOS=linux 必须同时生效
Go 编译成静态二进制是减小镜像体积和规避 libc 兼容问题的前提。如果只设 CGO_ENABLED=0 却漏了 GOOS=linux，在 macOS 或 Windows 上本地构建时仍可能隐式依赖 host 系统的动态链接库，导致镜像在 Alpine 或 distroless 运行时 panic："standard_init_linux.go:228: exec user process caused: no such file or directory"。
-
CGO_ENABLED=0关闭 cgo，避免调用 C 库 -
GOOS=linux强制目标操作系统为 Linux（即使你在 Mac 上构建） - 二者缺一不可，建议写成一行：
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o app . - 若项目中用了
cgo（比如 SQLite、某些加密库），不能简单关掉，得换纯 Go 实现或改用gcr.io/distroless/cc-debian12等带 libc 的基础镜像
FROM scratch 镜像里没有 /bin/sh，CMD 必须是可执行文件绝对路径
用 scratch 构建最小镜像很诱人，但它是空镜像，连 sh 都没有。此时若写 CMD ["./app"]，会报错 "OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "./app": stat ./app: no such file or directory" —— 因为当前工作目录未设置，./app 相对路径失效。
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
- 必须显式指定工作目录：
WORKDIR /或WORKDIR /app -
CMD改用绝对路径：CMD ["/app"]（注意不是["/app"]加括号外引号） - 验证方式：运行容器后执行
docker run --rm -it your-image ls -l /app，确认文件存在且有可执行权限 - 若需调试，临时换成
FROM alpine:latest，加apk add strace gdb查 syscall 失败点
Kubernetes 中 livenessProbe 和 readinessProbe 的 initialDelaySeconds 差异要合理
Go 应用启动慢是常态（尤其带 DB 连接池、gRPC 初始化、配置加载等）。若两个探针的 initialDelaySeconds 设得太近，livenessProbe 可能早于应用真正 ready 就开始探测，触发重启循环。
-
readinessProbe.initialDelaySeconds建议设为 3–5 秒，让应用完成基本初始化、端口监听即可接入流量 -
livenessProbe.initialDelaySeconds至少比 readiness 多 10–15 秒，留足 DB 连接、健康检查依赖项就绪时间 - 务必确保
/health和/ready是两个独立 endpoint：/ready只检查自身状态（如 HTTP 监听），/health检查下游依赖（DB、Redis、第三方 API） - 若用
httpGet探针，port必须和容器containerPort一致；K8s 不会自动映射 hostPort
Deployment 中 resources.requests 设置过低会导致调度失败或 OOMKilled
Go 程序的内存占用有“冷启动尖峰”：GC 未触发前，heap 可能快速涨到 200Mi+，哪怕长期稳定在 50Mi。若 requests.memory 设为 64Mi，Pod 可能根本起不来（Pending 状态卡在 “0/3 nodes are available: 1 node(s) had untolerated taint, 2 Insufficient memory.”）；若 limits.memory 设太紧，又容易被 kubelet OOMKilled。
-
requests.memory应 ≥ 应用常驻内存 + GC 尖峰预估（可用pprof的/debug/pprof/heap抓取启动后 30 秒快照） -
limits.memory建议设为 requests 的 1.5–2 倍，给 GC 和临时 buffer 留余量 - 避免设
requests.cpu为100m这类极小值：K8s 调度器可能将其打散到不同节点，反而增加跨节点通信开销 - 上线前用
kubectl top pods和kubectl describe pod检查 Events 是否有OOMKilled或ExceededQuota
最常被跳过的一步是：没在 Go 代码里显式处理 SIGTERM。Kubernetes 删除 Pod 前会发 SIGTERM，若你的 http.Server 没调用 Shutdown()，连接会直接断开，造成请求丢失。这和 Dockerfile 或 YAML 无关，但却是生产环境超时错误的隐形推手。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
