Ipvs0 network card of IPVS

kubernetes take kube-proxy The proxy mode of is set to ipvs After the pattern, one will be created for each ipvs0 Network card of , And will be displayed on the ipvs0 Configure all on the network card service Of ip, Each node is configured with many identical ip, Why doesn't it appear ip Conflict ？ Cluster internal access service ip How to access the ？ External access to the cluster service ip How to access ？

ipvs0 network card

ipvs0 Network card is one dummy Type of virtual network card , Can be added manually , among ipvs0 It's just a name , Just to demonstrate , So and ipvs The network card names created are consistent ：

ip li add ipvs0 type dummy

And then use ip a View the network card

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

Then attach a to the network card ip Address

ip addr add 172.20.42.51/22 dev ipvs0

View NIC

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

According to normal logic , We should start the network card , Then the network card can work normally , So start the network card

ip link set ipvs0 up

View NIC

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

Try on other nodes ping This 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

Does not ping through , Take a look at ipvs0 What is the difference between this network card and other network cards , You can find ipvs0 The network card has a NOARP The logo of , Indicates that... Is disabled arp, And whether it's down State and up Status has this flag , This indicates that the network card is unable to respond anyway arp Requested .

The key lies in ipvs0 be in up In the state of , The kernel will think ipvs0 This network card is available , But because it is disabled arp, So for this network card arp Requests are discarded directly , So external direct ping This network card ip unable ping through , Explained the effect of the demonstration just now .

And when ipvs0 This network card is in down In the state of , because arp The target address of the request is already assigned to ipvs0 NIC , So the kernel will of course think that this request was actually sent to it , But because of ipvs0 This network card is down state , So the kernel will think that this network card is not available , And another network card belonging to the current LAN , That is, the physical network card actually connected to the switch mac Address back , Let's demonstrate

ip link set ipvs0 down

Then try on other nodes ping This 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

It does ping Through the , But is it the real physical network card mac The address is returned ？ You can view it at other nodes

# 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

among 50 It's a physical network card ip, these two items. ip Corresponding mac The address is exactly the same , Explain that you are right ipvs0 Send the network card arp When asked , It is the physical network card mac The address returned back

Conclusion

So now you can answer the first question
Why doesn't it appear ip Conflict ？
ip Conflicts usually occur when multiple nodes are configured with the same ip, We need to use this externally ip, For example, use ssh Connect this ip Enter this node , Or use this ip Provides a service , such as nginx, But some nodes have this service , Some nodes do not have this service .
First of all, it must pass first arp Request get to mac Address , And then through mac The address is finally located to the specific node , But the problem is that all are configured with this ip All nodes of the will mac The address to return , We are not sure what we will return for the first time mac Which node does the address belong to mac Address , therefore ssh perhaps http The request may be sent to the wrong node ,ssh The problem is that you have entered the correct user name and password , But I just can't log in ,http The error in the request is to tell you that the web address is xxx Your web page may be temporarily unreachable , Or it's permanently moved to a new site .

But in use ipvs0 This network card , First , We won't pass ssh Connect it , stay k8s Li didn't do it , Because there is already a real physical network card that can be connected , Then there is the provision of external services , This is only when the service is set externalip When , Will be directly in ipvs0 Configure a network card that can be accessed externally ip, Outside directly through this ip Access the corresponding service , except externalip outside ,ipvs0 All the accessories are internal ip, It can only be accessed within the cluster .

Let's first look at external access , That is to say externalip, adopt externalip+port External exposure services , Each node can provide the same service , So no matter which node returns first arp request , The result is the same , So do external users need to know which node they are accessing ？ Unwanted ！

Then look at the internal access , Internal visits ipvs0 Upper ip Equal access localhost, Local people will ip Intercept , then ipvs Then the traffic is forwarded to the corresponding... According to the load balancing policy pod