Kube-OVN 在 Underlay 模式下 NetworkPolicy 失效问题分析

Kube-OVN 作为 Kubernetes 网络插件，在 Underlay 模式下运行时可能会遇到 NetworkPolicy 不生效的问题。这个问题主要影响网络策略对 Pod 间通信的控制能力，导致安全策略无法按预期执行。

问题现象

在 Kube-OVN 的 Underlay 模式下，当用户配置 NetworkPolicy 限制特定端口的访问时，发现以下异常现象：

1. 无论 NetworkPolicy 中是否添加 Service 端口（如 80 端口），都无法通过 Service 访问目标 Pod
2. 只有当 NetworkPolicy 中添加 Pod 实际监听的端口（如 8000 端口）时，才能直接访问 Pod
3. 使用 kubectl ko trace 工具检查时，流量未被丢弃但显示为 recirc 状态

技术背景

Kubernetes NetworkPolicy 是控制 Pod 间网络通信的重要安全机制。在传统 Overlay 网络中，NetworkPolicy 通常能正常工作。但在 Underlay 模式下，由于网络数据包直接通过物理网络传输，不经过 Overlay 封装，导致 NetworkPolicy 的实现机制有所不同。

根本原因分析

经过深入分析，发现问题主要源于以下几个方面：

1. ACL 规则应用时机不当：Kube-OVN 在处理 NetworkPolicy 时，ACL 规则被配置为在负载均衡之后才生效（apply-after-lb="true"），这导致对 Service 端口的过滤失效。

2. 端口匹配机制差异：在 Underlay 模式下，NetworkPolicy 实际匹配的是 Pod 的真实监听端口，而非 Service 的虚拟端口。这与部分用户对 Kubernetes NetworkPolicy 行为的预期不符。

3. 流量重定向问题：当流量通过 Service 访问时，由于 Underlay 模式的特殊处理，可能导致 NetworkPolicy 规则无法正确识别和过滤流量。

解决方案

针对这个问题，可以考虑以下解决方案：

1. 调整 ACL 规则应用时机：修改 Kube-OVN 的 ACL 规则配置，确保在适当的时间点应用网络策略，特别是对于有 Pod 选择器的情况。

2. 明确端口匹配策略：在使用 NetworkPolicy 时，开发者需要明确区分 Service 端口和 Pod 端口的差异，在策略中配置正确的目标端口。

3. 验证工具使用：充分利用 kubectl ko trace 等诊断工具，验证 NetworkPolicy 的实际生效情况，确保策略按预期工作。

最佳实践建议

1. 在 Underlay 模式下配置 NetworkPolicy 时，始终以 Pod 实际监听端口作为目标端口
2. 对于需要通过 Service 访问的场景，考虑同时配置 Service 端口和 Pod 端口的策略
3. 定期使用诊断工具验证网络策略的实际生效情况
4. 保持 Kube-OVN 组件版本更新，以获取最新的网络策略支持

总结

Kube-OVN 在 Underlay 模式下的 NetworkPolicy 实现有其特殊性，开发者需要理解底层网络机制与 Kubernetes 抽象概念之间的差异。通过正确配置和验证，可以确保网络策略在各种场景下都能按预期工作，保障集群网络安全。