Linux kind 的 multi-node 配置与 metallb 负载均衡集成

kind multi-node集群默认不支持loadbalancer因docker无真实云lb，k8s卡pending；需禁用kind内置lb（设disabledefaultcni: true）并配metallb layer 2模式，ip池须在kind子网内且speaker启用hostnetwork。

为什么 kind 的 multi-node 集群默认不支持 LoadBalancer 类型 Service

因为 kind 底层用的是 Docker 容器模拟节点，没有真实云厂商的负载均衡器，kubernetes 会卡在 pending 状态，kubectl get svc 显示 EXTERNAL-IP <pending></pending>。这不是配置错了，是机制上缺一环——得自己补个 LoadBalancer 实现，metallb 就是干这个的。

用 metallb 前必须关掉 kind 的默认 LoadBalancer 模拟

kind v0.20+ 默认启用了实验性内置 LB（基于 docker network 和端口映射），它和 metallb 冲突：两个组件同时抢 LoadBalancer 类型 Service，会导致 IP 分配混乱、健康检查失败、甚至 metallb 的 speaker 不工作。

关闭方式很简单，在 kind 配置文件里显式禁用：

kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 networking:   disableDefaultCNI: true  # 必须设为 true   # 不要写 loadBalancer: {} 或类似字段

常见错误：

• 只删了 loadBalancer 字段但没设 disableDefaultCNI: true → 内置 LB 还在运行
• 用 kind create cluster --config=... 重装集群但忘了删旧集群 → 旧容器残留网络规则，新 metallb 无法绑定 IP
• 没清理 docker network inspect kind 里的 com.docker.network.bridge.host_binding_ipv4 相关配置 → 导致 metallb 分配的 IP 被 Docker 拦截

metallb 的 Layer 2 模式怎么配才不丢包

multi-node kind 集群里，metallb 只能用 layer2 模式（不能用 bfd 或 bgp，因为 Docker 网络不支持跨容器 BGP 会话）。但 Layer 2 有个硬伤：ARP 广播只在二层广播域有效，而 kind 多节点其实是多个容器连在同一个 Docker 网桥上——看似同网段，实则内核 ARP 表可能不更新，导致流量发到旧 MAC 地址上，连接超时。

关键修复点：

• 给 metallb 的 ConfigMap 指定一个**严格落在 kind 网络子网内**的 IP 池，比如 kind 默认网段是 172.18.0.0/16，那就配 172.18.255.200-172.18.255.250，别用 192.168.x.x 这种外部网段
• 确保所有 kind 节点容器都运行在同一个自定义 Docker 网络（不是默认 bridge），并在 kind 配置中显式指定：

  networking:   podSubnet: "172.18.0.0/16"   serviceSubnet: "172.18.255.0/24"

• metallb 的 speaker DaemonSet 必须加 hostNetwork: true，否则它收不到本机之外的 ARP 请求

kind multi-node + metallb 后，curl 访问 LoadBalancer IP 却超时

最常见原因是宿主机防火墙或 Docker 网络策略拦截了目标端口。metallb 分配的 IP 是虚拟的，靠 ARP 响应“冒充”成当前 leader 节点的 MAC 地址，但流量最终仍得进该节点的网络栈——而 kind 节点容器默认不暴露端口到宿主机，所以你在宿主机 curl 172.18.255.200:80 会失败。

解决路径只有两条：

• 在宿主机上用 docker exec -it kind-worker curl http://172.18.255.200:80 测试（验证 metallb 内部通不通）
• 真要从宿主机访问，得手动把 metallb IP 池里的某个 IP 绑定到宿主机网卡：

  sudo ip addr add 172.18.255.200/32 dev docker0

  ，并确保 docker0 网桥开启了 proxy_arp：

  sudo sysctl -w net.ipv4.conf.docker0.proxy_arp=1

• 别碰 iptables 规则：kind 自带 iptables 链（如 KIND-MASQ），手动加规则容易被覆盖或冲突

Layer 2 模式下没有“高可用切换”的实时感知，节点宕机后 ARP 缓存可能长达几十秒才失效，这期间请求会黑屏——这不是 bug，是协议限制，没法绕开。