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 地址上，连接超时。
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
关键修复点：
- 给
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的speakerDaemonSet 必须加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内部通不通） - 真要从宿主机访问，得手动把
metallbIP 池里的某个 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，是协议限制，没法绕开。
