先用 docker run 本地验证镜像：确认能启动、端口监听、/health 返回200；常见问题包括架构不匹配、Alpine缺库、启动后退出、Deployment三字段未对齐、OOMKilled及livenessProbe过早触发。

部署前先确认镜像能本地跑通

别急着 kubectl apply，Go 应用镜像在集群里起不来，80% 的原因出在镜像本身。先用 docker run 在本地验证：是否能启动、端口是否监听、健康接口是否返回 200。

常见卡点：

• exec format error：镜像架构和节点不匹配（比如 x86_64 镜像推到了 arm64 节点），构建时加 GOOS=linux GOARCH=arm64
• standard_init_linux.go:228: exec user process caused: no such file or directory：Alpine 镜像缺 glibc 或动态库，要么改用 debian:slim，要么编译时加 CGO_ENABLED=0
• 启动后立刻退出：没加 CMD ["./main"] 或二进制没给执行权限（chmod +x）

Deployment YAML 必须对齐的三个字段

Go 应用的 Deployment 不是写完就能连上 Service，关键靠三处硬匹配：

• spec.template.metadata.labels（Pod 标签）必须和 spec.selector.matchLabels 完全一致，一个字母都不能错
• spec.template.spec.containers[].ports[].containerPort 值，必须等于 Service 中 spec.ports[].targetPort
• Service 的 spec.selector 必须能命中至少一个 Pod 的标签，否则 kubectl get endpoints 返回空

漏掉任意一项，Service 就成“断头路”，流量根本到不了 Go 进程。

Pod 启动失败时，按顺序查这四条命令

看到 CrashLoopBackOff 或 Pending，别猜，直接敲：

• kubectl get pods -n <namespace></namespace>：看状态和重启次数
• kubectl describe pod <pod-name> -n <namespace></namespace></pod-name>：重点看 Events 区域——FailedScheduling 是资源不够，ImagePullBackOff 是镜像拉不到，OOMKilled 是内存超限
• kubectl logs <pod-name> -n <namespace> --previous</namespace></pod-name>：查上一轮崩溃的日志（Go panic、配置文件打开失败、DB 连接超时都藏在这）
• kubectl exec -it <pod-name> -n <namespace> -- /bin/sh</namespace></pod-name>：进容器手动试 netstat -tuln 看端口、ls -l 看配置文件路径、curl -v http://localhost:8080/health 测健康接口

Go 程序在 K8s 里容易被误杀的两个隐性原因

即使日志显示正常启动，Go 服务仍可能被 kubelet 强制终止，常见于：

• resources.limits.memory 设太小：Go GC 触发时瞬时内存飙升超过 limit，直接 OOMKill。建议初始设 512Mi，上线后根据 container_memory_usage_bytes 指标调优
• livenessProbe 配得太激进：比如 initialDelaySeconds: 5，但 Go 应用加载配置+连 DB 要 8 秒，探针提前失败导致反复重启。应设为实际冷启动耗时的 1.5 倍以上

这两个点不报错、不打日志，只在 kubectl describe pod 的 Events 里留一行 Container killed due to OOM 或 Liveness probe failed，很容易被忽略。