命名空间划分决定了网络策略的“可见范围”和“默认边界”；划得太粗会让策略误伤，划得太细会让策略漏配，只有把命名空间标签和策略选择器对齐，才能让流量控制真正落地。
命名空间划分对网络策略的底层影响是什么
命名空间不是单纯的资源收纳箱,在 Kubernetes 里，网络策略通过 podSelector 和 namespaceSelector 两个选择器来匹配流量来源或目标，命名空间划分的方式，直接决定了 namespaceSelector 能匹配到什么对象。
你给命名空间打的标签,就是网络策略用来识别“你是谁”的身份证，策略里写 namespaceSelector: matchLabels: team: backend，它只会去找带 team=backend 标签的命名空间里的 Pod，如果新建命名空间没打这个标签，策略就当作它不存在，流量要么被默认拒绝，要么被默认放行，取决于你有没有全局兜底策略。
划分的粒度也会影响策略的维护成本,一个命名空间包揽所有服务，策略里只能靠 podSelector 细分；一旦某个 Pod 忘记打标签，策略就失效，反过来，每个微服务一个命名空间，策略数量可能翻好几倍，排查问题时要先翻十几份 YAML 才能定位。
业内专家指出,网络策略的排查成本往往高于配置成本，这句话放在命名空间划分上尤其贴切：划分阶段省下的几分钟，会在策略异常时用几小时还回来。
命名空间划分不合理会导致什么？先看三种典型故障
命名空间标签缺失导致策略“看不见”新环境
很多团队扩建环境时只执行 kubectl create namespace staging-new，没有同步打上 env: staging 或 team: payments 标签，已有的网络策略里写着按 team=payments 放行数据库流量，结果新命名空间的 Pod 访问数据库被拒绝，或者更糟，默认允许规则比默认拒绝规则优先，新环境直接裸奔。
排查命令：kubectl get namespace staging-new --show-labels，如果输出里没有策略需要的标签，流量策略自然不会生效，这不是网络策略写错，是命名空间划分时漏了标签约定。
命名空间粒度太粗导致策略“一刀切”
一个大的业务命名空间里塞了前端、订单、支付、报表四个模块，网络策略要放行前端到订单的流量，只能用 podSelector 指定 frontend 和 order 两个标签，但订单服务横向扩容后，新 Pod 如果没第一时间打上 order 标签，流量就被切断，或者有人为了图省事，直接放行整个命名空间内所有 Pod 互访，支付服务的数据库端口也暴露给前端了。
这种情况下,策略的精准度被命名空间粒度拖累，把支付等敏感模块拆到独立命名空间，再用命名空间级别的策略做隔离，远比在同一个命名空间里抠 podSelector 可靠。
命名空间粒度太细导致策略数量爆炸
见过一个团队,每个部署单元一个命名空间，整个集群有七十多个命名空间，网络策略跟着命名空间走，每新建一个命名空间就要复制两份 YAML：入站规则一份，出站规则一份，到后来没人记得哪个命名空间配了默认拒绝，哪个还是默认允许。
策略数量超过一定规模后,kube-proxy 或 CNI 插件的规则计算会变慢，这不是玄学，是因为每条 NetworkPolicy 最终要转化成数据平面的流表或 iptables 规则，命名空间切得越碎，策略条数越多，控制平面和数据平面的同步压力越大。
Kubernetes网络策略默认拒绝规则怎么配置才不踩坑
默认拒绝规则是命名空间划分后必须优先配的一条策略,它不针对具体服务，只做一件事：把该命名空间里所有没有被明确放行的流量挡掉。
入站默认拒绝配置：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
出站默认拒绝配置：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-egress
namespace: production
spec:
podSelector: {}
policyTypes:
- Egress
配置顺序要当心,如果先部署业务 Pod，再建默认拒绝策略，中间可能已经产生几分钟甚至几小时的未受控流量，正确做法是：新建命名空间后，立即应用默认拒绝策略，再部署任何工作负载。
默认拒绝规则本身不算高深,但它有个容易忽略的坑：它只管策略创建之后的流量，不会追溯历史连接，对于已经建立的 TCP 长连接，部分 CNI 插件不会主动切断，所以验证时要新建连接测试，别拿老连接下结论。
多租户场景下命名空间网络隔离怎么做
多租户集群里,命名空间划分对网络策略的影响最明显，租户之间要互相看不见，但不能影响各自的正常服务，单纯靠命名空间名称区分租户不够，因为 NetworkPolicy 的 namespaceSelector 匹配的是标签，不是名称。
实操步骤：
- 给每个租户的所有命名空间打上统一标签：
kubectl label namespace tenant-a purpose=tenant-a
- 在租户 A 的命名空间里，只放行来自同租户的入站流量：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-same-tenant
namespace: tenant-a
spec:
podSelector: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
purpose: tenant-a
policyTypes:
- Ingress
- 出站方向同理,用 egress 限制只能访问同租户命名空间的 Pod。
- 结合 ResourceQuota 限制每个命名空间能创建的 NetworkPolicy 数量，防止某个租户把规则表写满。
多租户场景下不建议用“默认允许，按需拒绝”的思路，因为命名空间一多，漏配一条拒绝规则的概率会上升，行业共识认为，多租户隔离应当优先采用“默认拒绝，按需放行”模型，这比逐条补拒绝规则可靠得多。
命名空间和网络策略哪个先配置？对比两种顺序的坑
很多新手会问到底先划命名空间,还是先写网络策略，答案很直接：先划命名空间，并且先打标签，再写策略。
先划命名空间后配策略
优点：策略里的 namespaceSelector 能立刻匹配到目标，不会出现策略建好却找不到对象的情况，缺点：在策略生效前，命名空间内流量处于默认允许状态，尤其在生产集群里，这个窗口期有风险。
先配策略后划命名空间
如果策略里引用了不存在的命名空间标签,策略不会报错，但也不会生效，等命名空间建好后，策略才会匹配到，这种顺序适合提前规划，但如果命名空间迟迟未建，等于策略空转。
对比表：
| 顺序 | 风险点 | 适用场景 |
|---|---|---|
| 先划命名空间后配策略 | 短暂默认允许窗口 | 已有应用需要快速上线 |
| 先配策略后划命名空间 | 策略空转无提示 | 新集群初始化、提前规划 |
不论哪种顺序,最终都要执行一条命令验证：kubectl get networkpolicy -n <namespace> -o yaml，检查策略的 namespaceSelector 是否和命名空间标签一致，还有 kubectl describe networkpolicy <name> -n <namespace> 查看规则实际生成的匹配条件。
简米云ACK命名空间网络策略配置有哪些不同
在云环境里,命名空间划分对网络策略的影响还多了一层插件差异，以简米云 ACK 为例，网络策略默认依赖 Terway 或 Flannel 插件，Terway 模式下网络策略直接下发给网卡，性能比 iptables 模式好一些；Flannel 模式则需要额外开启网络策略支持。
控制台操作路径：登录容器服务控制台，进入目标集群，选择“网络”下的“网络策略”，可以按命名空间筛选和创建策略，控制台会自动带出当前命名空间的 Pod 标签，减少手写 YAML 出错。
地域方面,不同地域的 ACK 集群在插件版本和功能开放时间上可能有差异，新地域上线稍晚，部分网络策略高级功能可能不可用，新建集群时，建议先在对应地域的集群详情里确认网络插件是否支持 NetworkPolicy，国内生产环境多数选择 Terway 插件，因为它的网络策略执行延迟更低，适合多租户和金融级隔离场景。
命名空间划分不是孤立的管理动作,它决定了网络策略的匹配精度、默认边界和运维成本，划分之前先想清楚标签体系，划分之后立刻补上默认拒绝规则，再用 namespaceSelector 做定向放行，能避免大部分“策略失效”的线上事故，网络策略写得再严谨，也架不住命名空间标签乱成一团；先把命名空间这层地理关系理清，门禁才能真正起作用。
Q&A
怎么排查命名空间划分对网络策略的影响？
先看命名空间标签：kubectl get namespace <name> --show-labels，再比对策略里的 namespaceSelector，如果标签对不上，策略不会生效，然后用 kubectl describe networkpolicy <name> -n <namespace> 查看实际匹配的 Pod 和命名空间，最后用一个带标签的临时 Pod 测试流量：kubectl run test --rm -it --image=busybox --labels=app=test -- wget -qO- http://target-service。
多个命名空间能共用一个网络策略吗？
不能,NetworkPolicy 是命名空间级资源，每个策略只能作用于它所在的命名空间，但一个策略可以通过 namespaceSelector 匹配多个命名空间的 Pod 作为流量来源或目标，如果要让多个命名空间套用同一套规则，只能把 YAML 复制到每个命名空间，或者用 GitOps 工具批量同步。
网络策略默认拒绝规则配置后 Pod 连不上怎么办？
先把默认拒绝策略暂时移除,确认 Pod 本身网络正常，然后逐步添加出站和入站放行规则，每加一条就用 kubectl exec 测试一次连通性，常见原因是出站方向只配了目标端口，没配 DNS 解析所需的 UDP 53 端口，补上 DNS 放行规则后，多数连接问题即可解决，默认拒绝规则要求所有依赖流量都必须显式放行，包括对 kube-dns 的访问。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/641781.html
