网络策略存在不等于数据面已执行。检查插件支持、选择器、入站与出站，并用允许和拒绝连接做验收。
集群里能查询到 NetworkPolicy 对象，只能证明 API 接受了配置。策略是否作用于目标 Pod、网络插件是否实现所需能力，以及其他策略是否扩大了允许范围，都需要实际验证。
变更前画出必要连接
以一个服务为起点，列出调用方、数据库、DNS、监控和外部依赖，标明命名空间、标签、端口与协议。把健康检查和初始化容器需要的连接一起考虑，避免上线后才发现 DNS 或启动流程被阻断。
Kubernetes 官方文档说明，网络策略的允许规则是叠加的；一条连接需要同时满足源端出站和目的端入站限制。网络插件的支持情况也决定实际效果，因此不能套用防火墙“后面的规则覆盖前面”的思路。
四组连接测试
| 来源与目标 | 预期 |
|---|---|
| 已授权调用方到业务端口 | 成功 |
| 未授权测试 Pod 到同一端口 | 被隔离 |
| 业务 Pod 到必要依赖 | 成功 |
| 业务 Pod 到无关测试目标 | 按策略拒绝 |
使用受控测试服务和指定协议，不以一次 ping 结果代替 TCP 或 UDP 业务验证。跨节点、Pod 重建和标签变化后也应复测，确认策略选择范围仍符合预期。
检查叠加规则与例外
某条过宽的允许策略可能让本来期望隔离的路径重新可达。审查所有作用于目标 Pod 的策略，而不是只阅读本次新增文件。hostNetwork 等特殊场景需要按插件文档单独确认。
保留变更前连接图、策略版本和实际测试结果。出现故障时按最小必要依赖修正配置，并记录原因，避免用全放行策略长期维持业务。
参考：Kubernetes：Network Policies。核对日期：2026年10月4日。
