Go应用在Kubernetes中启动失败主因是资源限制未配置、探针端点未暴露、镜像未静态编译；须监听0.0.0.0而非127.0.0.1，探针路径须与代码注册端点严格一致，containerPort需匹配监听端口，且Dockerfile必须用多阶段构建+CGO_ENABLED=0。
Go 应用在 Kubernetes 中跑不起来，八成不是代码问题，而是资源限制没配对、探针没暴露、镜像没静态编译——三者缺一不可。
Go 服务必须监听 0.0.0.0:8080，不能写 127.0.0.1:8080
Kubernetes 的 Service 流量是通过 Pod IP 转发进来的，不是 localhost。监听 127.0.0.1 会导致所有请求 503，readinessProbe 直接失败。
- 正确写法：
http.ListenAndServe(":8080", nil)或http.ListenAndServe("0.0.0.0:8080", nil) - 启动日志加一句：
log.Printf("server started on :8080")，方便快速确认监听地址 - 如果用了
gin，确保没调用router.Run("127.0.0.1:8080")这类硬编码
livenessProbe 和 readinessProbe 必须对应真实存在的 HTTP 端点
Kubernetes 不会猜你的健康逻辑，它只发起 HTTP GET 请求，并检查返回状态码。路径不存在或 handler 没注册，Pod 就会卡在 CrashLoopBackOff 或 ContainerCreating。
Kubernetes Skills
下载
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
- 至少实现两个端点：
/healthz（存活）、/readyz（就绪） - 别用
/或/ping代替——Deployment 里写的path必须完全一致 -
readinessProbe可加轻量 DB 连通性检查，但别查 Redis+MySQL+ES 全链路，超时就变不就绪 - 确保端口和
containerPort一致，比如 Deployment 写了containerPort: 8080，探针就不能设port: 80
资源限制不是“可选项”，而是调度前提
没配 resources.requests，Kubernetes 调度器根本不知道该把 Pod 分到哪个节点；没配 limits，容器可能吃光节点内存导致 OOMKilled。
-
requests.cpu影响调度：设"200m"表示至少预留 0.2 核，节点空闲 CPU 不足就调度失败 -
limits.memory触发硬限制：超过值会被 Linux OOM killer 杀掉，且不会触发 Go 的 GC 自适应调整 - 生产环境建议起步值：
requests: {cpu: "500m", memory: "256Mi"}，limits: {cpu: "1", memory: "512Mi"} - Go 运行时会根据
limits.memory自动调GOGC，但若你手动设了GOGC=10，反而可能让 GC 频繁触发，需权衡
Dockerfile 必须用多阶段 + CGO_ENABLED=0 + FROM scratch 或 alpine
镜像体积大、含调试工具、带 libc 动态依赖，都会增加拉取失败、安全扫描告警、启动慢的风险。
- 构建阶段用
golang:1.22-alpine，关键命令：RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags="-s -w" -o main . - 运行阶段优先选
FROM scratch：无 shell、无包管理器、攻击面最小；但前提是没用 cgo（如 sqlite、某些 crypto 库） - 若用了 cgo，改用
FROM alpine:latest并RUN apk --no-cache add ca-certificates - 最后加
USER 65532:65532，避免以 root 运行二进制
最容易被忽略的其实是探针路径和监听地址的严格匹配——它们不像代码能报错，而是静默失败，让你反复 kubectl describe pod 却找不到原因。
