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

问题现象

在使用MetalLB 0.14.8版本配合Antrea CNI的Kubernetes集群（v1.31.1+rke2r1）中，发现某个特定的LoadBalancer服务出现外部访问异常。具体表现为：

1. 通过ClusterIP或Pod内部访问服务正常
2. 从集群外部节点访问LoadBalancerIP时连接超时
3. ARP检测显示IP地址被错误节点宣告
4. 控制器日志出现"servicel2statuses.metallb.io not found"错误

技术背景

MetalLB的L2模式工作原理：

• 通过ARP/NDP协议在局域网内宣告负载均衡IP
• 使用servicel2status CRD记录服务与节点的映射关系
• Speaker组件负责在对应节点上进行二层通告

深入分析

异常现象中存在两个关键矛盾点：

1. 节点映射不一致

# 服务实际运行节点
capacitor-5bdc9f677f-zrqhd   10.201.0.153   kube03.company.com

# MetalLB记录的宣告节点
l2-59cjg   kube04.company.com   capacitor

2. 网络连通性差异

• 集群内访问成功，说明服务本身运行正常
• 集群外访问失败，但ARP响应存在，说明二层通告机制在工作

排查过程

1. 基础检查

• 确认MetalLB配置正确
• 检查节点网络连通性
• 验证其他LoadBalancer服务正常

2. 深入追踪

• 发现NetworkPolicy影响了外部连接
• 即使强制调度Pod到指定节点，问题依旧存在
• ARP响应始终来自错误节点

3. 关键发现

• 网络策略限制了外部访问权限
• 二层通告机制与网络策略产生冲突

解决方案

1. 修正NetworkPolicy配置，允许外部流量
2. 清理并重建相关服务资源
3. 验证MetalLB宣告节点与实际运行节点的一致性

经验总结

1. 当出现内外访问不一致时，应优先检查网络策略
2. MetalLB的L2通告依赖于底层网络畅通
3. 服务不可达问题需要分层排查：
   • 服务健康状态
   • 网络策略限制
   • 负载均衡器配置
   • 底层网络连通性

最佳实践建议

1. 部署服务时明确网络访问需求
2. 定期检查NetworkPolicy与实际流量的匹配情况
3. 使用MetalLB时监控servicel2status资源状态
4. 重要服务建议同时配置健康检查和就绪检查