Loadbalancer

背景 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 之类的方式暴露）。 ...

背景 homelab 的 K8s 集群用 kube-vip 把 VIP 192.168.50.100 绑在某一台 control-plane 节点上，Kong 通过 LoadBalancer Service 占用了这个 VIP 的 443 端口对外提供 HTTPS。 最近想在集群里自建一个 Git 服务（Forgejo），它需要 SSH 端口供 git clone 使用。一个想法是：再建一个 LoadBalancer Service，把 VIP 的 22 端口转发给 Forgejo 的内建 SSH。 但这里有个让人犹豫的问题： VIP 是绑在某台宿主机上的，而那台宿主机自己的 sshd 也监听着 22 端口。那么发往 192.168.50.100:22 的流量，到底会进 Forgejo，还是会被宿主机的 sshd 接走？ 先做个小实验 在集群上分三步验证，探测 192.168.50.100:22 返回的是什么。 第一步，不创建任何 22 端口的 LoadBalancer Service，直接探测 VIP 的 22 端口： nc -w 2 192.168.50.100 22 # SSH-2.0-OpenSSH_10.3 ← 落到了宿主机的 sshd 第二步，建一个 LoadBalancer Service，把 VIP 的 22 端口指向一个普通的 HTTP 测试 Pod： ...