Go用于编写Kubernetes微服务代码，需实现健康检查端点、多阶段构建轻量镜像、编写含探针和资源限制的Deployment与Service YAML，并用kind本地验证。
Go 本身不直接“构建 Kubernetes 微服务”，它只是用来写服务代码的语言；Kubernetes 是运行时编排平台。真正要做的，是用 Go 写一个符合微服务惯例的 HTTP/gRPC 服务，打成容器镜像，再用 Kubernetes 的 Deployment、Service、Ingress 等资源描述如何部署和暴露它。
用 net/http 或 gin 写一个可健康检查的 Go 服务
Kubernetes 依赖就绪（readiness）和存活（liveness）探针，所以你的 Go 服务必须暴露明确的 HTTP 端点，比如 /healthz 和 /readyz。不要只写一个 / 路由就完事。
常见错误：本地跑通了，但没加健康检查端点，导致 Pod 卡在 ContainerCreating 或反复重启。
- 用
http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) { w.WriteHeader(200) })最简实现 - 若用
gin，记得调用r.GET("/healthz", func(c *gin.Context) { c.Status(200) }) -
端口固定用
8080（或显式声明），避免硬编码到环境变量外——Kubernetes 的containerPort要和代码监听端口一致 - 启动时打印日志表明服务已监听，例如
log.Printf("server started on :8080")，方便排查CrashLoopBackOff
构建多阶段 Docker 镜像，别打包整个 $GOPATH
Go 编译产物是静态二进制，不需要运行时依赖 Go 环境。用多阶段构建能将镜像压到 ~10MB 以内，否则可能因基础镜像过大、拉取超时导致 ImagePullBackOff。
立即学习“go语言免费学习笔记（深入）”；
关键点：第一阶段用 golang:1.22-alpine 编译，第二阶段用 alpine:latest 或 scratch 运行。
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 -o main . <p>FROM alpine:latest RUN apk --no-cache add ca-certificates WORKDIR /root/ COPY --from=builder /app/main . CMD ["./main"]
- 务必加
CGO_ENABLED=0，否则二进制会动态链接 libc，无法在scratch中运行 - 如果用了
cgo（如 SQLite、某些加密库），就不能用scratch，得保留alpine并安装对应库 -
Dockerfile中不要go run main.go—— 这会在镜像里留 Go 环境，增大体积且不安全
编写最小可用的 Deployment + Service YAML
Kubernetes 不认 “微服务” 这个词，只认资源对象。一个最小可部署单元，至少需要 Deployment 控制副本，和 Service 提供稳定网络端点。
容易忽略的坑：容器端口没暴露、标签（selector）不匹配、资源限制缺失导致 OOMKilled。
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-api
spec:
replicas: 2
selector:
matchLabels:
app: go-api
template:
metadata:
labels:
app: go-api
spec:
containers:
- name: api
image: your-registry/go-api:v1.2
ports:
- containerPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 30
readinessProbe:
httpGet:
path: /readyz
port: 8080
initialDelaySeconds: 5
resources:
requests:
memory: "64Mi"
cpu: "100m"
limits:
memory: "128Mi"
cpu: "200m"
<hr /><p>apiVersion: v1
kind: Service
metadata:
name: go-api-svc
spec:
selector:
app: go-api
ports:</p><ul><li>protocol: TCP
port: 80
targetPort: 8080-
selector.matchLabels必须和 Pod 模板里的metadata.labels完全一致，否则 Service 找不到后端 -
targetPort是容器内端口（8080），port是 Service 暴露的端口（80），别写反 - 不加
resources.limits，Pod 可能被节点驱逐；不加requests，调度器无法判断能否调度
本地调试用 kind 或 minikube，别等推到集群才测
把 YAML 丢进生产集群试错成本太高。用 kind（Kubernetes IN Docker）搭一个单节点集群，5 秒启动，完全兼容标准 API。
典型流程：改代码 → docker build -t go-api:dev . → kind load docker-image go-api:dev → kubectl apply -f deploy.yaml → kubectl logs -f deploy/go-api。
- 用
kind时，镜像必须先load进集群，不能靠远程 registry —— 默认配置下它不连外网 -
kubectl port-forward service/go-api-svc 8080:80可直接本地访问服务，不用配 Ingress - 查问题优先看
kubectl describe pod <name>，Events 里常有FailedMount、ImagePullBackOff等关键线索
真正卡住的往往不是 Go 语法或 Kubernetes 概念，而是镜像构建阶段的 CGO 设置、YAML 里 label 键值拼写不一致、probe 路径返回非 2xx 状态码这种细节。每次变更只动一点，验证一点，比堆一堆配置再一起上线靠谱得多。
