Kubernetes结合Golang开发微服务实例-Golang-PHP中文网

kubernetes才是部署微服务的系统，go只需写好服务、暴露探针、打轻量镜像、响应sigterm；任一环节缺失都会导致deployment卡在pending或crashloopbackoff。

kubernetes结合golang开发微服务实例

Go 不部署微服务，Kubernetes 才是真正做这件事的系统；Go 的任务是写好服务、暴露探针、打轻量镜像、响应 SIGTERM——漏掉其中任一环，Deployment 就卡在 Pending 或 CrashLoopBackOff。

Deployment 创建失败：Namespace、Labels、Selector 全都得对齐

常见现象是 Replicas: 0、kubectl get pods 空列表、Events 里报 selector does not match template labels。这不是代码 bug，而是 YAML 和 Go 结构体里三处标签没咬合：

Deployment.Spec.Selector.MatchLabels 必须和 PodTemplate.Spec.Labels 完全一致（键和值都要相同）
ClientSet.AppsV1().Deployments(namespace) 的 namespace 参数必须显式传入，不能依赖 Deployment.ObjectMeta.Namespace —— 后者只影响元数据，不决定 API 路径
本地调试时别直接用 rest.InClusterConfig()，它在集群外会 panic；改用 fallback：if os.Getenv("KUBERNETES_SERVICE_HOST") == "" { config, _ = clientcmd.BuildConfigFromFlags("", "/path/to/kubeconfig") }

Dockerfile 多阶段构建写错：镜像超 800MB 还启动失败

错误不是 Go 编译慢，而是把整个构建环境塞进了运行镜像。典型症状是 standard_init_linux.go:228: exec user process caused: no such file or directory（musl vs glibc）、ImagePullBackOff、拉取耗时过长。

Golang Naming

Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。

下载

第一阶段必须加 CGO_ENABLED=0 GOOS=linux go build -a -ldflags="-s -w" -o main .，禁用 cgo + 静态编译 + 剥离符号
第二阶段用 scratch（推荐）或 alpine:latest；COPY --from=builder /app/main .，别带 /usr/local/go 或 go.mod
如果用了 cgo（比如 sqlite），第二阶段得用 alpine 并 RUN apk add --no-cache sqlite-dev，但优先考虑换纯 Go 替代方案
EXPOSE 8080 是注释，真正起效的是 Deployment 中的 containerPort: 8080，且必须和 Go 服务监听地址一致（0.0.0.0:8080，不是 127.0.0.1:8080）

Pod 反复重启（CrashLoopBackOff）：探针和信号处理没配对

日志显示 server started on :8080，几秒后就被 kill —— 这不是服务没起来，是 Kubernetes 认为它“不健康”或“没准备好”，或者进程没正确响应终止信号。

livenessProbe 和 readinessProbe 必须分离路径：/livez（只返回 200）和 /readyz（可查 DB，但别超时）；共用一个端点容易引发雪崩
initialDelaySeconds 至少设为 10（尤其带 DB 连接池初始化时），timeoutSeconds 对 liveness 设 2，对 readiness 设 10+
main 函数里必须捕获 SIGTERM：signal.Notify(quit, syscall.SIGTERM)，然后调用 http.Server.Shutdown(context.WithTimeout(...))，再关闭 DB/redis/gRPC 客户端
别用 os.Exit() 或裸 log.Fatal()，它们跳过 Shutdown，线上会丢请求

Service 访问不到：端口、selector、协议全得链路通

现象是 kubectl port-forward 能通，但 Service ClusterIP 访问超时或连接拒绝。问题不在 Go 代码，而在资源之间没连成闭环。

Service.Spec.Selector 必须和 Pod 的 labels 完全匹配（同 Deployment 的 matchLabels）
Service.Spec.Ports[].targetPort 必须等于 Pod 的 containerPort（数字或名称），不是 Service 的 port
如果 Go 服务监听 0.0.0.0:8080，但 Deployment 写了 containerPort: 9000，Service 就转发失败
HTTP/HTTPS 协议下，确保 Go 服务没强制重定向 HTTP → HTTPS（Service 默认不处理 TLS 终止）