问题极可能出在ARP广播冲突上：节点被标签node.kubernetes.io/exclude-from-external-load-balancers排除，或多网卡同网段导致内核抢答ARP，使VIP未出现在接口且arping无响应。
当 MetalLB 分配的 VIP 无法被外部访问，ping 不通、arping 无响应、节点网络接口上查不到该 IP，且确认控制器已成功分配地址——问题极可能出在 ARP 广播冲突上，而非服务配置或路由错误。
确认 VIP 是否被正确宣告
在任一 Kubernetes 节点上执行：kubectl get svc -A | grep LoadBalancer，确认服务状态为 ExternalIP 已填入且非 pending。
运行 kubectl logs -n metallb-system deploy/controller | tail -10，检查是否有 announcing service 日志；若无，说明控制器未触发宣告流程，跳过后续 ARP 排查。
检查 Speaker 是否在目标节点运行并监听
执行 kubectl get pods -n metallb-system -o wide，确认 speaker Pod 处于 Running 状态，并分布在你期望承载 VIP 的节点上。
进入对应节点，运行 ip addr show | grep -A2 "inet.*[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}"，确认 VIP 未出现在任何接口上——这是 ARP 冲突的典型表征，而非正常宣告失败。
【必须确保 speaker 容器以 hostNetwork=true 运行，否则无法绑定主机网络栈发送 ARP】
定位 ARP 冲突源：三步抓“李鬼”
第一步：从第三方同网段主机（非 Kubernetes 集群节点）执行：sudo arping -c 5 -I eth0 VIP地址。
第二步：若输出中出现两条及以上不同 MAC 地址的 Unicast reply，例如：
→ Unicast reply from VIP地址 [00:11:22:aa:bb:cc] 0.786ms
→ Unicast reply from VIP地址 [33:44:55:dd:ee:ff] 1.203ms
则确认存在 ARP 冲突，“00:11:22:aa:bb:cc”是合法 MetalLB 宣告的 MAC，“33:44:55:dd:ee:ff”即为抢占者。
第三步：登录核心交换机或网关，执行 display arp | include VIP地址（华为）或 show arp | include VIP地址（Cisco），观察是否同一 IP 对应两个 MAC 条目，且端口不同——这直接暴露冲突设备物理位置。
验证节点是否被 MetalLB 排除
方法一：检查节点标签
执行 kubectl get nodes -o wide 获取节点名，再对每个节点运行：kubectl get node 节点名 -o jsonpath='{.metadata.labels}' | grep exclude-from-external-load-balancers。若返回结果非空，该节点上的 speaker 将彻底忽略 VIP 宣告。
方法二：临时清理标签验证
执行 kubectl label node 节点名 node.kubernetes.io/exclude-from-external-load-balancers-（注意末尾减号），等待约 10 秒后再次检查 ip addr，VIP 应立即出现在该节点接口上。
排除多网卡同网段干扰
若节点有多个网卡接入同一子网（如 eth0 和 eth1 均配置 192.168.10.0/24），MetalLB 默认只在主路由出口网卡宣告 VIP，但内核仍可能从另一张卡响应 ARP。
运行 sysctl net.ipv4.conf.all.arp_ignore，若返回值为 0，说明内核允许任意网卡响应本机 IP 的 ARP 请求——这会导致“一张卡宣告 VIP，另一张卡抢答 ARP”，外部看到的就是间歇性可达。
修复命令：echo "net.ipv4.conf.all.arp_ignore = 1" | sudo tee -a /etc/sysctl.conf && sudo sysctl -p。
