Go微服务部署需确保静态编译（CGO_ENABLED=0）、多阶段构建精简镜像、探针配置匹配实际启动耗时、容器端口命名明确、HTTP客户端设超时，否则易因ABI不兼容、镜像臃肿、探针误杀、路由混乱或级联超时导致失败。
Go微服务部署不是“写完代码扔进Docker再kubectl apply”就能跑通的事。真正卡住人的，往往在镜像构建阶段的静态链接缺失、Kubernetes中livenessProbe配置不当导致反复重启、或者多服务间因http.DefaultClient未设超时引发级联雪崩——这些都不是文档里一句“推荐使用官方镜像”能覆盖的。
Go二进制编译必须加-static标志
默认go build生成的可执行文件依赖宿主机glibc，在Alpine等轻量镜像里直接报no such file or directory（其实是找不到动态链接库）。这不是路径问题，是ABI不兼容。
- 正确做法：始终用
CGO_ENABLED=0 go build -a -ldflags '-extldflags "-static"' -o app . - 若必须启用CGO（比如用了
cgo调用OpenSSL），则基础镜像不能选Alpine，得换debian:slim或ubuntu:22.04 -
-a参数强制重编译所有依赖，避免本地缓存污染镜像一致性
Dockerfile里不要用COPY . /app
把整个源码目录COPY进镜像，不仅体积暴增，还会意外暴露go.mod、.git甚至本地config.yaml——生产镜像应该只含运行时必需项。
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 推荐多阶段构建：
FROM golang:1.23-alpine AS builder编译，再FROM alpine:latest仅COPY二进制和必要配置 - 用
WORKDIR /app后，只COPY --from=builder /app/app .，别碰go.sum或测试文件 - 如果服务需读取配置文件，用
ENV CONFIG_PATH /app/config.yaml而非硬编码路径，方便Kubernetes ConfigMap挂载
Kubernetes探针不能照抄示例值
很多教程直接复制initialDelaySeconds: 10，结果服务启动慢于10秒就被Kubelet杀掉重启，形成“启动→探针失败→kill→重启”死循环。
- 先实测本地冷启动耗时：
time ./app && curl -f http://localhost:8080/health，取P95值再加2秒作为initialDelaySeconds -
periodSeconds设太小（如2秒）会压垮健康检查端点，尤其当服务本身带DB连接池初始化时 -
readinessProbe和livenessProbe路径必须不同：前者检查是否就绪接收流量（如DB连通+缓存预热），后者只确认进程存活（如/health返回200即可）
多容器Pod里端口命名容易被忽略
Deployment里定义了两个container，都暴露8080端口，但没给name字段，后续Service做targetPort映射时会失效——Kubernetes无法区分哪个8080对应哪个容器。
- 每个
containerPort必须带name：name: user-api或name: metrics - Service的
targetPort必须与之严格匹配，不能只写数字 - 同一Pod内多个容器监听相同端口（如都用8080）是允许的，但必须通过
name隔离，否则Service路由会随机转发
真正麻烦的从来不是“怎么部署”，而是当三个服务同时上线后，发现用户服务调订单服务超时，查日志只看到context deadline exceeded——这时候才意识到，从没给http.Client设过Timeout，也没在Kubernetes里配service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout。部署流程的终点，其实是可观测性配置的起点。
