MetalLB L2模式下多副本服务ARP风暴问题分析与解决

问题背景

在使用MetalLB为Kubernetes集群提供负载均衡服务时，用户报告了一个关于L2模式下服务连接不稳定的问题。具体表现为：当使用externalTrafficPolicy: Local配置且后端Pod分布在多个节点时，会出现间歇性的连接超时现象。经过深入分析，发现这是由于多个MetalLB Speaker节点同时响应ARP请求，导致网络中出现ARP冲突/风暴。

问题现象

用户部署了一个ingress-nginx控制器，配置为：

• 使用MetalLB L2模式（v0.14.9）
• 部署了2个副本，分布在不同的节点上
• 服务配置了externalTrafficPolicy: Local
• 使用单个IP地址池

在运行约30分钟后，外部客户端开始出现连接超时。通过arping命令测试发现，多个节点（有时是所有节点）同时响应同一个负载均衡IP的ARP请求，造成网络混乱。

技术分析

正常预期行为

在L2模式下，MetalLB应该：

1. 为每个服务IP选举一个主节点（Leader）
2. 只有主节点响应ARP请求
3. 其他节点保持沉默，即使它们也承载了服务的后端Pod

实际异常行为

观察到的异常现象包括：

1. 多个节点同时响应ARP请求
2. ARP响应来自不同节点的MAC地址
3. 网络中出现ARP风暴，导致客户端无法稳定连接

根本原因

经过排查，可能的原因包括：

1. MetalLB的Leader选举机制在特定条件下失效
2. 节点网络配置问题（如ARP代理、路由过滤等）
3. 内核网络栈的异常行为
4. CNI插件（如Calico）与MetalLB的交互问题

解决方案

用户最终通过以下步骤解决了问题：

1. 内核降级：将Ubuntu内核从6.8.0-57-generic降级到6.8.0-55-generic版本
2. CNI调整：改用manifest方式安装Calico，而非Operator方式

这些调整使得系统稳定运行超过4天，问题不再复现。

预防建议

对于类似场景，建议采取以下预防措施：

1. 内核版本选择：使用经过充分测试的内核版本，避免使用可能存在网络问题的最新版本
2. CNI部署方式：对于Calico等CNI插件，优先选择manifest方式部署以获得更稳定的行为
3. 网络参数检查：确保节点上的以下参数配置正确：
   • arp_proxy设置为0
   • rp_filter配置合理
   • ip_forward根据需求设置
4. 监控设置：部署网络状态检测，及时发现ARP异常

总结

MetalLB在L2模式下与externalTrafficPolicy: Local配合使用时，需要特别注意网络配置的稳定性。当出现类似ARP风暴问题时，可以从内核版本、CNI实现方式和基础网络配置等多个维度进行排查。通过合理的配置和版本选择，可以确保MetalLB在复杂环境下稳定运行。

对于生产环境，建议在变更前充分测试，并建立完善的监控机制，以便快速发现和解决网络异常问题。