kube-vip 的 cp/svc 双选举，与 keepalived+haproxy、MetalLB 的对比
背景 homelab 的 K8s 集群用同一个 kube-vip DaemonSet 同时做两件事： cp_enable: "true" —— 维护 API Server 的高可用 VIP，kubectl/kubeconfig 都走这个地址 svc_enable: "true" —— 维护 Kong LoadBalancer Service 的入口 VIP，Ingress 流量走这个地址 两者目前共用同一个地址 192.168.50.100（详见 Homelab 拓扑）。最近一次 kube-vip 版本升级（v0.8.0 → v1.2.3）和一次 control-plane 节点重启，都观察到同一个 IP 同时出现在两台 control-plane 节点上的"双挂"现象。排查过程中把 kube-vip 这套机制，跟另外两个常见的同类方案——keepalived+haproxy、MetalLB——梳理对比了一下，记在这里。 kube-vip 在这里做的是两件不相关的事 kube-vip 内部为 cp 和 svc 各维护一把完全独立的 K8s Lease，靠 leader election 选出 winner，winner 在本机网卡上做 ARP 广播占用 VIP： Lease 选的是谁 对应哪个开关 plndr-cp-lock 谁提供 API Server（:6443） cp_enable plndr-svcs-lock 谁提供 Kong 的 LoadBalancer Service 入口（:80/:443） svc_enable 两把锁互不知道对方存在，也不能互相替代——关掉其中一个，另一个照常运行，只是对应的能力消失（比如关掉 svc_enable，Kong 就没有 VIP 了，得换 NodePort 之类的方式暴露）。 ...