kubectl get svc api -o jsonpath='{.spec.selector}'
kubectl get pod -l app=api --show-labels
kubectl get endpoints api
Service 的 ClusterIP 能 ping 通，curl 却报 connection refused，kubectl get endpoints api 返回 ENDPOINTS 为空。这类现象通常不是突然出现的，往前翻半天日志能看到苗头。
追下去是这么回事：Service 靠 selector 匹配 Pod 标签，Deployment 模板里的 app 从 api 改成了 api-server，selector 还写着 api。没有 Endpoints 时 kube-proxy 没有后端可转。
围绕「Service 标签不匹配」排查时，命令行跑一遍比在面板里点十次有用，面板会替你做掉不少隐式操作。同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。
把这次用到的命令存进笔记，比记住结论有用，换个环境还能照着走。改完隔一天再看一次，当场正常不代表能稳住。
测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。
处理上按这个顺序：把 Service 的 selector 和 Pod 的实际 labels 并排 diff；确认改的是 Pod 模板标签 不是 Deployment 自身的标签；改完等几秒再看 endpoints 必要时重建 Service；用 kubectl port-forward 先排除应用自身没监听。
确认没问题再收工，endpoints 里出现 Pod IP:8080 curl ClusterIP 返回 200。