适用场景：已有K8s网络策略基础认知，准备把Pod访问控制从试点命名空间推向更多业务命名空间的团队；本文不重复讲“NetworkPolicy是什么”，重点放在灰度上线、验收和回滚。
K8s网络策略真正进入生产流程时，风险往往来自“默认拒绝已经生效，但依赖关系没有盘清”。一次策略变更可能同时影响服务调用、DNS解析、健康检查、跨命名空间访问和外部API出站。如果没有灰度批次、观测口径和回滚条件，Pod访问控制很容易从安全治理动作变成业务中断事件。下面先从上线前的依赖盘点开始，把NetworkPolicy变更拆成可验收的流程。
上线前先做依赖清单，而不是先改策略
NetworkPolicy灰度上线的第一步不是写新规则，而是确认“哪些流量需要继续存在”。在老系统、共享命名空间或微服务数量较多的集群里，调用关系可能散落在Service、环境变量、配置中心、健康检查、Job任务和外部API中，直接默认拒绝会把这些隐性依赖一次性暴露出来。
上线前至少盘点四类依赖：
- 服务调用：同命名空间和跨命名空间的HTTP、gRPC、TCP连接，尤其是网关到后端、后端到数据库代理、异步任务到消息队列。
- 平台组件：CoreDNS、Ingress Controller、Service Mesh边车、监控采集器、日志Agent和镜像拉取相关组件。
- 探针与运维入口：readiness、liveness、Prometheus scrape、运维堡垒机或诊断Pod访问路径。
- 外部出站：云服务API、对象存储、License服务、Webhook、制品仓库、第三方回调和NTP等基础依赖。
图1：K8s网络策略上线前应先把隐性访问关系收敛为可审核依赖清
在 K8s容器 体系里，网络策略更适合作为发布治理的一部分，而不是单独交给某个安全规则文件。平台团队需要给出边界和模板，业务团队需要确认调用依赖，SRE或运维团队需要定义观测与回滚窗口。
标签准备决定Pod访问控制是否可持续
依赖清单确认后，第二步是检查Namespace和Pod标签是否足够稳定。很多NetworkPolicy事故并不是规则写错，而是策略上线时匹配正常，下一次应用发布后Pod标签变了，导致允许路径失效或保护对象漂移。
| 准备项 | 验收问题 | 不满足时的风险 |
|---|---|---|
| Namespace标签 | 命名空间是否有环境、租户、团队或业务域标签 | 跨命名空间放行范围过宽或完全不匹配 |
| Pod标签 | 工作负载是否有稳定的`app`、`component`、`tier`等标签 | 发布后新Pod不被策略选中或被错误选中 |
| Service到Pod映射 | Service selector是否与Pod标签一致 | 只验证Service连通，忽略后端Pod真实边界 |
| 发布模板 | Helm、Kustomize或GitOps模板是否会覆盖标签 | 灰度批次通过，正式发布后策略失效 |
| 责任归属 | 谁维护标签、谁审批策略、谁确认回滚 | 异常时无法快速判断该撤策略还是修标签 |
标签不稳定时先暂停默认拒绝
如果标签还处在临时命名、多人手工维护或不同环境不一致的状态，不建议直接启用默认拒绝。更稳妥的方式是先补标签治理：统一命名空间标签，确认Deployment、StatefulSet、Job和CronJob模板内的Pod标签，再用只读方式核对策略能选中哪些对象。
关键判断是：策略应该依赖稳定标签，而不是依赖当前刚好存在的一组Pod。只有这样，Pod滚动发布、扩缩容、节点迁移或副本重建后，访问边界才不会随机变化。
默认拒绝要先限定爆炸半径
默认拒绝是Pod访问控制的核心动作，但它不适合一开始就覆盖全部命名空间。生产上线时应先选低风险命名空间或单个工作负载验证，再逐步扩大到同业务域、同租户或同环境。
建议按下面顺序灰度：
- 测试命名空间验证：用与生产相同标签和依赖模型的测试命名空间跑完整策略。
- 非核心业务试点：选择调用链短、回滚窗口明确、业务方能即时验收的工作负载。
- 单方向收敛：先收敛Ingress或Egress中的一个方向，确认观测信号稳定后再推进另一个方向。
- 按业务域扩展：按团队、租户、服务组或环境批次推进，不跨多个不相关业务同时上线。
- 关键业务单独窗口：核心交易、登录、支付、控制面组件等需要单独变更窗口和回滚演练。
图2：灰度上线时要同时检查策略选择器、访问方向和依赖放行结果
DNS和出站例外要提前写入验收项
很多NetworkPolicy变更看起来只限制业务端口，实际最先暴露的却是DNS解析、外部API访问或监控探针失败。尤其启用Egress控制后，Pod访问CoreDNS、外部域名、对象存储或Webhook地址，都可能需要单独放行。
不要把“业务服务可访问”当成唯一验收
灰度批次里至少要覆盖三类验证：业务端点是否可访问、非授权来源是否被拒绝、基础依赖是否仍然正常。只跑一个`curl`成功，并不能证明策略已经安全上线。
kubectl get networkpolicy -n demo
kubectl get pod -n demo --show-labels
kubectl exec -n demo deploy/frontend -- nslookup api.demo.svc.cluster.local
kubectl exec -n demo deploy/frontend -- curl -sS http://api:8080/healthz
kubectl exec -n demo deploy/unauthorized -- curl -m 3 http://api:8080/healthz上面的命令只作为验证思路：前两条确认策略和标签，第三条验证DNS，第四条验证允许路径，第五条验证非授权路径是否被阻断。真实环境还需要补充Prometheus采集、Ingress探针、Job任务和外部依赖检查。
如果你还在梳理网络、安全和容器运行基础，可以把NetworkPolicy上线清单与 Kubernetes容器专题 中的RBAC、镜像安全和运行时治理内容串起来看：网络边界负责“能不能连”，权限和身份体系负责“能不能操作”。
观测指标要能区分策略问题和业务问题
NetworkPolicy上线后，访问失败不一定都来自策略，也可能是Service解析、Pod未就绪、应用超时、证书过期或依赖服务异常。观测设计的目标，是让团队尽快判断“是不是这次网络策略变更导致”。
建议在变更窗口内盯住这些信号：
- 连接失败：应用日志中的connection refused、timeout、no route、TLS handshake失败等异常是否集中出现。
- DNS异常：解析失败、CoreDNS错误率、Pod内`nslookup`或业务日志中的域名解析异常。
- 探针状态：readiness失败是否导致Service后端减少，liveness失败是否引发不必要重启。
- 监控采集：Prometheus scrape失败、日志采集断点、服务网格指标缺口。
- 业务指标：接口错误率、队列堆积、订单或任务处理延迟是否与策略生效时间吻合。
验收结论要写清“继续推进”或“立即回退”
灰度不是观察一会儿就继续推进，而是要提前定义验收条件。例如：允许路径全部通过、非授权路径被拒绝、核心业务错误率无异常、DNS和监控采集正常、业务方完成确认。只要其中一项失败，就不应扩大策略覆盖范围。
可以把灰度结果分成三类：
- 继续推进：允许路径、拒绝路径、基础依赖和业务指标都符合预期。
- 暂停修正：发现依赖遗漏或标签问题，但未影响关键业务，先补规则或标签后重测。
- 立即回滚：业务不可用、核心探针失败、DNS异常扩大或无法判断影响范围。
回滚计划要比策略文件更早准备
NetworkPolicy回滚不能只写“删除策略”。生产环境里可能存在多条策略共同作用，同一个Pod也可能同时被多个策略选中。随手删除某条策略，可能恢复了当前业务，也可能打开了不该开放的路径。
更可靠的回滚方式，是在上线前就明确回滚对象、触发条件、审批人和验证命令。
图3：K8s网络策略灰度上线应包含依赖盘点、分批验证、观测验收
回滚清单建议包含：
- 触发条件：错误率、连接失败、DNS异常、业务方告警或探针失败达到什么程度就回滚。
- 回滚对象：撤销哪一个NetworkPolicy、恢复哪一版策略、是否只回滚某个命名空间。
- 执行方式：通过GitOps回退提交、恢复上一个发布包，还是临时删除策略后再补正式变更。
- 验证步骤：回滚后验证允许路径、拒绝路径、DNS、探针和业务指标是否恢复。
- 复盘边界：记录漏盘依赖、标签问题或观测缺口，避免下一批重复踩坑。
回滚后不要忘记保留最小隔离目标
回滚的目标是恢复业务，不是放弃网络边界。一次灰度失败后，应把失败原因拆出来：是标签不稳定、DNS例外遗漏、跨命名空间依赖未确认，还是观测口径不足。修正后再进入下一轮小批次，而不是直接把默认拒绝推迟到无法落地。
一张上线验收表串起平台和业务团队
NetworkPolicy灰度上线涉及平台、安全、业务和运维，多数失败不是单个字段问题，而是交接不清。建议把验收表放进发布流程，作为变更前、变更中和变更后的共同检查项。
| 阶段 | 平台团队检查 | 业务团队检查 | 运维/SRE检查 |
|---|---|---|---|
| 变更前 | 标签、策略作用对象、命名空间范围 | 调用链、外部依赖、健康检查 | 观测面板、告警阈值、回滚窗口 |
| 灰度中 | 策略是否按批次生效 | 核心接口、任务和回调是否正常 | DNS、探针、错误率、采集链路 |
| 扩大范围前 | 是否有遗漏依赖和异常拒绝 | 是否完成业务验收 | 是否满足继续推进条件 |
| 回滚后 | 是否恢复到预期策略版本 | 是否确认业务恢复 | 是否记录触发条件和复盘结论 |
让清单进入发布系统，而不是留在文档里
如果团队已经使用GitOps或变更单系统，建议把依赖清单、灰度批次、回滚条件和验收结果放进同一个流程里。这样每次策略变更都能回答四个问题：影响谁、放行谁、如何验证、失败怎么退。
最终要形成的不是“更多NetworkPolicy文件”，而是一套可重复执行的Pod访问控制上线机制。当依赖、标签、观测和回滚都能被复用时，网络策略才能从单次安全加固，变成持续治理能力。
小结
K8s网络策略的生产价值，不是一次性把所有Pod都锁死，而是把Pod访问控制纳入可盘点、可灰度、可观测、可回滚的发布流程。真正应该优先处理的，是依赖清单、标签稳定性、默认拒绝爆炸半径、DNS和出站例外、灰度验收口径以及回滚触发条件。
对于准备推进NetworkPolicy的团队，建议先从低风险命名空间建立完整闭环，再复制到更关键的业务域。只要不能说明影响范围和回滚路径，就不要把默认拒绝直接推到核心生产命名空间。
常见问题
1. K8s网络策略灰度上线时，应该先做Ingress还是Egress？
没有固定答案，取决于当前风险和依赖清晰度。多数团队可以先从Ingress开始，因为服务入口关系更容易由业务方确认；如果出站风险更高，也可以先选择少量工作负载验证Egress。关键是不要同时大范围收紧两个方向，否则定位难度会明显上升。
2. 默认拒绝策略可以直接套到整个生产命名空间吗？
不建议在依赖不清时直接套用。即使目标是命名空间隔离，也应先完成调用链、DNS、探针、监控采集和外部出站盘点，再选择单个工作负载或非核心命名空间灰度。默认拒绝越接近核心业务，越需要明确回滚条件。
3. NetworkPolicy回滚是删除策略就可以吗？
不一定。多个NetworkPolicy可能同时作用在同一组Pod上，删除其中一条策略未必恢复所有访问，也可能放开不该开放的路径。更稳妥的做法是保留上一版策略清单，通过GitOps或发布系统回退到已验证版本，并在回滚后重新验证允许路径和拒绝路径。
4. 如何判断Pod访问控制失败是不是网络策略导致的？
先对齐时间线：访问失败是否从策略生效窗口开始，是否只影响被策略选中的Pod，DNS、探针和业务日志是否同时出现异常。再用测试Pod验证允许来源和非授权来源，结合`kubectl get networkpolicy`、Pod标签和应用日志判断。不要只凭一次连接失败就认定是NetworkPolicy问题。
5. 灰度完成后还需要保留哪些记录？
建议至少保留依赖清单、策略版本、灰度批次、验收结果、异常与回滚记录。后续扩展到新命名空间时，这些记录能帮助团队判断哪些例外是业务必需，哪些放行只是临时兜底，也能减少重复沟通成本。
