可行，但关键在于镜像精简（cgo_enabled=0+goos=linux多阶段构建）、探针合理（readiness与liveness的initialdelayseconds需差异化设置）、资源限制科学（requests需覆盖冷启动内存尖峰，limits设为1.5–2倍），且代码须显式处理sigterm。
直接部署静态编译的 Go 应用到 Kubernetes 是可行的，但关键不在“能不能”，而在于镜像构建方式、探针配置和资源约束是否匹配静态二进制的运行特性——否则容易出现 ImagePullBackOff、CrashLoopBackOff 或探针持续失败。
多阶段构建必须禁用 CGO 且指定 GOOS=linux
Go 静态编译的前提是彻底剥离对 libc 等动态库的依赖。如果没关 CGO_ENABLED，即使用了 alpine 基础镜像，运行时仍可能因缺少 libc 报错 no such file or directory（实际是找不到动态链接器）。
-
CGO_ENABLED=0必须显式设置，不能依赖默认值 -
GOOS=linux要明确指定，避免本地 macOS/Windows 编译出不兼容的二进制 - 推荐加
-a -installsuffix cgo强制重新编译所有依赖，防止缓存残留 cgo 代码 - 构建命令示例：
CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o main .
运行阶段别用 golang 镜像，优先选 scratch 或 alpine
静态二进制不需要任何运行时依赖，所以 FROM golang:1.22 直接跑是典型错误——镜像体积大、攻击面宽、启动慢。
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
- 首选
scratch：零依赖，最小攻击面，但要求二进制完全静态且不调用外部命令（如exec.Command("sh")） - 次选
alpine:latest：需补apk --no-cache add ca-certificates，否则 HTTPS 请求（比如调用其他服务或上报 metrics）会因证书缺失失败 - 绝对不要写
CMD ["go", "run", "main.go"]—— 这会把整个 Go 工具链打进镜像，且无法在scratch中运行
Deployment 中 containerPort 和探针路径必须与 Go 代码一致
Kubernetes 不会解析你的 Go 源码，它只按 YAML 字段机械执行。端口错一位、路径少个斜杠，探针就永远 404，Pod 卡在 Running 但状态为 NotReady。
-
containerPort必须等于 Go 代码里http.ListenAndServe(":8080", nil)的端口，不能只写80然后靠 Service 映射掩盖 -
livenessProbe.httpGet.path和readinessProbe.httpGet.path要对应代码中注册的 handler，比如http.HandleFunc("/healthz", ...)就得写path: /healthz - 探针
initialDelaySeconds别设太小：Go 启动快，但若初始化 DB 连接或加载配置，5 秒可能不够，建议 readiness 至少设10，liveness 设30
资源 limits/requests 缺失会导致调度失败或 OOMKilled
静态二进制虽轻量，但 Kubernetes 调度器仍需知道它要多少资源。不设 resources.requests，节点可能根本不会被选中；不设 limits.memory，容器内存无上限，一旦泄漏就会被 OOMKilled。
- 开发环境可设低些：
requests: {cpu: "100m", memory: "128Mi"} - 生产环境建议从
cpu: "200m", memory: "256Mi"起步，根据top或metrics-server实际观察调整 - 注意：
limits.memory设得太小（如"64Mi"），Go runtime GC 可能频繁触发，反而拖慢响应
最容易被忽略的是健康探针的实现逻辑本身——它得返回 200，且不能阻塞；而更隐蔽的问题是，哪怕镜像构建正确、YAML 语法无误，只要 selector.matchLabels 和 template.metadata.labels 不完全一致，Deployment 就不会创建任何 Pod，kubectl get pods 一片空白，连日志都看不到。
