Linux bridge使用dummy接口调用IPVS的问题
在IPVS: How Kubernetes Services Direct Traffic to Pods一文中,作者给出了一个简单的组网(如下)来模拟kubernetes是如何使用IPVS进行通信的。
![image](https://img2020.cnblogs.com/blog/1334952/202104/1334952-20210413160313552-414491209.png)
问题描述
当在netns_leah
命名空间中测试通过VIP访问netns_dustin
中的服务时,发现如果不创建一个类型为dummy
,且IP为VIP(10.100.100.100)的接口时,访问是不通的。作者怀疑bridge_home
接口并没有调用IPVS规则。
如下图,IPVS规则实际是iptables处理路径上挂载的钩子。
![image](https://img2020.cnblogs.com/blog/1334952/202104/1334952-20210413160939401-595586113.png)
问题分析
按照原文的步骤,创建dummy接口之后就可以成功执行如下命令,从netns_dustin
命名空间通过VIP访问netns_dustin
中的服务:
sudo ip netns exec netns_dustin curl 10.100.100.100:8080
抓包发现执行逻辑如下:
![image](https://img2020.cnblogs.com/blog/1334952/202104/1334952-20210413161552068-217893347.png)
![image](https://img2020.cnblogs.com/blog/1334952/202104/1334952-20210413161400355-255172948.png)
如果不配置dummy接口,将不会执行上述第四步,即bridge_home
不会发起到netns_dustin
的ARP广播请求,由此可以怀疑,从netns_leah
到bridge_home
的SYNC报文并没有经过IPVS规则,由于无法解析VIP,bridge_home
将根据默认路由转发目的地为VIP的报文。
本机的IP地址(192.168.118.148
)和默认路由如下:
![image](https://img2020.cnblogs.com/blog/1334952/202104/1334952-20210413162054383-686601560.png)
删除dummy接口,并在出接口ens33
上抓包,发现bridge_home
果然按照默认路由转发了报文。
![image](https://img2020.cnblogs.com/blog/1334952/202104/1334952-20210413162214103-1504928878.png)
总结
dummy接口相当于提供了一个让bridge_home
进入iptables的机会,这样就可以使用IPVS规则处理报文。