应使用 Deployment 管理 Go 应用副本，确保高可用与滚动更新；需正确配置 replicas、标签匹配、监听地址、端口、Service 类型、健康探针及多阶段镜像构建。
用 Deployment 管理 Go 应用副本，别直接起 Pod
Deployment 是 Kubernetes 中管理 Go 应用生命周期的正确入口。它确保指定数量的 Pod 始终运行，并支持滚动更新、回滚和扩缩容。直接写 Pod YAML 会导致无法自动恢复、无法升级、失去声明式优势。
关键点：
-
replicas建议设为 ≥2，单副本无法体现负载均衡意义 -
selector.matchLabels和template.metadata.labels必须完全一致，否则 Deployment 控制器找不到自己的 Pod - Go 二进制必须监听
0.0.0.0:8080（而非127.0.0.1:8080），否则 Service 流量进不来 - 容器
ports.containerPort要与 Go 程序实际监听端口一致，Kubernetes 不做端口转换
Service 类型选错，流量根本到不了 Go 应用
ClusterIP 是默认类型，仅限集群内访问；若想从外部访问（比如浏览器测通），必须显式指定 type: NodePort 或 type: LoadBalancer。NodePort 在开发/测试环境最常用，但要注意端口范围（默认 30000–32767）。
常见错误现象：
-
kubectl get services显示CLUSTER-IP是10.x.x.x，但本地 curl 失败 → 没暴露到节点 - 用了
NodePort，却没在云厂商控制台开安全组或防火墙 → 节点端口被拦截 - Service 的
selector标签和 Deployment 的 Pod 标签不匹配 → Endpoints 为空，kubectl get endpoints返回空
健康探针没配，Kubernetes 会把未就绪的 Go 实例当流量入口
没有 readinessProbe，Kubernetes 会在 Go 应用还没初始化完（比如 DB 连接未建好、配置未加载）时就把 Pod 加入 Service 的 Endpoint 列表，导致请求 502/503。
推荐配置（适配 Go 的轻量 HTTP 服务）：
Kubernetes Skills
下载
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
注意：
-
/ready接口应检查依赖是否就绪（DB、Redis、下游服务），返回 200 才算通过 -
/health可只检查进程存活，比如返回固定字符串 -
initialDelaySeconds必须大于 Go 应用冷启动耗时，否则 probe 频繁失败触发重启循环
镜像构建不精简，Pod 启动慢、资源浪费、有安全风险
直接用 golang:alpine 镜像运行 Go 二进制，会把整个 Go 工具链和调试符号打包进去，镜像体积大、启动慢、攻击面广。
务必用多阶段构建：
FROM golang:1.22-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags="-s -w" -o app . FROM alpine:latest RUN apk --no-cache add ca-certificates WORKDIR /root/ COPY --from=builder /app/app . EXPOSE 8080 CMD ["./app"]
关键参数说明：
-
CGO_ENABLED=0：禁用 cgo，避免依赖 libc，保证纯静态链接 -
GOOS=linux：明确目标系统，避免本地 macOS/Windows 编译出错 -
-ldflags="-s -w"：剥离调试符号和 DWARF 信息，减小二进制体积 30%+ - 最终镜像大小通常 ≤15MB，比单阶段构建小 5–10 倍
真正容易被忽略的是：readinessProbe 和 livenessProbe 的路径必须在 Go 代码里真实实现，且不能阻塞 —— 很多开发者只写了 handler，却忘了注册路由，或者用了第三方框架但没配好中间件顺序，导致探针永远 404。
