Kubernetes服务互通失败，先别急着改NetworkPolicy：四步定位真实阻断点

Kubernetes 中“服务 A 访问不了服务 B”并不等于 NetworkPolicy 拒绝了流量。过早修改策略，可能把原本清晰的故障变成更难回滚的配置问题。

第一步确认 Service 真的指向 Pod

kubectl get svc api -n app -o wide kubectl get endpointslice -n app -l kubernetes.io/service-name=api

如果 EndpointSlice 没有地址，先检查 selector、Pod 标签和 readiness。Service 没有后端时，策略放行也不会产生有效连接。

第二步从调用 Pod 内测试

不要只在节点上 `curl`。进入实际调用方容器：

kubectl exec -n app deploy/web -- \ wget -S -O- --timeout=5 http://api:8080/health

DNS 失败说明服务发现或命名空间写错；连接拒绝通常意味着目标端口没有监听；超时才需要重点检查网络路径和策略。不同错误对应不同层，不要用同一个结论覆盖全部情况。

第三步确认策略的选择范围

kubectl get networkpolicy -A kubectl describe networkpolicy allow-api -n app

NetworkPolicy 的 podSelector 默认只在当前命名空间内匹配。跨命名空间访问通常还需要 namespaceSelector，并且 ingress 与 egress 是两个方向。只允许入口而禁止出口，同样可能导致请求失败或回包异常。

修改前先保存现状，使用最小范围的临时策略验证假设。验证完成后立即收紧，不要把 `0.0.0.0/0` 或所有命名空间永久放行到生产环境。

第四步确认实现支持

不同 CNI 对 NetworkPolicy 的能力和日志位置不同。策略对象创建成功，不代表底层一定执行了相同语义。需要结合集群使用的 CNI 文档和流量日志确认实际行为。

建议的排查顺序

按“Service → EndpointSlice → Pod 内 DNS → Pod 内 TCP → 双向策略 → CNI 日志”的顺序推进，每次只改变一个变量，并记录恢复时间和回滚方式。这样即使最终不是策略问题，也能留下可复用的故障证据。

排查时还要确认端口含义。Service 的 `port`、`targetPort` 和容器实际监听端口可能不同，名称形式的 targetPort 还依赖 Pod 端口名匹配。可以用 `kubectl get svc api -o yaml` 和 `kubectl get pod -o yaml` 对照，而不是只看 Service 的简短列表。

如果请求经过 Ingress 或服务网格，客户端到入口、入口到后端可能是两段不同连接。入口返回 404 可能是路由规则不匹配，后端超时才是网络策略或应用处理问题。把观测点放在调用 Pod、入口代理和目标 Pod 三处，才能知道哪一段真正丢失。

如果你正在学习容器安全、云原生网络和防御实践，可以参考马士兵网络安全课程的相关入口：