无法通过LoadBalancer IP访问Tanzu Community Edition K8s服务

故障由两个核心配置问题叠加导致：

1. TCE v0.12.1的单节点非托管集群默认基于Docker封装，本质是定制化的kind集群，K8s控制平面节点本身就是运行在Ubuntu虚拟机上的Docker容器，并非直接运行在虚拟机操作系统上的进程，因此节点IP是Docker自定义网桥br-908920d3a805分配的172.19.0.2，而非虚拟机物理网卡ens160的172.17.60.103，这是默认运行逻辑，不属于异常。
2. MetalLB二层模式的工作前提是：分配的LoadBalancer IP必须与节点直连的二层网络网段一致，节点可直接响应该IP的ARP请求。当前你给MetalLB分配的172.17.60.122属于虚拟机物理网卡所在的172.17.60.0/24网段，但承载K8s节点的Docker网桥属于172.19.0.0/16网段，两层网络默认不直连，访问时自然返回No route to host错误。

• 第一步：校验MetalLB现有配置
  执行以下命令查看当前MetalLB的IP地址池与广播规则：

  kubectl get ipaddresspools.metallb.io -A
  kubectl describe ipaddresspools.metallb.io -A
  kubectl get l2advertisements.metallb.io -A
  

  从已给出的服务信息判断，当前地址池已配置172.17.60.0/24网段地址，但该网段对容器化运行的K8s节点属于外部网络，节点无对应直连网卡，无法响应ARP请求。
• 第二步：按实际访问需求选择修复方案
  • 场景1：仅需在Ubuntu虚拟机本地访问LoadBalancer服务
    直接修改MetalLB地址池为Docker网桥br-908920d3a805所在的172.19.0.0/16网段空闲地址，避开已被Docker占用的172.19.0.1（网桥网关）、172.19.0.2（节点IP）即可，配置示例：

    apiVersion: metallb.io/v1beta1
    kind: IPAddressPool
    metadata:
      name: default-pool
      namespace: metallb-system
    spec:
      addresses:
      - 172.19.0.100-172.19.0.200
    ---
    apiVersion: metallb.io/v1beta1
    kind: L2Advertisement
    metadata:
      name: default-l2
      namespace: metallb-system
    

    应用配置后删除原有demo-service，等待Service重新分配同网段的ExternalIP，直接在虚拟机本地curl对应地址即可正常访问。
  • 场景2：需要局域网内其他设备跨主机访问LoadBalancer服务
    现有Docker桥接模式的集群无法满足该需求，需要重新部署TCE非托管集群，部署时指定节点使用Docker host网络模式，让K8s节点直接使用虚拟机的物理网卡网络。集群重建完成后再安装MetalLB，保留172.17.60.0/24网段的地址池（注意地址要避开DHCP分配范围，不与局域网现有设备IP冲突），同时执行以下命令开启kube-proxy的strictARP配置，让MetalLB可正常接管ARP响应：

    kubectl get configmap kube-proxy -n kube-system -o yaml | sed -e "s/strictARP: false/strictARP: true/" | kubectl apply -f - -n kube-system
    

• 第三步：连通性验证
  配置完成后先在虚拟机本地curl分配到的LoadBalancer IP，确认应用返回正常；如果是跨主机访问场景，再使用同局域网其他设备访问该IP，确认流量可达。

• TCE非托管集群的网络逻辑和kubeadm、k3s等直接部署在宿主机上的K8s发行版完全不同，所有kind集群的网络限制对其生效，不要直接套用裸金属/虚拟机部署的K8s网络配置经验。
• MetalLB二层模式下不需要手动给节点网卡配置LB IP的别名，MetalLB会自动发送免费ARP声明IP归属，但前提是节点直连LB IP所在的二层广播域。
• 如果配置完成后仍出现连接拒绝，优先检查虚拟机ufw防火墙是否放通对应服务端口，以及Docker的iptables转发规则是否正常。

内容的提问来源于stack exchange，提问作者Shukti