Kubernetes deny-all NetworkPolicy未生效问题（Weave与Calico对比）

兄弟，你碰到的这个情况真的是Weave Net的网络策略实现特性导致的，和Calico的处理逻辑差得挺多的。

核心原因：Weave对已存在连接的“懒处理” #

Weave Net的网络策略是靠连接追踪来生效的，但它有个很关键的特性：如果策略是在Pod启动后才添加的，已经存在的Pod网络规则不会被回溯更新拦截。

你说你是先部署了应用，后加的deny-all ingress策略，这时候就踩了Weave的这个坑：

• my-staging里的UI服务Pod已经跑起来了，Weave早就给它生成了初始的网络规则，允许所有 ingress 流量；
• 当你后来加了拒绝策略，Weave的weave-npc控制器只会给新创建的Pod应用这个规则，不会主动去更新已经在运行的Pod的iptables规则；
• 而Calico就不一样了，它的calico-node组件在策略变更时，会重新计算所有Pod的网络规则，不管Pod是新的还是已经在跑的，直接强制刷新iptables，所以新策略马上就能生效。

再说说Weave的策略生效逻辑 #

Weave的weave-npc是监听NetworkPolicy的变化，但它的更新逻辑是增量式的：

• 只有当Pod发生重启、或者有新的网络策略关联到Pod标签时，它才会去更新对应Pod的规则；
• 你加的这个策略是podSelector: {}（匹配所有Pod），但因为Pod已经运行了，weave-npc不会主动触发规则更新，所以旧的允许规则还在，default命名空间的busybox自然能访问到。

验证和临时修复的办法 #

如果你想确认是不是这个问题，可以试试这两个操作：

• 重启my-staging命名空间里的UI服务Pod，让Weave重新给它生成网络规则，这时候再用busybox访问，应该就被拦住了；
• 或者重启集群里的weave-npc Pod，让它重新加载所有网络策略，也能触发规则更新。

不过要是你需要严格的网络策略强制执行，Calico的实现确实更贴合Kubernetes官方对网络策略的预期，这也是你切换之后一切正常的原因。

内容的提问来源于stack exchange，提问作者pkaramol