This message was deleted.

We don't use harvester, but our approach was to use kube-vip chart in each deployed cluster, configuring a static IP into kube-vip at deployment time using Rancher cluster templates (RKE2 feature). Kube-vip then picks a node to being ARPing that IP address (or you can use BGP) and our DNS gives that static IP a name. Now anytime someone is talking to dev.cluster.example.com it looks up the DNS and talks to the static IP and that goes to whichever node is the leader right now. And then kube-proxy routes that request internal to the cluster to its final destination. Now if a node crashes or a new node is added to the cluster, kube-vip will adjust the pool of nodes available for the static IP addr. We also looked at metallb which does similar but metallb does not support pings and you have to setup up ipvs to get pings. Our datacenter requires pings for dynamic node IP addrs or it will recycle that IP addr assuming it is dead. kube-vip also has a service load-balancer we haven't used yet, to give each service a different node IP addr to spread out external traffic across nodes.

Thanks, I'll take a look at that