K8s默认Network Policy规则与Pod实际互通表现不符疑问

你对官方默认规则的认知偏差，核心是把Network Policy（以下简称NP）的单一层面规则，等同于整个集群的全链路网络连通逻辑，具体遗漏如下：

• 默认非隔离规则的作用边界非常有限
  官方定义的「无匹配NP时Pod入站、出站默认非隔离、NP控制器不拦截对应流量」，仅描述NP控制器本身的行为，不代表集群网络默认全通。NP只是K8s多层网络访问控制体系中的一个维度，既不覆盖其他层的拦截逻辑，也不保障底层网络本身的连通性。
• 默认非隔离状态的触发前提经常不成立
  该状态仅在「没有任何NP资源匹配目标Pod」时生效，但绝大多数生产环境集群（包括各大云厂商托管K8s、OpenShift等发行版、带安全基线的部署工具链）会在新命名空间创建时自动注入兜底NP，最常见的是默认拒绝所有入站/出站流量的安全策略。这类场景下你虽然没有手动创建NP，但匹配Pod的NP已经存在，默认非隔离状态从一开始就不会触发。
• NP之外的拦截规则经常被忽略
  即使确认没有任何匹配Pod的NP，以下问题同样会导致Pod间通信失败，和NP默认规则没有关系：
  • CNI层面的限制：部分CNI默认未开启跨节点Pod通信；Calico、Cilium等支持高级策略的CNI可配置集群级全局策略（如Calico GlobalNetworkPolicy、CiliumClusterWideNetworkPolicy），这类策略作用于全集群所有命名空间，不受单命名空间下NP配置的影响
  • 基础设施层拦截：节点操作系统防火墙（iptables/nftables/firewalld）、云服务器安全组、VPC网络ACL未放通Pod网段流量
  • 基础网络组件故障：CNI路由表异常、Pod网段IP冲突、kube-proxy的Service转发规则失效（如果测试时使用Service地址而非Pod直连IP，这类故障占比极高）
  • 工作负载自身问题：应用未正确监听对应端口、容器内部配置了自定义防火墙规则、Pod的DNS配置错误导致服务发现失败

针对「新建命名空间部署两个Pod、未手动配置NP但无法通信」的场景，按以下顺序排查即可快速定位根因：

1. 检查目标命名空间下是否存在自动注入的NP资源：

   kubectl get networkpolicy -n <目标命名空间名>
   

   如果返回结果非空，说明已有NP匹配目标Pod，默认非隔离规则不生效，直接查看对应NP的规则配置即可定位拦截点。
2. 校验CNI能力与全局策略：
   • 若使用Flannel等原生不支持NP的CNI，NP规则本身不会生效，连通性问题与NP逻辑无关
   • 若使用Calico、Cilium等支持高级策略的CNI，排查是否存在集群范围的全局网络策略拦截流量
3. 逐层排除非NP层故障：
   • 优先通过Pod IP直连测试同节点上两个Pod的连通性，跳过Service解析、DNS、跨节点路由等干扰变量，先验证基础网络连通性
   • 检查节点侧防火墙、云安全组、网络ACL规则是否放通Pod网段的通信流量
   • 进入容器内部确认应用端口正常监听、无容器内自定义拦截规则

认知纠正：不存在「未配置NP则网络一定全通」的结论。K8s网络连通性是CNI插件、节点网络、云基础设施、多层访问控制规则共同作用的结果，NP只是其中可通过K8s原生资源配置的一个访问控制层。

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