Go服务在Kubernetes中起不来，主因是Deployment的labels与selector不匹配、端口未对齐（代码监听0.0.0.0:8080、containerPort、探针port、targetPort四者必须一致）、Dockerfile未禁用CGO且未使用scratch基础镜像。
Go 服务在 Kubernetes 里跑不起来，90% 是因为 Deployment 没绑对镜像、探针或端口——不是代码写得不对，是容器没“活”成 Kubernetes 认可的 Pod。
Deployment 必须显式声明 labels 和 selector 匹配
Kubernetes 不靠文件名或目录结构识别 Pod，只认 selector.matchLabels 和 template.metadata.labels 是否完全一致。漏掉一个 key 或值对不上，Deployment 就创建不了 Pod，kubectl get pods 看不到任何实例。
-
selector.matchLabels必须和template.metadata.labels完全相同（包括大小写） - 别复用其他项目的 label 值，比如
app: api要确保所有地方都写api，不是API或apiserver - Deployment 创建后，用
kubectl describe deployment go-app查看 Events，常见报错是SelectorMismatch
Dockerfile 多阶段构建必须禁用 CGO 并切换基础镜像
直接用 FROM golang:alpine 运行编译好的二进制，等于把 Go 工具链、包管理器、shell 全塞进生产环境——体积大、启动慢、攻击面宽。
- 构建阶段用
golang:1.22-alpine，但务必加CGO_ENABLED=0 GOOS=linux，否则生成的二进制仍依赖 libc - 运行阶段优先选
FROM scratch：无 shell、无用户、无包管理器，镜像通常 - 如果用了 cgo（比如
net包调用系统 DNS 或某些 crypto 库），就只能退到alpine:latest，并apk add ca-certificates - 别漏
USER 65532:65532——Kubernetes 默认禁止 root 启动容器，不设非 root 用户会卡在CreateContainerError
HTTP 探针路径必须真实存在且监听 0.0.0.0
Kubernetes 的 livenessProbe 和 readinessProbe 是 HTTP GET 请求，发到 Pod IP + containerPort。路径不存在、服务没监听、端口不一致，都会导致 Probe 失败，Pod 反复重启。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- Go 代码里至少暴露两个端点：
/healthz（只返回 200）和/readyz（可加 DB 连通性检查，但别超 2s） -
http.ListenAndServe(":8080", nil)是对的；http.ListenAndServe("127.0.0.1:8080", nil)是错的——Pod IP 不是 loopback - Deployment 中
containerPort: 8080必须和 Go 代码监听端口、探针port完全一致 -
initialDelaySeconds别设太小：readinessProbe至少 5s，livenessProbe至少 30s，给应用留出初始化时间
ConfigMap/Secret 注入配置时，环境变量名区分大小写且不能含点
Go 读 os.Getenv("DB_HOST")，但 ConfigMap 里写成 db.host: "10.0.1.5"，Kubernetes 不会自动转成下划线或大写——它只会把键原样当环境变量名，而 . 在环境变量里非法，会被忽略。
- ConfigMap 键名只能含字母、数字、下划线，如
DB_HOST、REDIS_PORT - 在 Deployment 中用
envFrom: [{configMapRef: {name: my-config}}]注入时，确保 ConfigMap 的 data 字段键名合法 - Secret 同理，且记得 base64 编码值（
echo -n "password" | base64），不要手敲乱码 - 验证是否注入成功：
kubectl exec -it <pod-name> -- env | grep DB</pod-name>
最容易被跳过的其实是日志和信号处理：没加 log.Printf("server started on :8080")，CrashLoopBackOff 时连启动失败都不知道；没监听 SIGTERM，滚动更新时连接被粗暴中断。这些不写在 YAML 里，但决定了服务到底“稳不稳定”。
