策略要生效得靠插件
网络策略只是声明对象，是否真正阻断流量由网络插件决定。实现了策略执行的插件会把这些对象翻译成节点上的转发规则或内核程序；不支持的插件只会把对象存起来，流量照常通行。因此写策略之前，先确认集群里的插件具备这个能力。
基本信息
| 所属接口组 | networking.k8s.io/v1 |
|---|---|
| 执行方 | 网络插件与节点上的转发规则 |
| 支持情况 | 主流插件已支持，部分老式覆盖网络默认不执行 |
| 生效前提 | 策略选择的目标 Pod 与该插件纳管的网络一致 |
| 验证方式 | 建默认拒绝对照，验证连接被阻断 |
典型使用场景
- 梳理东西向流量，收敛服务之间的可访问范围
- 合规要求下隔离数据库与业务命名空间
- 排查策略不生效：怀疑插件没有执行策略
- 更换插件后做能力复核，确认策略能力没有退化
- 多网卡环境确认策略作用于哪张网络
确认集群网络组件
确认集群网络组件
kubectl -n kube-system get pods -o wide | grep -i -E 'calico|cilium|antrea|flannel|kube-router' # 插件类型
kubectl get networkpolicy -A | head # 已存在的策略
kubectl -n kube-system get pods -o wide # 插件副本是否就绪
kubectl get nodes -o wide # 节点网络情况连通性验证（策略生效性测试）
连通性验证（策略生效性测试）
kubectl run np-test --rm -it --image=busybox:1.36 --restart=Never -n prod -- sh
# 容器内执行：
nc -zv -w 2 db 5432 && echo allowed || echo blocked # 期望被阻断
nslookup db # 解析是否正常
wget -qO- --timeout=2 http://db:5432 # 另一种验证方式能力与现象对照
| 情况 | 现象 | 处理 |
|---|---|---|
| 插件支持策略 | 默认拒绝后连接被阻断 | 按需逐条放开来源 |
| 插件不执行策略 | 拒绝策略下连接仍然畅通 | 更换或补齐插件能力 |
| 插件副本异常 | 策略时灵时不灵 | 先恢复插件自身状态 |
| 多网络并存 | 只拦住其中一张网络的流量 | 明确策略作用的网络范围 |
验证策略是否真正生效的标准做法是：先建一条默认拒绝，再从同命名空间的 Pod 发起连接。如果仍然畅通，说明插件没有执行策略，此时继续细化规则没有意义。
更换网络插件属于集群级变更，期间可能出现网络短暂中断。必须先完成方案设计与回滚演练，并在变更窗口内执行。