K8s怎么排查Service无法正确转发流量到后端Pod-LINUX-PHP中文网

clusterip curl超时或503，首要检查endpoints是否为空；若为空，需核对service selector与pod标签是否严格匹配；其次确认pod ready状态、readinessprobe通过情况、targetport与containerport一致性，最后验证kube-proxy运行及iptables规则。

k8s怎么排查service无法正确转发流量到后端pod

当Service明明存在、Pod也显示Running，但curl ClusterIP却超时或返回503时，流量转发链路已经中断。这不是应用层的问题，而是Service与Pod之间的“登记表”没对上，或是底层转发规则失效。

第一步：确认Endpoints是否为空

执行 kubectl get endpoints <service-name> -n <namespace></namespace></service-name>，观察输出的ENDPOINTS列。若为空（显示），说明Service根本没关联到任何Pod。

这一步必须最先做——因为90%的“Service不通”问题都卡在这里。空Endpoints不是网络问题，是Service和Pod之间“互相不认识”。

运行 kubectl describe svc <service-name> -n <namespace></namespace></service-name>，重点看Events区域是否有no endpoints available提示，同时核对Spec→Selector字段值。

用 kubectl get pods -n <namespace> --show-labels</namespace> 列出所有Pod标签，逐个比对是否严格匹配Service中声明的selector。标签名、值、大小写全部要一致，【一个字符不匹配就会导致Endpoints为空】。

第二步：检查Pod是否真正就绪

即使Pod状态是Running，也不代表它能收流量。Service只把就绪（Ready）的Pod加入Endpoints。

运行 kubectl get pods -n <namespace></namespace>，看READY列是否为1/1（或对应副本数）。若显示0/1，说明readinessProbe失败或未配置。

执行 kubectl describe pod <pod-name> -n <namespace></namespace></pod-name>，滚动到Conditions部分，查找Ready: False及对应Reason。常见原因是probe路径返回非200、超时、或容器内服务监听在localhost而非0.0.0.0。

Cloud Service Agreement

起草并填写 SaaS 协议模板——云合同、MSA、订单表格、软件许可、试点协议、设计合作伙伴协议，并提供多种变体。

下载

如果Pod没配readinessProbe，kubelet默认认为它就绪；但一旦配置了，就必须通过探针验证——这是硬性规则，【没通过probe的Pod永远不会出现在Endpoints里】。

第三步：验证targetPort与容器实际端口是否一致

方法一：查Service定义中的targetPort字段
运行 kubectl get svc <service-name> -n <namespace> -o jsonpath='{.spec.ports[0].targetPort}'</namespace></service-name>，得到一个数字或名称。

方法二：查容器真实暴露端口
运行 kubectl get pod <pod-name> -n <namespace> -o jsonpath='{.spec.containers[0].ports[0].containerPort}'</namespace></pod-name>，对比两个值是否相等。

若targetPort是字符串（如"http"），需确认Service所在命名空间中是否存在对应名称的Port定义；若不匹配，流量会静默丢弃，不会报错也不会记录日志。