MetalLB控制器重启导致服务IP重新分配问题分析

问题背景

在Kubernetes集群中使用MetalLB作为负载均衡器时，发现当MetalLB控制器（controller）组件重启后，部分处于Pending状态的服务会被错误地重新分配IP地址，甚至会出现IP地址被其他服务抢占的情况。这个问题在MetalLB 0.13.12版本中出现，而在0.12.1版本中则表现正常。

问题现象

当MetalLB控制器重启时，它会重新处理所有服务。如果此时有服务处于Pending状态，这些服务可能会被错误地分配之前已经分配给其他服务的IP地址，导致IP地址的级联重新分配。具体表现为：

1. 创建大量测试LB服务（如250个）
2. 修改控制器使其启动时有延迟（60-100秒）
3. 在控制器完全启动前创建新服务（这些服务会处于Pending状态）
4. 控制器完全启动后，部分服务的LB IP会被重新分配

技术分析

该问题源于MetalLB控制器在处理服务时的同步逻辑。在0.12.1版本中，控制器会等待完全同步后才开始分配IP地址，这确保了IP分配的原子性和一致性。而在0.13.12版本中，控制器的处理逻辑发生了变化，导致在同步过程中就可能开始分配IP地址。

关键区别在于：

• 0.12.1版本：控制器明确等待同步完成（"controller not synced yet"日志），然后按顺序分配IP
• 0.13.12版本：控制器在同步过程中就可能开始处理服务，导致竞争条件

解决方案

该问题已在MetalLB 0.14.2版本中修复。修复的核心是改进了控制器的同步逻辑，确保在完全同步前不会进行IP分配操作，恢复了类似0.12.1版本的行为。

最佳实践

为避免类似问题，建议：

1. 在生产环境中使用经过充分测试的稳定版本
2. 大规模部署前进行充分的测试，特别是控制器重启场景
3. 监控服务的IP地址变化，设置告警机制
4. 考虑使用固定IP分配策略减少意外变化

总结

MetalLB控制器的IP分配逻辑对服务稳定性至关重要。0.13.12版本中引入的同步问题可能导致服务IP意外变化，影响生产环境稳定性。升级到0.14.2或更高版本可以解决此问题，同时建议用户关注控制器的同步状态和IP分配日志，确保负载均衡服务的稳定性。