Kube-OVN中LoadBalancer类型服务多端口配置的缺陷分析与解决方案

问题背景

在Kubernetes网络方案Kube-OVN的实际使用中，用户发现当通过LoadBalancer类型服务暴露非HTTP协议服务时（如SSH），存在连接无法建立的问题。具体表现为TCP SYN包能到达节点网络接口，但服务端无SYN/ACK响应，且流量未能正确转发至后端Pod。

技术现象分析

通过tcpdump抓包分析可见：

1. 客户端发送的SYN包能到达节点网络接口（10.224.1.112:30001）
2. 流量未到达目标Pod的网络接口
3. OVN逻辑路由器的NAT表(lr-nat-list)未显示预期的端口映射规则

进一步测试发现：

• 初始创建时包含所有端口的LoadBalancer服务（80/443/30001）工作正常
• 先创建基础服务（80/443）后添加额外端口（30001）时，新增端口无法正常工作

根本原因

这是Kube-OVN v1.12.18版本中LoadBalancer服务控制器的一个已知缺陷。当动态添加新端口到现有LoadBalancer服务时：

1. 服务控制器未能正确更新OVN逻辑路由器的NAT规则
2. 新增端口的DNAT规则未被正确配置到数据平面
3. 导致新增端口的流量无法被正确转发

解决方案

临时解决方案

1. 删除现有LoadBalancer服务
2. 重新创建包含所有需要端口（包括新增端口）的完整服务定义

长期解决方案

该问题已被标记为需要向后移植(need backport)的缺陷，建议：

1. 关注Kube-OVN后续版本更新
2. 升级到包含修复的稳定版本

最佳实践建议

1. 对于需要暴露多协议服务的场景：

   • 建议在初始创建时包含所有需要暴露的端口
   • 避免后期动态添加关键业务端口

2. 故障排查方法：

   • 使用kubectl ko nbctl lr-nat-list检查NAT规则
   • 在节点和Pod两端进行tcpdump抓包对比
   • 检查kube-ovn-controller日志中是否有相关错误

3. 对于生产环境：

   • 建议在变更前进行充分测试
   • 考虑使用蓝绿部署方式更新服务配置

技术影响范围

该缺陷影响以下场景：

• 使用Kube-OVN提供的LoadBalancer服务
• 需要动态添加新端口到现有服务
• 非HTTP协议服务的暴露（TCP/UDP）

不影响：

• 初始创建时包含完整端口配置的服务
• 仅使用HTTP/HTTPS协议的服务
• ClusterIP或NodePort类型的服务

总结

Kube-OVN作为高性能的Kubernetes网络方案，在大多数场景下表现优异。本次发现的LoadBalancer服务多端口配置问题主要影响服务动态变更场景。通过了解这一限制，用户可以采用合理的服务设计模式规避问题，同时期待后续版本中的官方修复。对于关键业务系统，建议采用声明式配置管理，避免依赖服务的动态变更能力。