当强删 kube-vip（而没有先清理 lb svc）后，lb svc 的 vip 依旧在，如果 kube-vip 部署是没有使用 ipvs-strict-arp。这个时候可能会发生 arp 代答。
# sysctl -a | grep bond0.1825 | grep arp
net.ipv4.conf.bond0/1825.arp_accept = 0
net.ipv4.conf.bond0/1825.arp_announce = 0
net.ipv4.conf.bond0/1825.arp_filter = 0
net.ipv4.conf.bond0/1825.arp_ignore = 0
net.ipv4.conf.bond0/1825.arp_notify = 0
net.ipv4.conf.bond0/1825.drop_gratuitous_arp = 0
net.ipv4.conf.bond0/1825.proxy_arp = 0
net.ipv4.conf.bond0/1825.proxy_arp_pvlan = 0
[root@node01 ~]# route -n | grep 192.251.137.
192.251.133.0 192.251.137.254 255.255.255.0 UG 403 0 0 bond0.1825
192.251.137.0 0.0.0.0 255.255.255.0 U 403 0 0 bond0.1825
# arping 192.251.137.40
ARPING 192.251.137.40 from 192.251.137.31 bond0.1825
Unicast reply from 192.251.137.40 [BC:22:47:B5:8B:3E] 0.716ms
Unicast reply from 192.251.137.40 [30:B9:30:00:11:B5] 0.754ms
Unicast reply from 192.251.137.40 [30:B9:30:00:11:ED] 0.761ms
Unicast reply from 192.251.137.40 [30:B9:30:00:11:ED] 0.726ms
[root@node01 ~]# ip a | grep -i -B 1 -E "BC:22:47:B5:8B:3|30:B9:30:00:11:B5|30:B9:30:00:11:ED"
4: eno3: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
link/ether 30:b9:30:00:11:ed brd ff:ff:ff:ff:ff:ff
5: eno4: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc mq master bond0 state DOWN group default qlen 1000
link/ether 30:b9:30:00:11:ed brd ff:ff:ff:ff:ff:ff
--
13: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master ovs-system state UP group default qlen 1000
link/ether 30:b9:30:00:11:ed brd ff:ff:ff:ff:ff:ff
--
14: bond0.1825@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 30:b9:30:00:11:ed brd ff:ff:ff:ff:ff:ff
--
15: bond0.2095@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 30:b9:30:00:11:ed brd ff:ff:ff:ff:ff:ff
--
29: br-managenet: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether 30:b9:30:00:11:ed brd ff:ff:ff:ff:ff:ff
[root@node03 ~]# ip a | grep -i -B 1 -E "BC:22:47:B5:8B:3|30:B9:30:00:11:B5|30:B9:30:00:11:ED"
4: eno3: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
link/ether 30:b9:30:00:11:b5 brd ff:ff:ff:ff:ff:ff
5: eno4: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc mq master bond0 state DOWN group default qlen 1000
link/ether 30:b9:30:00:11:b5 brd ff:ff:ff:ff:ff:ff
--
13: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master ovs-system state UP group default qlen 1000
link/ether 30:b9:30:00:11:b5 brd ff:ff:ff:ff:ff:ff
--
14: bond0.1825@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 30:b9:30:00:11:b5 brd ff:ff:ff:ff:ff:ff
--
15: bond0.2095@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 30:b9:30:00:11:b5 brd ff:ff:ff:ff:ff:ff
--
50: br-managenet: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether 30:b9:30:00:11:b5 brd ff:ff:ff:ff:ff:ff
[root@node04 ~]# ip a | grep -i -B 1 -E "BC:22:47:B5:8B:3|30:B9:30:00:11:B5|30:B9:30:00:11:ED"
16: ens3f0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
link/ether bc:22:47:b5:8b:3e brd ff:ff:ff:ff:ff:ff
17: ens3f1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
link/ether bc:22:47:b5:8b:3e brd ff:ff:ff:ff:ff:ff
18: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether bc:22:47:b5:8b:3e brd ff:ff:ff:ff:ff:ff
--
21: bond0.1825@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether bc:22:47:b5:8b:3e brd ff:ff:ff:ff:ff:ff
--
22: bond0.2095@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether bc:22:47:b5:8b:3e brd ff:ff:ff:ff:ff:ff
如果强制删除了 kube-vip，那么 如下 kube-vip 的 lb svc 将残留
[root@node01 ~]# k get svc -A -o wide | grep 192.251.137.40
ingress-apisix apisix-gateway LoadBalancer 10.233.56.79 192.251.137.40 80:32222/TCP 21d app.kubernetes.io/instance=apisix,app.kubernetes.io/name=apisix
ingress-apisix apisix-ingress-controller-apisix-gateway LoadBalancer 10.233.29.232 192.251.137.40 80:31056/TCP,443:30229/TCP 21d app.kubernetes.io/instance=apisix,app.kubernetes.io/name=ingress-controller
monitoring cmss-ekiplus-prometheus-loadbalancer LoadBalancer 10.233.13.143 192.251.137.40 9090:32391/TCP 38d app.kubernetes.io/name=prometheus,prometheus=cmss-ekiplus-prometheus
所以只能强制删除, 手动把 finalizer 移除。 强制删除后，192.251.137.40 便从 ipvs0 上移除了。 当 ip 不在 node 本地，arp 代答也不会发生。
参考：
kube-proxy ipvs-strict-arp 是 Kubernetes 中的一个选项，用于控制 kube-proxy 如何将流量代理到后端服务。当该选项设置为 "true" 时，kube-proxy 将严格检查 ARP 表，仅当该表中存在对应的条目时才将流量代理到该地址。当该选项设置为 "false" 时，kube-proxy 将不检查 ARP 表，而是直接将流量代理到该地址。
