Kube-OVN集群节点重启问题分析与解决方案

问题背景

在使用Kube-OVN构建的Kubernetes高可用集群环境中，运维人员发现当执行主节点(master node)重启操作时，集群网络会出现异常无法自动恢复的情况。具体表现为：

1. 第一次重启主节点后，集群能够自动恢复
2. 第二次重启另一个主节点后，集群网络完全中断
3. 需要完全卸载并重新安装Kube-OVN才能恢复集群功能

问题现象分析

通过深入排查，发现以下关键现象：

1. CNI配置文件丢失：重启后节点上的/etc/cni/net.d/目录为空，缺少必要的00-multus.conf和01-kube-ovn.conflist配置文件
2. OVN数据库连接失败：ovn-central Pod无法建立数据库连接，日志显示"database not available"错误
3. 网络组件异常：kube-ovn-controller持续处于CrashLoopBackOff状态
4. Pod网络不可达：新创建的Pod无法获取IP地址，网络功能完全中断

根本原因

经过技术分析，确定问题的根本原因在于：

1. OVN数据库文件丢失：节点重启时，系统自动同步机制会覆盖/etc/origin/ovn目录，导致OVN的Northbound和Southbound数据库文件被删除
2. 集群仲裁机制失效：当两个主节点相继重启后，剩余的节点无法形成数据库集群多数派，导致数据库服务无法自动恢复
3. CNI配置未持久化：Kube-OVN的CNI配置文件未得到持久化保存，节点重启后被清除

解决方案

针对上述问题，推荐以下解决方案：

1. 保护关键目录

修改系统配置，将以下目录排除在自动同步范围外：

• /etc/origin/ovn：包含OVN数据库文件
• /etc/cni/net.d/：包含CNI配置文件

2. 数据库备份与恢复

实施定期备份策略，对OVN数据库进行备份：

# 备份Northbound数据库
ovsdb-tool cluster-to-standalone /backup/ovnnb_db.db /etc/origin/ovn/ovnnb_db.db

# 备份Southbound数据库
ovsdb-tool cluster-to-standalone /backup/ovnsb_db.db /etc/origin/ovn/ovnsb_db.db

3. 高可用配置优化

确保Kube-OVN的高可用配置正确：

# values.yaml关键配置
replicaCount: 3
MASTER_NODES: "192.168.0.11,192.168.0.12,192.168.0.13"

4. 监控与告警

部署监控系统，对以下指标进行监控：

• OVN数据库集群状态
• ovn-central Pod健康状态
• 网络连通性检查

最佳实践建议

1. 节点维护流程：

   • 执行节点重启前，先确认集群健康状态
   • 采用滚动重启策略，确保每次只有一个主节点下线
   • 重启后验证所有网络组件状态

2. 配置管理：

   • 使用ConfigMap持久化CNI配置
   • 实施配置漂移检测机制

3. 灾难恢复：

   • 制定详细的恢复流程文档
   • 定期进行故障恢复演练

总结

Kube-OVN作为Kubernetes的网络插件，在生产环境中需要特别注意其状态数据的持久化问题。通过合理的配置保护、备份策略和高可用设计，可以确保集群在节点维护过程中的稳定性。本文描述的问题和解决方案，为使用Kube-OVN的企业用户提供了有价值的参考。