Kube-OVN 与 OpenStack 混合部署中的端口清理问题分析

在混合云环境中同时使用 Kube-OVN 和 OpenStack 时，网络管理员可能会遇到一个棘手的问题：Kube-OVN 的垃圾收集机制（GC）会错误地清理 OpenStack Neutron 创建的有效端口。这个问题主要发生在 Kube-OVN 控制器启动或定期执行 GC 时，导致 OpenStack 网络功能异常。

问题现象

当 Kube-OVN 运行在与 OpenStack 共享 OVN 控制平面的环境中时，控制器会定期扫描并清理它认为"无效"的端口资源。日志中会显示类似以下信息：

准备清理端口组 neutron_pg_drop
准备清理端口组 pg_77e847e8_bee6_476c_ac9a_3a6e172dfdbe

这些端口实际上是 OpenStack Neutron 创建的有效资源，包含安全组规则等重要网络配置。它们的消失会导致 OpenStack 实例的网络连接出现问题。

根本原因分析

Kube-OVN 的 GC 机制设计初衷是清理集群中不再使用的网络资源。它会检查 OVN 数据库中的端口和端口组，如果发现这些资源没有对应的 Kubernetes 资源（如 Pod 或 Service），就会将其标记为"垃圾"并删除。

问题的关键在于：

1. 资源识别机制：Kube-OVN 主要依赖 Kubernetes API 中的资源来识别"有效"端口，而忽略了外部系统（如 OpenStack）管理的资源。

2. 外部 VPC 处理：虽然 Kube-OVN 支持外部 VPC（通过 ovn.kubernetes.io/vpc_external 标签标识），但 GC 逻辑没有充分考虑这些 VPC 中的资源保护。

3. 标签传播问题：OpenStack Neutron 创建的端口带有特定的 external_ids（如 neutron:security_group_id），但 Kube-OVN 的 GC 逻辑没有识别这些标记。

解决方案探讨

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

1. 增强 GC 逻辑：修改 Kube-OVN 的 GC 代码，使其能够识别并保留带有特定 external_ids（如 neutron.*）的端口资源。

2. 外部资源白名单：在 Kube-OVN 配置中增加一个正则表达式模式，用于匹配需要保留的外部资源标识。

3. GC 功能开关：为特定 VPC 或命名空间提供禁用 GC 的选项，保护关键网络资源不被误删。

4. 资源所有权标记：在创建外部资源时，显式标记这些资源的所有权，帮助 GC 机制正确识别。

实施建议

对于正在经历此问题的用户，建议采取以下临时措施：

1. 定期备份 OVN 数据库，以便在资源被误删后能够快速恢复。

2. 调整 Kube-OVN 的 GC 间隔时间，减少问题发生的频率。

3. 考虑为 OpenStack 和 Kubernetes 使用独立的 OVN 部署，彻底避免资源冲突。

长期来看，最佳解决方案是修改 Kube-OVN 代码，使其能够正确处理混合环境中的网络资源。这需要：

1. 增强外部 VPC 的支持，确保其 enableExternal 状态能够正确传播到 GC 逻辑。

2. 为 GC 机制添加资源过滤功能，基于 external_ids 或特定标签保留关键资源。

3. 提供更细粒度的 GC 控制选项，允许管理员按需配置资源保留策略。

总结

Kube-OVN 与 OpenStack 的混合部署为云平台提供了灵活的网络解决方案，但也带来了资源管理上的挑战。理解 GC 机制的工作原理和限制，采取适当的防护措施，是确保网络稳定运行的关键。随着 Kube-OVN 的持续发展，我们期待看到更完善的混合环境支持功能，使管理员能够更自信地部署和管理复杂的云网络架构。