Go应用在Kubernetes中不稳、扩缩容失效、频繁OOMKilled或CrashLoopBackOff，根本原因是部署配置与容器生命周期不匹配：configmap/secret挂载错误、环境变量名不符、探针路径/端口不一致、冷启动未配startupProbe、资源限制不足、镜像构建未设CGO_ENABLED=0 GOOS=linux。
Go 应用在 Kubernetes 里跑不稳、扩缩容失效、频繁 OOMKilled 或 CrashLoopBackOff，根本不是代码写得差，而是部署配置和运行时行为没对齐容器生命周期。
Pod 启动失败时，--previous 日志是唯一可信线索
容器反复崩溃又重启（CrashLoopBackOff）时，当前日志常为空或只有一行“server started”，因为进程已退出。真实错误藏在上一轮崩溃中。
- 必须加
--previous：运行kubectl logs <pod-name> -n <namespace> --previous - 常见真凶包括：
configmap挂载路径错导致配置文件缺失、secret名拼错（regcred≠RegCred）、环境变量名写成DB_URL而非DATABASE_URL - 探针路径错位也常被忽略：
readinessProbe.httpGet.path: /healthz，但 Go 服务只暴露/health，结果永远 404
containerPort 和 Go 监听端口必须字面一致
Kubernetes 不读你的代码，只认 containerPort 字段和探针配置。硬编码 :8080 在 http.ListenAndServe 里，再配 containerPort: 8081，livenessProbe 就会一直报 connection refused。
- Go 代码必须从环境变量读端口：
port := os.Getenv("PORT")，fallback 到"8080" -
containerPort值必须和实际监听端口完全相同（数字、类型），不能只是“差不多” - 若用了 sidecar（如 Nginx），还要确认它转发的目标端口和容器内监听端口一致，否则流量进不来
资源限制和探针延迟不匹配，直接触发重启雪崩
Go 应用冷启动慢（DB 连接池初始化、gRPC dial、缓存 warmup），但很多人把 readinessProbe.initialDelaySeconds 和 livenessProbe.initialDelaySeconds 设成一样，导致还没 ready 就被 liveness 杀掉。
立即学习“go语言免费学习笔记（深入）”；
-
readinessProbe.initialDelaySeconds设小点（3–5 秒），只要端口能accept()就放流量进来 -
livenessProbe.initialDelaySeconds设大些（20–30 秒），给足初始化时间；或改用轻量检查（如进程存活、goroutine 数突增） -
resources.limits.memory至少设为压测后稳定 RSS 的 1.5 倍，否则 GC 频繁或直接 OOMKilled
镜像构建阶段漏掉 CGO_ENABLED=0 GOOS=linux，容器启动就 panic
在 macOS 或 Windows 上本地构建时，若只设 CGO_ENABLED=0 却没指定 GOOS=linux，二进制仍可能隐式依赖 host 系统的动态链接库，进 Alpine/distroless 镜像就报 no such file or directory。
- 多阶段构建中，编译命令必须同时生效：
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o app . - 用
FROM scratch时，CMD必须是绝对路径：CMD ["/app"]，且需提前WORKDIR / - 验证方式：
docker run --rm -it your-image ls -l /app，确认文件存在且有可执行权限
最易被忽略的一点：startupProbe 不是可选项，而是冷启动慢的服务救命稻草。没有它，livenessProbe 就是定时炸弹——尤其当你用了 client-go Informer 初始化、etcd 连接或远程配置拉取时。
