go应用本身不部署微服务，kubernetes才负责部署与管理；需暴露/healthz和/readyz探针、监听0.0.0.0、禁用cgo构建轻量镜像、严格匹配labels和端口、配置合理探针与优雅关闭机制，否则pod易卡在containercreating或crashloopbackoff。
Go 应用本身不“部署”到 Kubernetes，它只是被 Kubernetes 部署——你只需确保二进制能跑、端口对得上、探针路径写准、镜像够轻，否则 Pod 会卡在 ContainerCreating 或反复 CrashLoopBackOff。
Go服务必须暴露/healthz和/readyz端点
Kubernetes 的 livenessProbe 和 readinessProbe 不会猜你的健康逻辑，只做 HTTP GET 请求并检查状态码。缺这两个端点，Pod 很可能起不来，或刚起来就被杀掉。
-
/healthz应返回200，不做 DB 查询、不连下游——它只回答“进程还活着吗” -
/readyz可查 DB 连通性、Redis 是否可写，但超时建议设为timeoutSeconds: 10，避免拖慢滚动更新 - 路径名必须和 Deployment YAML 中的
httpGet.path完全一致（比如 YAML 写的是/health，代码却只注册了/healthz，探针永远 404） - 端口也要匹配：代码监听
:8080，YAML 中containerPort却写成80，探针连不上
Dockerfile 必须用多阶段构建 + CGO_ENABLED=0
镜像太大不只是浪费空间——它直接导致 ImagePullBackOff、节点磁盘爆满、CI 流水线卡住。
Kubernetes Skills
下载
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
- 第一阶段用
golang:1.22-alpine，关键命令是：RUN CGO_ENABLED=0 GOOS=linux go build -a -o main . - 第二阶段必须用
scratch或alpine:latest，绝不能FROM golang直接跑 - 如果用了 cgo（比如
sqlite3或某些加密库），就不能用scratch，得保留alpine并apk add对应依赖 - 入口命令必须是
./main，不是go run main.go——后者会把整个 Go 工具链打进镜像
Deployment YAML 中 labels 和 selector 必须严格匹配
这是最常被忽略的硬性约束，截至 2026 年 9 月 16 日，Kubernetes 仍要求 spec.selector.matchLabels 和 template.metadata.labels 完全一致，一个字母都不能差。
- 比如
matchLabels: {app: go-app}，那template.metadata.labels也必须是{app: go-app}，不能是{app: goapp}或多加一个version: v1 -
containerPort值必须和 Go 代码中ListenAndServe的端口一致（如":8080"→containerPort: 8080） - 镜像 tag 强烈建议用具体版本（如
v1.2.3），别用latest——后者会让滚动更新失效，且无法回滚
Service 类型选错会导致服务根本不可达
ClusterIP 是默认类型，仅限集群内部访问；如果你希望外部调用，必须显式指定其他类型。
-
NodePort：适合开发测试，通过任意节点 IP + 端口（如30080）访问，但端口范围固定在30000–32767 -
LoadBalancer：云厂商集成，自动分配公网 IP，但需注意费用和延迟 - 别漏写
spec.selector——它必须和 Deployment 的labels完全一致，否则 Service 找不到后端 Pod - 若用
Ingress，记得确认 Ingress Controller（如 nginx-ingress 或 ingress-nginx）已部署并运行正常
真正卡住人的往往不是语法错误，而是探针路径拼写差一个字符、containerPort 和代码监听端口不一致、或者 selector 和 labels 表面相似实则不等——这些细节在 kubectl describe pod 的 Events 里才看得见，别只盯着 kubectl get pods 看状态。
