Go服务在Kubernetes中起不来，首要排查containerPort与代码监听地址是否一致：http.ListenAndServe(":8080", nil)实际监听127.0.0.1:8080，必须改为"0.0.0.0:8080"，且Deployment中containerPort、livenessProbe.port、Service.targetPort须四者完全对齐。
Kubernetes 不解决 Go 语言服务的“管理问题”，它只解决容器化服务的编排、调度、自愈与发现——Go 本身不管理服务，也不该去管理；真正要做的，是让 Go 服务变成 Kubernetes 能识别、能探活、能滚动、能扩缩的一等公民。
Go 服务起不来？先查 containerPort 和监听地址是否对齐
最常见的 CrashLoopBackOff 或 connection refused，90% 是端口没对上。Kubernetes 的探针、Service、网络策略都依赖 containerPort 这个声明字段，但它必须和 Go 真正监听的地址端口完全一致。
-
http.ListenAndServe(":8080", nil)实际监听的是127.0.0.1:8080，kubelet 从宿主机 namespace 访问不到 - 正确写法必须是
http.ListenAndServe("0.0.0.0:8080", nil)，或从环境变量拼接：http.ListenAndServe("0.0.0.0:" + os.Getenv("PORT"), nil) -
containerPort字段在 Deployment YAML 中不能省略，且值必须等于代码中绑定的端口号（如8080） - 探针配置里的
httpGet.port、Service 的targetPort也得同步设成同一值，四者缺一不可
Pod 反复重启？检查 livenessProbe 是否误杀
Go 进程启动慢（比如连 DB、加载配置），但 livenessProbe 默认 30 秒超时、10 秒间隔，还没等主逻辑跑起来就被 kill -9 了。
- 把
initialDelaySeconds设到足够大（例如60），尤其当有初始化耗时操作时 -
livenessProbe不该做重检查（比如查 DB 连通性），它只负责“进程还活着吗”；重逻辑留给readinessProbe - 如果用了 OpenTelemetry sidecar，它的启动比 Go 主进程慢 2–5 秒，
livenessProbe过早触发会导致整个 Pod 反复重建 - 日志里看到
Terminated: Signal: KILL或OOMKilled，优先怀疑 probe 配置过激或资源 limit 设置过低
滚动更新卡住？Deployment 的 selector 和 labels 必须严格匹配
Kubernetes 不靠“名字”认 Pod，全靠 selector.matchLabels 和 template.metadata.labels 的键值对是否完全一致。错一个字符，新 Pod 就进不了 Service，旧 Pod 也不敢删。
立即学习“go语言免费学习笔记（深入）”；
- 检查 Deployment YAML 中这两处 label 是否逐字相同：
spec: selector: matchLabels: app: go-service template: metadata: labels: app: go-service -
replicas别留空，默认是 1，但生产环境建议显式写为3或按需设定 -
resources.requests和limits必须填，否则调度器无法判断节点是否有足够资源，Pod 会长期处于Pending - 更新镜像后，用
kubectl rollout status deployment/go-service确认UpdatedReplicas == AvailableReplicas == Replicas，别只看kubectl get pods
OpenTelemetry 探针没数据？sidecar 注入有硬性前提
Go 的自动仪表化不是“开箱即用”，tencent-opentelemetry-operator 根本不支持 Go；官方 otel/autoinstrumentation-go sidecar 方案虽可用，但失败率高，往往卡在几个细节上。
- 主容器必须禁用 strip：编译时不能加
-ldflags="-s -w"，否则探针找不到符号表，日志反复报failed to find symbol main.main - sidecar 容器必须设
securityContext.privileged: true，且 Pod 级别开启shareProcessNamespace: true -
OTEL_GO_AUTO_TARGET_EXE环境变量必须指向主容器中二进制的绝对路径（如/app/main），不能是软链接或相对路径 - 如果用了 cgo（比如 sqlite、某些 crypto 库），就不能用
scratch镜像，得保留alpine并apk add对应依赖，否则 sidecar 启动失败
真正的难点不在写代码，而在于让 Go 二进制、Dockerfile、Deployment YAML、探针配置、sidecar 权限这五层严丝合缝——漏掉任何一层，表现都是“服务看似运行，但监控/链路/扩缩全失效”。
