ClusterIP curl超时或503，首要检查Endpoints是否为空；若为空，需核对Service selector与Pod标签是否严格匹配；其次确认Pod READY状态、readinessProbe通过情况、targetPort与containerPort一致性，最后验证kube-proxy运行及iptables规则。
当Service明明存在、Pod也显示Running，但curl ClusterIP却超时或返回503时，流量转发链路已经中断。这不是应用层的问题，而是Service与Pod之间的“登记表”没对上，或是底层转发规则失效。
第一步：确认Endpoints是否为空
执行 kubectl get endpoints <service-name> -n <namespace>，观察输出的ENDPOINTS列。若为空（显示<none>），说明Service根本没关联到任何Pod。
这一步必须最先做——因为90%的“Service不通”问题都卡在这里。空Endpoints不是网络问题，是Service和Pod之间“互相不认识”。
运行 kubectl describe svc <service-name> -n <namespace>，重点看Events区域是否有no endpoints available提示，同时核对Spec→Selector字段值。
用 kubectl get pods -n <namespace> --show-labels 列出所有Pod标签，逐个比对是否严格匹配Service中声明的selector。标签名、值、大小写全部要一致，【一个字符不匹配就会导致Endpoints为空】。
第二步：检查Pod是否真正就绪
即使Pod状态是Running，也不代表它能收流量。Service只把就绪（Ready）的Pod加入Endpoints。
运行 kubectl get pods -n <namespace>，看READY列是否为1/1（或对应副本数）。若显示0/1，说明readinessProbe失败或未配置。
执行 kubectl describe pod <pod-name> -n <namespace>，滚动到Conditions部分，查找Ready: False及对应Reason。常见原因是probe路径返回非200、超时、或容器内服务监听在localhost而非0.0.0.0。
如果Pod没配readinessProbe，kubelet默认认为它就绪；但一旦配置了，就必须通过探针验证——这是硬性规则，【没通过probe的Pod永远不会出现在Endpoints里】。
第三步：验证targetPort与容器实际端口是否一致
方法一：查Service定义中的targetPort字段
运行 kubectl get svc <service-name> -n <namespace> -o jsonpath='{.spec.ports[0].targetPort}'，得到一个数字或名称。
方法二：查容器真实暴露端口
运行 kubectl get pod <pod-name> -n <namespace> -o jsonpath='{.spec.containers[0].ports[0].containerPort}'，对比两个值是否相等。
若targetPort是字符串（如"http"），需确认Service所在命名空间中是否存在对应名称的Port定义；若不匹配，流量会静默丢弃，不会报错也不会记录日志。
第四步：检查kube-proxy是否正常工作
① 查看kube-proxy Pod状态：kubectl get pods -n kube-system | grep kube-proxy，确保所有节点上的Pod都是Running且READY为1/1。
② 检查日志是否有错误：kubectl logs <kube-proxy-pod-name> -n kube-system | tail -20，重点关注failed to sync iptables或can't find node类报错。
③ 登录任一工作节点，执行 iptables -t nat -L KUBE-SERVICES | grep <service-clusterip>，若无输出，说明kube-proxy未成功写入规则——此时即使Endpoints正确，流量也无法转发。
这一步操作起来很简单，直接把文件拖进去就行。
