Metallb Speaker CrashLoopBackOff及LoadBalancer暴露应用异常排查

你的集群目前存在几个关联的故障点，得从最影响基础功能的问题开始逐一排查：

1. 优先修复coredns和存储Pod宕机问题 #

coredns是集群内部的核心DNS服务，它挂掉的话，集群内Pod和服务之间根本无法正常解析域名——Metallb的Speaker组件大概率会因为连不上集群API服务、找不到依赖组件而崩溃。存储Pod宕机也会导致需要持久化的集群组件（比如部分插件）无法正常启动。

先执行这些命令获取具体故障日志和事件：

# 查看coredns的运行日志
kubectl -n kube-system logs -l k8s-app=kube-dns
# 查看存储相关Pod的日志（替换成你的存储Pod标签）
kubectl -n kube-system logs -l <存储Pod标签键>=<存储Pod标签值>
# 查看coredns Pod的详细启动事件
kubectl -n kube-system describe pods -l k8s-app=kube-dns
# 查看存储Pod的详细启动事件
kubectl -n kube-system describe pods -l <存储Pod标签键>=<存储Pod标签值>

coredns宕机常见原因包括：节点网络异常、kube-dns配置错误、集群DNS参数（比如clusterDomain）有误、RBAC权限不足等；存储Pod宕机多是卷挂载失败、存储服务本身故障导致。先把这些基础组件拉起来，再看Metallb的问题是否缓解。

2. 定位Metallb Speaker CrashLoopBackOff的根源 #

等集群基础功能恢复后，再聚焦Metallb Speaker的问题，执行以下命令获取关键信息：

# 获取Speaker Pod的崩溃日志
kubectl -n metallb-system logs -l app=metallb,component=speaker
# 查看Speaker Pod的完整事件记录
kubectl -n metallb-system describe pods -l app=metallb,component=speaker

常见的Speaker崩溃诱因有这些：

• 网络权限限制：Speaker需要操作节点的网络栈（比如发送ARP/NDP报文），如果节点的SELinux/AppArmor规则过严，会阻止它的操作导致崩溃。
• 地址池配置冲突：你配置的192.168.1.100-192.168.1.150网段，是否和集群节点IP、其他服务的外部IP重叠？或者这个网段不在节点所在的物理网络里？
• Metallb组件不完整：检查Controller组件是否正常运行：

  kubectl -n metallb-system get pods -l app=metallb,component=controller
  

  如果Controller也异常，大概率是Metallb安装时遗漏了RBAC权限配置这类步骤。
• 节点内核参数不达标：Metallb的Layer2模式需要节点开启net.ipv4.ip_forward，可以在每个节点上检查：

  sysctl net.ipv4.ip_forward
  

  如果返回net.ipv4.ip_forward = 0，需要执行sysctl -w net.ipv4.ip_forward=1开启，并写入/etc/sysctl.conf做持久化。

3. 验证LoadBalancer Service的配置正确性 #

等Metallb组件恢复正常后，再检查你的LoadBalancer配置：

• 确认selector: part: watchdog和你要暴露的Pod标签完全匹配，执行kubectl get pods --show-labels查看Pod的标签信息，确保一致。
• 检查targetPort: 10069是否是Pod实际监听的端口，执行kubectl exec <你的Pod名称> -- netstat -tulnp查看Pod内的端口监听状态。

总结 #

当前核心矛盾是集群基础组件（coredns、存储Pod）宕机，这会直接导致整个集群的网络、存储功能异常，进而引发Metallb的连锁故障。建议先解决coredns和存储Pod的问题，再逐步排查Metallb Speaker的崩溃原因，最后验证LoadBalancer Service的配置是否正确。

内容的提问来源于stack exchange，提问作者Jaume Garcia Sanchez