Kubernetes 中“服务 A 访问不了服务 B”并不等于 NetworkPolicy 拒绝了流量。过早修改策略可能把原本清晰的故障变成更难回滚的配置问题。第一步确认 Service 真的指向 Podkubectl get svc api -n app -o wide kubectl get endpointslice -n app -l kubernetes.io/service-nameapi如果 EndpointSlice 没有地址先检查 selector、Pod 标签和 readiness。Service 没有后端时策略放行也不会产生有效连接。第二步从调用 Pod 内测试不要只在节点上 curl。进入实际调用方容器kubectl exec -n app deploy/web -- \ wget -S -O- --timeout5 http://api:8080/healthDNS 失败说明服务发现或命名空间写错连接拒绝通常意味着目标端口没有监听超时才需要重点检查网络路径和策略。不同错误对应不同层不要用同一个结论覆盖全部情况。第三步确认策略的选择范围kubectl get networkpolicy -A kubectl describe networkpolicy allow-api -n appNetworkPolicy 的 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 三处才能知道哪一段真正丢失。如果你正在学习容器安全、云原生网络和防御实践可以参考马士兵网络安全课程的相关入口