MetalLB 负载均衡器在局域网中无法访问的问题分析与解决方案

问题背景

在使用 MetalLB 为 Kubernetes 集群配置负载均衡时，用户遇到了一个典型问题：从集群节点内部可以成功访问通过 MetalLB 分配的负载均衡 IP（192.168.0.30），但同一局域网内的其他机器却无法访问该地址。通过抓包分析发现，虽然 ARP 请求得到了正确响应，但 TCP 握手请求（SYN 包）没有得到回应。

技术分析

1. 网络通信流程分析

从技术角度来看，这个问题涉及以下几个关键环节：

1. ARP 解析：客户端发送 ARP 请求查询 192.168.0.30 的 MAC 地址，MetalLB 正确响应
2. TCP 握手：客户端发送 SYN 包到 192.168.0.30，但未收到 SYN-ACK 响应
3. 网络路径：数据包到达节点但未被正确处理

2. 可能的原因

根据经验，这类问题通常由以下几个因素导致：

1. 反向路径过滤（RPF）：Linux 系统默认启用的安全机制，会丢弃不符合路由规则的数据包
2. 节点标签配置：node.kubernetes.io/exclude-from-external-load-balancers 标签可能导致节点不参与负载均衡
3. CNI 插件限制：Flannel 等 CNI 插件可能对主机网络通信有特殊要求
4. 网络策略：虽然安全防护已关闭，但可能存在其他网络限制

解决方案

方案一：检查并调整反向路径过滤

在 Kubernetes 节点上执行以下命令检查 RPF 设置：

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.eno1.rp_filter

如果值为 1（严格模式），建议调整为宽松模式：

sysctl -w net.ipv4.conf.all.rp_filter=2
sysctl -w net.ipv4.conf.eno1.rp_filter=2

方案二：检查节点标签

查看节点是否带有排除标签：

kubectl get nodes --show-labels | grep exclude-from-external-load-balancers

如有，移除该标签：

kubectl label nodes <node-name> node.kubernetes.io/exclude-from-external-load-balancers-

方案三：CNI 插件配置优化

对于 Flannel 用户，可以尝试以下配置调整：

1. 确保 Flannel 使用主机网关模式（host-gw）而非默认的 VXLAN
2. 检查 Flannel 的 net-conf.json 配置，确保与物理网络兼容

深入理解

MetalLB 在二层模式（L2）下工作时，实际上是通过 ARP/NDP 协议宣告负载均衡 IP 的归属。当外部客户端访问该 IP 时，数据包会直接发送到宣告该 IP 的节点。此时，节点的网络栈需要：

1. 接受目标为非本机 IP 的数据包（需开启 IP 转发）
2. 正确处理 DNAT（将目标 IP 转换为 Service 的 ClusterIP）
3. 确保回程流量路径正确

最佳实践建议

1. 网络规划：确保 MetalLB 的 IP 池与物理网络兼容，避免 IP 冲突
2. 系统配置：在所有节点上统一调整内核参数，特别是与网络相关的 sysctl 设置
3. 监控验证：使用 tcpdump 和 kubectl 命令实时监控网络流量和 Service 状态
4. 文档记录：记录所有网络变更，便于问题回溯

总结

MetalLB 在局域网环境中无法访问的问题通常不是由 MetalLB 本身引起，而是与底层网络配置密切相关。通过系统性地检查网络栈配置、节点标签和 CNI 插件设置，大多数情况下都能找到解决方案。对于生产环境，建议在部署前充分测试网络连通性，并建立完善的监控机制。