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

问题背景

在Kubernetes网络插件Kube-OVN的Underlay部署模式下，用户报告了一个关于NetworkPolicy功能异常的问题。具体表现为：当配置了NetworkPolicy规则后，策略未能按预期限制Pod间的网络访问，特别是针对Service端口和Pod端口的控制出现不一致行为。

问题复现与现象

用户创建了两个Pod（A和B）以及一个Service A（ClusterIP类型，端口80）。Pod B标记为client，Pod A标记为frontend。配置的NetworkPolicy规则仅允许Pod B（client）向Pod A（frontend）的443和8443端口发起出站连接。

实际测试发现：

1. 无论NetworkPolicy中是否添加80端口，通过Service访问（端口80）均失败
2. 当NetworkPolicy中添加8000端口（Pod实际监听端口）时，直接访问Pod端口（8000）成功
3. 未添加8000端口时，直接访问Pod端口（8000）失败

技术分析

NetworkPolicy实现机制

Kube-OVN通过OVN的ACL（访问控制列表）功能实现NetworkPolicy。在Underlay模式下，ACL规则被转换为OVN流表项，控制数据包的转发行为。

从提供的ACL规则可见，Kube-OVN生成的规则包含以下关键属性：

• 方向：from-lport（从逻辑端口发出）
• 匹配条件：包含源端口、目标IP和端口
• 特殊选项：apply-after-lb="true"（在负载均衡后应用）

问题根源

经过分析，该问题可能涉及多个方面：

1. Service与Pod端口处理差异：Kube-OVN在处理NetworkPolicy时，对Service端口和Pod实际端口采用了不同的处理逻辑。Service访问经过kube-proxy的NAT转换后，ACL规则可能无法正确匹配转换后的流量。

2. ACL应用时机：apply-after-lb="true"选项可能导致ACL在负载均衡后应用，使得针对Service端口的规则失效。

3. 规范理解差异：Kubernetes NetworkPolicy规范中，对于egress规则是否应该针对Service端口还是Pod实际端口存在理解上的分歧。不同CNI插件可能有不同的实现方式。

解决方案建议

1. 明确端口处理规范：Kube-OVN应明确声明其对NetworkPolicy中端口处理的方式，特别是针对Service端口和Pod端口的区别。

2. ACL规则优化：考虑调整ACL规则的生成逻辑，确保无论是通过Service访问还是直接Pod访问，都能被NetworkPolicy正确控制。

3. 调试工具使用：建议用户使用kubectl ko trace命令跟踪网络流量，确认具体哪些规则被命中或忽略。

最佳实践

对于使用Kube-OVN Underlay模式的用户，建议：

1. 在编写NetworkPolicy时，同时考虑Service端口和Pod实际端口的需求。

2. 进行全面的网络策略测试，包括Service访问和直接Pod访问两种场景。

3. 定期检查OVN ACL规则，确认生成的规则符合预期。

4. 保持Kube-OVN版本更新，及时获取最新的网络策略功能改进。

总结

Kube-OVN在Underlay模式下NetworkPolicy的实现存在Service端口处理方面的特殊行为，这要求用户在配置网络策略时需要特别注意端口设置。理解底层实现机制有助于更有效地设计和管理Kubernetes集群的网络策略。随着项目的持续发展，这一问题有望在后续版本中得到进一步优化和解决。