ClusterIP能ping通但curl不通，本质是网络可达（ICMP）与服务可用（TCP）混淆；常见原因包括Pod未就绪仍被转发、targetPort配置错误、Ingress组件干扰、应用绑定127.0.0.1而非0.0.0.0。
ClusterIP 服务能 ping 通但 curl 不通，本质是混淆了“网络可达”和“服务可用”的边界。ping 走 ICMP，只验证 kube-proxy 是否成功把 ClusterIP 映射到节点网络栈（比如 iptables 或 eBPF 规则是否加载），而 curl 走 TCP，依赖后端 Pod 真实就绪、端口监听、健康检查通过、协议匹配等多个环节。以下是几种常见却容易被忽略的隐藏问题：
Pod 未就绪（Ready=False）但仍在 Endpoints 中
K3s 默认使用 readinessProbe 判断 Pod 是否加入 Endpoints。若 probe 配置有误（如路径不存在、超时过短、初始延迟不足），Pod 可能长期处于 0/1 Ready 状态，但因 endpoints controller 同步延迟或缓存，kubectl get endpoints 里仍显示旧 IP。此时 kube-proxy 会继续转发流量，但请求实际发向一个没监听该端口的容器。
- 检查：
kubectl get pods -o wide看 READY 列；kubectl describe pod <name></name>查 Events 和 Conditions - 验证 Endpoints：
kubectl get endpoints <svc-name></svc-name>，对比输出 IP 与kubectl get pods -o wide --selector=<label></label>的实际运行 Pod IP - 临时修复：删掉 readinessProbe 或调宽探测参数，确认服务恢复后再优化
Service 目标端口（targetPort）与 Pod 容器实际监听端口不一致
这是最隐蔽的配置错误之一。ClusterIP 转发依赖 targetPort 正确指向容器内进程监听的端口。若写错（比如写成容器暴露的 port 名但 Service 中用数字，或写成宿主机映射端口），kube-proxy 会把请求转到容器内一个未监听的端口，连接直接被拒绝（curl: Connection refused），而 ping 依然成功。
- 检查：
kubectl get svc <name> -o yaml</name>确认spec.ports[*].targetPort值；再查 Pod 模板中容器ports.containerPort或进程实际监听情况（进容器执行ss -tln或netstat -tln） - 注意：targetPort 可以是字符串（对应 containerPort.name）或整数，二者必须严格匹配
- 建议：统一用整数形式，避免 name 引用拼写错误
K3s 内置 Traefik 或其他 Ingress Controller 干扰了 ClusterIP 流量路径
K3s 默认启用 Traefik 作为 Ingress 控制器，它会监听所有 Service 的 NodePort 和 LoadBalancer 类型，但有时其 webhook 或自动注入逻辑可能意外影响 ClusterIP 的 iptables 规则顺序，尤其在启用了 --disable traefik 后未彻底清理残留规则时。表现为：从集群内 curl ClusterIP 超时或拒绝，但直接 curl Pod IP + 端口正常。
- 排查：
iptables -t nat -L KUBE-SERVICES | grep <cluster-ip></cluster-ip>看是否有异常跳转；或临时停用 Traefik：k3s kubectl delete deploy -n kube-system traefik（K3s v1.22+） - 验证：停用后立即测试 curl，若恢复则说明是 Ingress 组件干扰
- 根治：重装 K3s 时显式加
--disable traefik，或确保清理 /var/lib/rancher/k3s/server/manifests/traefik.yaml
Pod 内应用绑定地址为 127.0.0.1 而非 0.0.0.0
很多开发环境启动的服务默认只监听 localhost（如 flask run、npm start 默认行为），导致容器内可 curl 127.0.0.1，但 ClusterIP 流量经 kube-proxy 转发后到达的是容器 eth0 的 IP（如 10.42.x.x），而应用并未监听该地址，连接被拒绝。
- 检查：进 Pod 执行
ss -tln，看 LISTEN 行的 Local Address 是否含*:<port></port>或0.0.0.0:<port></port>；若只有127.0.0.1:<port></port>就是问题 - 修复：修改应用启动命令，例如 Flask 加
--host=0.0.0.0，Node.js 服务确保server.listen(port, '0.0.0.0') - 验证：在 Pod 内
curl http://<pod-ip>:<port></port></pod-ip>应返回正常响应
这些问题都不涉及网络策略或防火墙，纯粹是 Kubernetes 对象语义、容器运行时行为与底层转发机制之间的错位。定位时优先看 Ready 状态、Endpoints、targetPort、容器监听地址这四点，基本覆盖 90% 的“能 ping 不能 curl”场景。
