命名空间划分直接决定了网络策略的生效范围与管控粒度，合理划分是Kubernetes集群安全防护的第一道关卡。
在容器化环境里，命名空间（Namespace）不只是资源隔离的工具，更是网络策略（NetworkPolicy）得以落地的前置条件，如果命名空间划分粗糙，网络策略要么管得太宽，要么根本配不出来，本文从实际部署视角，拆解命名空间划分如何影响网络策略的配置、排障与运维成本。
命名空间与网络策略的绑定关系：为什么划分方式会改变规则写法
命名空间是网络策略的默认边界
行业共识认为,Kubernetes网络策略默认作用于指定命名空间内的Pod，写一条NetworkPolicy时，spec.podSelector只能选中当前命名空间里的Pod，而namespaceSelector则用于跨命名空间匹配来源或目标，这意味着命名空间的边界本身就构成了策略的逻辑边界。
如果所有应用都堆在default命名空间里,那么podSelector会同时命中无关应用，策略配起来要么误伤，要么得靠大量ipBlock硬编码，反之，如果每个应用独占命名空间，则策略的podSelector天然聚焦，规则可读性和可维护性显著提升。
划分粒度决定策略的精确程度
常见的划分方式有三种：按环境（dev/prod）、按业务线（支付/会员）、按团队（A组/B组），每种方式对网络策略的影响完全不同。
- 按环境划分：命名空间之间往往需要隔离，策略多表现为“拒绝所有跨环境访问”，规则简单但容易过于粗放。
- 按业务线划分：需要精细控制业务间的互访，策略会大量使用
namespaceSelector组合podSelector，规则数量增加，但权限边界清晰。 - 按团队划分：团队间协作频繁，策略容易出现“开洞”现象，需要额外设计白名单机制。
从实际操作看,推荐按业务线为主、环境为辅的组合划分，例如prod-payment、dev-payment，既保证环境隔离，又保留业务内联动的简便性。
命名空间划分不当会引发哪些网络策略故障
跨命名空间访问被默认拒绝后难以排障
当你在命名空间A里部署前端,命名空间B里部署后端，若没有在B的NetworkPolicy中显式允许来自A的流量，默认情况下所有非本命名空间的访问都会被拒绝（取决于CNI实现），此时前端报超时，排查时先看策略，再看命名空间标签是否匹配。
经常踩坑的是namespaceSelector的标签匹配问题，很多团队给命名空间打标签时随意命名，比如env: prod和environment: prod混用，导致策略选不到目标命名空间，建议在集群初始化时统一命名空间标签规范，并写入操作手册。
共享命名空间导致策略过度放宽
把所有中间件放进同一个middleware命名空间，然后写一条“允许所有Pod访问该命名空间的3306端口”，看似简单，但任何被误调度进该命名空间的Pod都会获得数据库访问权限，而如果按业务再拆成middleware-mysql、middleware-redis，则每条策略只针对单一端口，攻击面大幅缩小。
业内专家指出,这种“先便利后补洞”的做法在中小团队中非常普遍，但后期每次安全审计都需要重新梳理策略归属，成本远高于初期多写几条规则。
命名空间层级过深导致策略膨胀
有团队尝试用命名空间模拟微服务目录层级,例如company/product/partner/order，但Kubernetes命名空间没有父子关系，这种路径式划分只会让namespaceSelector的标签组合爆炸，每条策略要匹配多层级的标签，不仅写起来繁琐，CNI在计算策略时也需要更多资源，实际上命名空间是扁平结构，不要试图在其中构建层级，层级应该由应用自身的标签表达。
如何基于命名空间划分设计可扩展的网络策略体系
第一步：制定命名空间命名与标签规范
在集群创建前,用ConfigMap或Git仓库维护命名空间清单，每个命名空间至少包含三个标签：env（环境）、team（负责团队）、app（业务域）。
- 命名空间：
prod-payment - 标签：
env=prod,team=payment,app=core
这样后续写NetworkPolicy时,namespaceSelector的matchLabels可以精准锁定任意维度，如果只按名称匹配（某些CNI支持），命名空间重命名成本极高，而标签则灵活得多。
第二步：按“默认拒绝”原则编写基础策略
为每个命名空间创建一条入站默认拒绝策略,只留podSelector: {}和policyTypes: ["Ingress"]，但不添加任何规则，这条策略不阻碍出站，也不影响同命名空间内互访，之后每开一个访问入口，就新增一条规则，让“允许”是有据可查的。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: prod-payment
spec:
podSelector: {}
policyTypes:
- Ingress
这条策略必须在新命名空间创建后立即生效,否则后续补上时，已经建立的连接不会被主动断开（多数CNI不会重评估存量连接），容易造成“策略已下单但流量没断”的假象。
第三步：用命名空间标签驱动跨业务策略
当订单服务需要访问用户服务的8080端口时,不再针对具体Pod IP，而是写：
spec:
podSelector:
matchLabels:
app: user-service
ingress:
- from:
- namespaceSelector:
matchLabels:
app: order
ports:
- port: 8080
这里的namespaceSelector会选中所有带app=order标签的命名空间下的Pod，如果将来新增一个订单子服务，只要其命名空间打上该标签，无需修改策略即可自动纳入允许范围，这正是命名空间划分所带来的策略复用价值。
第四步：定期审计策略与命名空间的一致性
建议每季度导出所有NetworkPolicy,对照命名空间标签清单检查是否存在孤儿规则（引用了不存在的命名空间标签）、冗余规则（同命名空间内重复允许）或缺失规则（业务已上线但策略未添加），也可以使用开源工具如kube-network-policies（社区项目）进行规则可视化，但核心仍是依赖清晰的命名空间命名规范。
不同CNI插件下命名空间划分对策略行为的差异
| CNI插件 | 默认处理跨命名空间流量 | 对命名空间标签的支持 | 注意事项 |
|---|---|---|---|
| Calico | 默认允许，除非有策略 | 支持namespaceSelector |
需要开启PolicyType为Passed的自定义资源 |
| Cilium | 默认允许，支持DNS策略 | 支持，且可结合CIDRGroup |
命名空间标签变化后，策略重载延迟约数秒 |
| Flannel | 不支持NetworkPolicy | 不适用 | 通常需要额外部署Calico或Cilium作为策略引擎 |
从运维角度看,命名空间划分对策略的影响在Calico和Cilium下表现一致，但Cilium对namespaceSelector的变更响应更敏感，删除命名空间后，旧规则不会立即消失，需手动清理，因此大规模集群建议在Namespace变更流程中加入策略同步步骤。
命名空间数量与策略性能的权衡
命名空间划分过细,比如几百个命名空间各自带十几条策略，策略总数可能上千，多数CNI会将策略转换为BPF或IPTable规则，数量越多，规则下发时间越长，据公开测试数据，当策略数量超过5000条时，部分CNI的规则更新延迟会从毫秒级上升到秒级，因此不必为每个微服务单独创建命名空间，应将相同安全域的应用合并，用应用标签区分具体服务。
实际操作中,一个集群内的命名空间数量建议控制在50个以内，超过这个量级先考虑业务分集群，再考虑用命名空间隔离，否则网络策略的排障会变成一场灾难：面对几百个命名空间，你根本不知道哪条规则在起作用。
Q&A：命名空间划分与网络策略常见疑问
命名空间划分对网络策略的影响有多大？
影响是决定性的,没有合理的命名空间划分，网络策略要么无法精确表达“谁可以访问谁”，要么需要大量IP白名单来弥补边界模糊，合理划分后，一条策略可以复用给整个命名空间组，规则量减少一半以上。
如何让网络策略跨命名空间生效？
必须通过namespaceSelector匹配目标命名空间的标签，或者在NetworkPolicy的from中引用多个namespaceSelector，注意标签是精确匹配，不支持正则或模糊匹配，所以务必统一标签键值规范，若使用Calico，还可以通过NetworkPolicy的namespaceSelector字段实现更灵活的选配，但原生Kubernetes API已经足够覆盖大多数场景。
命名空间删除后，相关的网络策略会自动清理吗？
命名空间被删除时,绑定在该命名空间下的NetworkPolicy会随命名空间一并删除，但引用该命名空间标签的其他策略不会自动移除，这会导致规则中残留不存在的标签选择器，虽然不影响现有流量，但会给审计留下误导信息，建议在命名空间删除流程中增加对全局NetworkPolicy的扫描步骤，用kubectl get netpol -A -o yaml | grep namespaceSelector找到所有引用点并手工清理。