MetalLB中L2广告异常问题的排查与解决

问题现象

在使用MetalLB 0.14.8版本为Kubernetes集群(v1.31.1+rke2r1)提供负载均衡服务时，发现一个特定服务无法通过其LoadBalancerIP从集群外部访问。通过排查发现，该服务的L2广告被错误地创建在了非Pod运行节点上。

详细分析

异常表现

1. 服务访问异常：从集群内部通过LoadBalancerIP访问服务正常，但从集群外部节点访问时出现连接超时。

2. L2广告位置错误：

   • servicel2status显示广告创建在kube04节点
   • 实际Pod运行在kube03节点

3. ARP响应验证：

   • 通过arping测试，发现返回的MAC地址确实来自错误的节点(kube04)

日志分析

在MetalLB Speaker组件日志中发现关键错误信息：

servicel2statuses.metallb.io "l2-759gw" not found

这表明控制器在尝试协调服务L2状态时，未能找到预期的资源对象。

根本原因

经过深入排查，发现问题的根本原因并非MetalLB本身，而是由于以下因素导致：

1. 网络策略干扰：在相关命名空间中存在网络策略(NetworkPolicy)，这些策略阻止了来自集群外部的连接请求。

2. 表象与实质：虽然L2广告位置异常是一个明显的现象，但它实际上是网络策略限制导致的表象问题，而非MetalLB的功能缺陷。

解决方案

1. 调整网络策略：检查并修改相关命名空间中的网络策略，确保允许来自集群外部的合法流量。

2. 验证修复效果：

   • 确认Pod到节点的绑定关系
   • 测试集群内外访问的一致性
   • 监控MetalLB Speaker日志中的错误信息是否消失

经验总结

1. 排查思路：当遇到服务访问异常时，需要系统性地检查整个网络路径，包括：

   • 负载均衡层(MetalLB)
   • 网络策略
   • 节点网络配置
   • 服务端点状态

2. 现象与本质：表面现象(如L2广告位置异常)可能是更深层次问题的表现，需要全面分析。

3. 测试验证：通过集群内外对比测试，可以快速定位问题边界，缩小排查范围。

这个问题虽然最终发现不是MetalLB的缺陷，但提供了宝贵的排查经验，展示了在复杂网络环境中诊断问题的方法论。