ipvs之ipvs0网卡

kubernetes将kube-proxy的代理模式设置为ipvs模式后会在每个创建一个ipvs0的网卡，并会在每个节点的ipvs0网卡上配置所有service的ip，等于每个节点都配置了很多相同的ip，为什么不会出现ip冲突？集群内部访问service ip如何访问？集群外部访问service ip又是如何访问？

ipvs0网卡

ipvs0网卡是一块dummy类型的虚拟网卡，可以手动添加，其中ipvs0只是一个名称，只是为了演示，所以和ipvs创建的网卡名一致：

ip li add ipvs0 type dummy

然后使用ip a查看该网卡

51: ipvs0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether ce:8b:5d:28:59:28 brd ff:ff:ff:ff:ff:ff

然后给该网卡配上一个ip地址

ip addr add 172.20.42.51/22 dev ipvs0

查看网卡

51: ipvs0: <BROADCAST,NOARP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether ce:8b:5d:28:59:28 brd ff:ff:ff:ff:ff:ff
    inet 172.20.42.51/22 scope global ipvs0
       valid_lft forever preferred_lft forever

按照正常的逻辑，我们应该是将该网卡启动，然后该网卡才能正常工作，所以启动该网卡

ip link set ipvs0 up

查看网卡

51: ipvs0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether ce:8b:5d:28:59:28 brd ff:ff:ff:ff:ff:ff
    inet 172.20.42.51/22 scope global ipvs0
       valid_lft forever preferred_lft forever
    inet6 fe80::cc8b:5dff:fe28:5928/64 scope link 
       valid_lft forever preferred_lft forever

尝试在其他节点ping这个ip

# ping 172.20.42.51
PING 172.20.42.51 (172.20.42.51) 56(84) bytes of data.
From 172.20.42.1 icmp_seq=12 Destination Host Unreachable
From 172.20.42.1 icmp_seq=13 Destination Host Unreachable

并不能ping通，来看一下ipvs0这块网卡和其他网卡有什么不同之处，可以发现ipvs0网卡有一个NOARP的标志，表示的是禁用arp，并且不管是down状态和up状态都有这个标志，说明这块网卡无论如何都是无法响应arp请求的。

关键在于ipvs0处于up状态时，内核会认为ipvs0这块网卡是可用的，但是因为禁用了arp，所以对这块网卡的arp请求都会直接丢弃掉，所以外部直接ping这块网卡的ip无法ping通，解释了刚才演示的效果。

而当ipvs0这块网卡处于down状态时，因为arp请求的目标地址已经配在了ipvs0网卡上，所以内核当然会认为这次请求确实就是发给它的，但由于ipvs0这块网卡是down状态，所以内核会认为这块网卡不可用，并将同属于当前局域网的另一块网卡，也就是真实连接在交换机上的物理网卡的mac地址返回回去，下面演示一下

ip link set ipvs0 down

然后在尝试在其他节点ping这个ip

# ping 172.20.42.51
PING 172.20.42.51 (172.20.42.51) 56(84) bytes of data.
64 bytes from 172.20.42.51: icmp_seq=1 ttl=64 time=0.246 ms
64 bytes from 172.20.42.51: icmp_seq=2 ttl=64 time=0.237 ms
64 bytes from 172.20.42.51: icmp_seq=3 ttl=64 time=0.228 ms

确实能ping通了，但是是不是将那块真实的物理网卡的mac地址返回了呢？可以在其他节点看一下

# arp -n
172.20.42.50             ether   52:54:00:7c:bf:93   C                     br0
172.20.42.51             ether   52:54:00:7c:bf:93   C                     br0

其中50是物理网卡的ip，这两个ip对应的mac地址确实是一样的，说明在对ipvs0网卡发送arp请求时，确实是将物理网卡的mac地址返回了回来

结论

所以现在可以回答最开始的问题
为什么不会出现ip冲突？
ip冲突一般是在多个节点上配置了同样的ip，我们需要在外部使用这个ip，比如使用ssh连接这个ip进入到这个节点，或者用这个ip提供了某项服务，比如nginx，但是某些节点有这个服务，某些节点又没有这个服务。
首先肯定也是先通过arp请求获取到mac地址，然后通过mac地址最终定位到具体的节点，但是问题是所有配置了这个ip的节点都会将mac地址返回，我们并不能确定第一次返回的mac地址是哪个节点的mac地址，所以ssh或者http请求可能就会发往错误的节点，ssh时出现的问题就是明明输入了正确的用户名和密码，但是就是登录不了，http请求的错误就是告诉你网址为xxx的网页可能暂时无法连接，或者它已永久性地移动到了新网址。

但是在使用ipvs0这块网卡的时候，首先，我们不会通过ssh去连它，在k8s里就不是干这件事的，因为已经有真实的物理网卡可以连，然后就是对外提供服务，这个只有在给服务设置了externalip的时候，会直接在ipvs0网卡上配置一个外部能访问的ip，外部直接通过这个ip访问对应的服务，除externalip之外，ipvs0上配的都是内部的ip，只会在集群内部访问。

先看从外部访问，也就是externalip，通过externalip+port对外暴露服务，每个节点都能提供一样的服务，所以不管那个节点先返回arp请求，结果是一样的，所以外部用户需要知道访问的是哪个节点吗？不需要！

然后看内部访问，内部访问ipvs0上的ip等于访问localhost，本地就会将ip截获到，然后ipvs再根据负载均衡策略将流量转发到对应的pod