默认拒绝网络策略如何避免误伤?

默认拒绝网络策略的风险，不在于“拒绝”本身，而在于通信关系尚未厘清就开始拒绝。NetworkPolicy 依赖 CNI 插件实现，策略上线前应先确认插件是否支持入口、出口、端口和选择器规则，并盘点业务真实依赖，否则 DNS、服务发现、监控、日志、发布流水线以及外部 API 都可能被一并切断。

先建立通信基线

至少应梳理六类流量：Pod 到 DNS，Ingress 到应用，应用到数据库、缓存和消息系统，跨命名空间调用，访问云平台 API 或外部 SaaS，以及监控、日志和服务网格控制面到业务 Pod。基线不能只看 Kubernetes 对象，还要结合应用日志、服务探针、消息消费和外部依赖确认实际通信。

实施时不要直接在整个集群开启默认拒绝。更稳妥的顺序是先在隔离环境和单个非关键命名空间验证，再逐步扩大范围；生产命名空间应按业务批次推进，并为每条例外规则记录业务负责人和失效时间。

从小范围拒绝开始

命名空间级策略可以先拒绝全部入口和出口，再按已确认的依赖增加允许规则。允许范围应尽量由命名空间标签、Pod 标签、协议和端口共同限定，避免使用过宽的 ipBlock。DNS、数据库、缓存等基础依赖应分别验证，不能因为 Pod 仍处于 Running 就判断网络正常。

验证应同时包含正向和反向测试：确认 Ingress 能访问应用、应用能访问必要的数据服务，也确认无关命名空间无法连接数据库；随后检查 DNS 解析、健康检查、监控、日志和服务网格状态。被拒绝的连接未必会在应用侧产生清晰错误，因此需要结合网络测试与应用观测判断。

把回滚设计在前面

每次策略变更都应保存版本化清单，并准备恢复上一版策略的路径。发生故障时，先保留事件、控制器日志和发布状态，再恢复关键依赖，不要临时放开全部流量。若某条例外长期存在，应重新评估其业务必要性；默认拒绝的目标不是制造“全封闭”，而是让每一条通信都具备明确的范围、责任人和可验证理由。