先查 endpoints 是否为空：若 kubectl get endpoints -n 的 endpoints 列为空，说明 service 未匹配到 pod；再检查 selector 与 pod labels 是否完全一致、pod 是否处于 running 且 ready 为 1/1、readinessprobe 配置是否合理生效。
Service 无法访问时，先确认 Endpoints 是否为空
Service 不通，90% 的情况不是 DNS 或网络策略问题，而是后端根本没有 Pod 被正确关联进来。直接看 Endpoints 是最快路径：
- 运行
kubectl get endpoints my-service -n default，如果输出中ENDPOINTS列为空，说明 Service 没有匹配到任何 Pod - 检查 Service 的
selector字段是否与 Pod 的labels完全一致（注意大小写、拼写、键值对数量） - 确认目标 Pod 处于
Running状态且就绪（READY列为1/1），而非0/1—— 后者通常意味着readinessProbe未通过
Go 应用健康端点返回 200 却被标记为不健康？检查 timeoutSeconds 和启动顺序
Go 程序启动快，但若依赖数据库连接或配置加载，/health 端点可能在进程启动后几秒内仍不可用。Kubernetes 默认的 timeoutSeconds: 1 极易误判。
-
timeoutSeconds必须 ≥ 应用冷启动时最慢一次健康检查响应时间，建议设为3或5 -
initialDelaySeconds要覆盖 Go 应用完整初始化耗时，例如：DB 连接池建立 + 配置热加载 + 缓存预热，至少预留15~30秒 - 避免在
livenessProbe中调用依赖外部服务的逻辑（如查 DB、发 HTTP 请求），否则一次下游抖动就会触发重启循环
kube-proxy 状态异常导致 ClusterIP 不可达
ClusterIP 类型的 Service 在节点上依赖 kube-proxy 同步 iptables/IPVS 规则。如果规则缺失，Pod 就无法通过 Service 名称访问其他服务。
- 运行
kubectl get pods -n kube-system -l k8s-app=kube-proxy，确认所有节点上的kube-proxyPod 都是Running - 在任意节点执行
iptables -t nat -L | grep my-service，若无匹配行，说明规则未同步 —— 常见于 kube-proxy 启动失败或配置了错误的--proxy-mode - 若集群使用 IPVS 模式，还需检查
ipvsadm -ln输出中是否有对应 virtual server 和 real server 条目
Go 应用里手动实现健康检查时，别忽略 readiness 与 liveness 的语义隔离
很多 Go 项目用一个 /health 接口同时响应两种探针，这是隐患根源。Kubernetes 期望它们承担不同职责。
-
livenessProbe应只检查进程是否存活（例如：HTTP handler 是否注册成功、goroutine 是否卡死），不涉及外部依赖 -
readinessProbe可包含 DB 连接、Redis 可用性、依赖服务连通性等，失败时仅下线流量，不重启容器 - 推荐在 Go 中拆成两个独立 endpoint：
/live（轻量）和/ready（带依赖检查），并在 Deployment 中分别引用
readinessProbe 是否真的生效 —— 很多团队只写了 probe，却没确认 Pod 的 READY 状态是否随 probe 结果动态变化。只要它始终显示 1/1，哪怕 probe 返回 503，也说明配置未生效或 probe 路径写错。
