Kube-OVN安全组规则优先级问题分析与解决方案

问题背景

在使用Kube-OVN v1.13.0版本时，用户发现当Pod绑定安全组后，无法ping通网关地址。经过详细排查，发现这是一个由于版本升级导致的ACL规则优先级问题。

问题现象

当用户创建安全组并绑定到Pod后，虽然安全组规则中已经允许所有IPv4流量（优先级2100），但实际流量却匹配了默认的deny规则（优先级2003），导致ICMP流量被拦截。通过ovn-trace工具可以确认流量确实被默认的deny规则拦截。

根本原因分析

这个问题源于Kube-OVN从v1.12.x升级到v1.13.0版本时的行为变更：

1. 在v1.12.x版本中，安全组的ACL规则使用tier 0
2. 升级到v1.13.0后，新建的安全组规则变为tier 2
3. 但默认的deny all ACL规则仍保持为tier 0

由于tier 0的优先级高于tier 2，导致原本设计为最低优先级的deny all规则变成了最高优先级，从而拦截了所有流量。

解决方案

临时解决方案

对于已经出现问题的环境，可以执行以下步骤：

1. 删除现有的deny all规则
2. 重启ovn controller使其重建规则

具体命令如下：

kubectl-ko nbctl acl-del ovn.sg.kubeovn_deny_all from-lport 2003 "inport == @ovn.sg.kubeovn_deny_all && ip"
kubectl-ko nbctl acl-del ovn.sg.kubeovn_deny_all to-lport 2003 "outport == @ovn.sg.kubeovn_deny_all && ip"
kubectl rollout restart deployment/kube-ovn-controller -n kube-system

长期解决方案

开发团队已经提交了修复代码，确保deny all规则使用正确的tier级别，与安全组规则保持一致。建议用户升级到包含此修复的版本。

技术建议

1. 在升级Kube-OVN版本时，应仔细阅读版本变更说明，特别是涉及网络策略和安全组规则的变更
2. 对于生产环境，建议先在测试环境验证版本升级的兼容性
3. 遇到类似网络策略问题时，可以使用ovn-trace工具进行流量路径分析

总结

这个问题展示了网络策略实现中规则优先级的重要性。在云原生网络环境中，安全组和网络策略的正确配置对业务连通性至关重要。Kube-OVN团队已经快速响应并修复了这个问题，体现了开源社区的高效协作。