Talos集群部署MetalLB后无法访问LoadBalancer类型服务

看起来你已经走完了集群部署、MetalLB配置和Adminer服务安装的流程，结果卡在了LoadBalancer服务的访问上——这种情况在Talos+MetalLB的组合里挺常见的，我来帮你一步步排查可能的问题：

第一步：先确认MetalLB自身的状态是否正常 #

MetalLB如果没正常跑起来，LoadBalancer IP就算分配了也没法转发流量，先查这个：

• 检查MetalLB的所有组件Pod状态：

  kubectl get pods -n metallb-system
  

  你需要看到controller和speaker两个组件都处于Running状态，特别是speaker必须在你的worker节点（192.168.0.15）上正常运行——Talos默认控制平面不会调度负载类Pod，所以speaker跑在worker上才对。
• 检查L2广告配置是否生效：

  kubectl get l2advertisements.metallb.io -n metallb-system
  

  看看你定义的l2adv是否关联了apps IP池，状态是否正常。

第二步：验证集群内部的服务连通性 #

先排除集群内部的问题，确认Service到Pod的链路是通的：

• 检查Adminer的Pod是否正常运行：

  kubectl get pods -n default
  

  确保Pod处于Running状态，没有重启记录。如果有异常，用日志排查：

  kubectl logs <你的Adminer Pod名称> -n default
  

  重点看服务是否正常监听了18080端口。
• 检查Service的Endpoint是否正确关联：
  你之前贴了kubectl describe svc adminer的部分内容，一定要看Endpoints字段——如果这里是空的，说明Service的标签选择器和Pod的标签不匹配，导致没关联上Pod。这是新手最容易踩的坑，比如TrueCharts的Adminer可能自带特定的标签，你需要确认Service的selector和Pod的labels是否一致。
• 测试ClusterIP访问：
  如果Endpoint正常，先通过ClusterIP访问试试：

  kubectl run -it --rm curl-test --image=curlimages/curl -- curl <Adminer的ClusterIP>:18080
  

  如果能正常返回内容，说明Service到Pod的链路没问题，问题出在LoadBalancer的IP转发环节；如果也不通，那先解决集群内部的连通性问题。

第三步：排查Talos系统的特殊限制 #

Talos是个安全加固的操作系统，默认的防火墙和网络策略可能会挡住流量：

• 检查worker节点的防火墙规则：
  用talosctl登录到worker节点查看防火墙：

  talosctl -n 192.168.0.15 firewall list
  

  确认是否允许18080端口的入站流量，以及是否允许MetalLB L2模式需要的ARP/NDP协议流量（Talos默认可能会限制这些）。如果没有对应的规则，需要添加：

  talosctl -n 192.168.0.15 firewall ingress allow --port 18080/udp --port 18080/tcp
  talosctl -n 192.168.0.15 firewall ingress allow --protocol arp
  

• 检查kube-proxy的运行模式：
  Talos默认kube-proxy可能用IPVS模式，确认规则是否正确生成：

  ipvsadm -Ln | grep 192.168.0.16
  

  如果能看到对应的转发规则到Adminer的Pod IP，说明IPVS没问题；如果是iptables模式，检查iptables规则：

  iptables-save | grep adminer
  

  看是否有对应的DNAT规则。

第四步：验证MetalLB L2模式的IP绑定 #

L2模式下，MetalLB会把LoadBalancer IP绑定到worker节点的网卡上，你需要确认这个绑定是否生效：

• 在worker节点上查看IP地址：

  ip addr
  

  看看是否有192.168.0.16这个IP（可能是临时的虚拟IP，或者绑定在网卡的别名上）。
• 在你的客户端机器上检查ARP表：

  arp -a 192.168.0.16
  

  确认对应的MAC地址是worker节点（192.168.0.15）的网卡MAC——如果不是，说明L2广告没正常工作，客户端找不到对应的节点。

最后：一些常见的修复尝试 #

如果上面的排查找到了问题，针对性修复；如果还没找到，可以试试：

• 重启MetalLB的speaker Pod：

  kubectl delete pod -n metallb-system -l app=metallb,component=speaker
  

• 重启kube-proxy：

  kubectl rollout restart daemonset kube-proxy -n kube-system
  

• 检查TrueCharts的Adminer配置是否有特殊的网络设置，比如是否启用了网络策略，挡住了外部流量。

备注：内容来源于stack exchange，提问作者Johan