CNI差异如何影响多租户隔离?

同一集群按命名空间划分租户后，即使已经创建了 NetworkPolicy，也不能据此认定租户间网络已隔离。策略能否生效取决于底层 CNI 的实现及配置；命名空间只是组织资源的逻辑边界，不会自动阻断 Pod 之间的通信。

CNI 差异影响隔离，关键不在插件名称，而在策略是否被执行、执行范围是否覆盖预期流量，以及拒绝后必要通信能否恢复。Calico、Cilium、Flannel 等环境不能套用同一套默认行为判断。尤其不能把“配置了拒绝策略”等同于“默认已拒绝所有流量”：若策略未被执行，跨租户访问仍可能成功；若出口流量被拒绝却没有明确放行 DNS，应用则可能因无法解析名称而表现为故障。

验证时，应先记录 CNI 及其版本、配置，再在租户 A 创建针对入口和出口流量的拒绝策略。从 A 的 Pod 访问租户 B 的 Service，检查连接是否被阻断；随后明确放行所需的 DNS 流量，分别检查名称解析和服务连接。两者要分开看：解析失败不能证明跨租户访问已被正确隔离，能解析名称也不代表后续连接被允许。策略变更后重复测试，并结合 CNI 日志排查预期与实际不符的结果。

网络隔离也不能替代其他边界。RBAC 控制账户能否读取其他命名空间的资源，ResourceQuota 限制资源占用，CNI 执行的网络策略则约束通信路径。多租户环境应分别验证这些控制点，而不是凭某个插件的常见印象，推断整个集群的隔离状态。