一次metallb lb ip不通问题排查

• 问题表现
• 初步排查
• 进一步排查
• 破案
• 分析
• 总结
• 参考

问题表现

有一个三节点的k8s集群，根据业务网络规划，除了每台机器上一张网卡给k8s用，还需要为每台机器配置网桥和另一块网卡。

其中一个节点的netplan配置如下所示：

network:
  version: 2
  renderer: networkd
  ethernets:
    # k8s用的网卡
    ens3:
      dhcp4: no
      addresses: [192.168.122.101/24]
      gateway4: 192.168.122.1
      nameservers:
        addresses: [114.114.114.114]
    # 另一张网卡
    ens18: {}
  bridges:
    br-bus:
      interfaces: [ens18]
      dhcp4: no
      addresses: [ 192.168.222.201/24 ]

在本次出问题的实验环境中，三台节点对应的vm实际上都是用同一台宿主机使用kvm拉起来的，网桥所在网段的网关192.168.222.1也就是kvm所在的这台宿主机。

k8s集群里部署了metallb，使用网桥所在的网段192.168.222.0/24作为LB网段。

问题的症状是：原本正常的k8s loadbalancer service，在某个节点重启后不再正常，从网关（也就是安装了kvm的宿主机，后文称为网关）上ping不通。

初步排查

1. 首先再拉一台kvm虚机，配置和三节点同网段的ip。通过这个机器去访问lb，发现一切正常。
2. 由于基于metallb实现的lb service，仅在service event中输出流量由哪个节点负责引导，而k8s中event会自动清除。所以对于非新建立的service，难以直接定位访问lb的流量被引导到了哪个节点。
3. 所以在三台节点同时抓包，在网关ping lb，确定流量被arp协议引导到了master2。
4. 但是master2并未回包，因此才有了不通的表现。为什么master2不回包呢？

进一步排查

结合上面排查的表现，通过1，我们可以确定集群里的metallb和k8s相关组件是正常的。

因此，重点是排查基础网络的情况，主要就是网桥、lb所在网段192.168.222.0/24的通讯情况了。

于是我们在网关上分别对三台节点网桥的ip进行联通性测试，诡异的事情发生了：

第一次在ping命令中遇到Redirect Host的提示，于是去查了一下该提示的含义，先问了chatgpt，再看了看《TCP/IP详解卷一》中关于该提示的解释。事后复盘，对于第一次遇到该提示的情况，即使查清楚了计算机网络里对该类问题的定义，也不一定能为解决问题提供直接的信息。

破案

经过不断地在网关对这三台节点上的网桥进行ping测试，发现一直都是只有一台能通，另外两台不通。

经过跟环境部署的同事沟通，同事提醒我确认下几台vm的mac地址是否有重复的情况。

经过一番查看，发现三台节点的网桥mac地址竟然是一样的！

分析

1. netplan中bridge未配置mac，那么其mac是怎么生成的？经过搜索，原来是根据/etc/machine-id进行映射生成的。
2. 查看环境中三个几点的machine-id，果然都是一样的。可能是负责打镜像的同事没有把machine-id重置。
3. 为什么在第四台机器上lb工作可以正常？为什么从网关ping就不正常？
   1. 从第四台机器访问，arp请求收到response后，把数据包填好，发给网关。网关发现这个包是完整的，会泛洪，从每个口发出去，即使三台目标mac重复了，但是总会有正确的一台回包，所以工作正常。
   2. 从网关直接访问，网关发起arp请求收到response后，把数据包填好，不会泛洪，而是会去查找转发表，向特定的某个机器发送数据包。后面又得知，同事在配置vm时，第二个节点的网卡配置错误了，这也解释了ping测试时，192.168.222.202的unreachable，因此推测lb流量是因为被引导到了这台有问题的机器而不通的。
   3. 那么问题又来了，网关和222.202不通，为什么lb的流量还会被引导到该节点呢？事实上metallb在选择speaker备选节点时，判断条件式node ready，并不能感知到外部网络联通性。该vm的网卡配置错误，并没有影响三个节点之间的网络互联，所以node都是ready的，所以所有node都有机会成为流量的引导点，作为metallb speaker的备选节点。这样，如果恰好lb被分配到了这样一个节点，就会导致metallb工作完全正常，但是lb ip不通的情况。说到底，还是基础设施层面二层网络联通性的问题，跟metallb关系不大。

总结

本次故障表现简单：lb ip不通。实际背后排查涉及到了以下几方面的知识，并不简单：

1. 对kubernetes lb service和metallb实现原理的理解
2. kvm网络配置
3. 对linux layer2网络故障的排查和解决

参考

18.04 - Netplan generates the same MAC address for bridges on two different machines - Ask Ubuntu