This is some musing on the concept of identity for a service within a clustered environment.
Generally when accessing a service within some runtime environment capable of hosting multiple things we have a means of identifying which service a client wishes to interact with, eg.:
IP aliases (L3)
Port forwarding (L4)
Server Name Indication (SNI) (L5 or 6)
HTTP headers for proxy routing (L7)
It's the layer 3 that I've been thinking on, as the lower in the stack you go the more exposed you are to the local routing topologies, IPAM, site configurations, etc. Should you want your cluster to extend across multiple L2 domains then it becomes substantially more involved as we need to start having potentially different IPs in any given L2 domain and DNS SRV records, BGP awareness, etc.
All that complexity preserves optionality however as you can still layer any of those other mechanisms on top of it.
One possible scheme is to lean on DHCP to furnish an address appropriate for the environment. However if we want to be able to have any predictability in address assignment (and often we do), we also need a stable way of identifying ourselves to the DHCP server.
My thought here is to use the extended client identifier with a subtly different interpretation than normal:
DUID - instead of this being a singular system, this is the ID of the cluster. Likely a cluster either has some unique identifier, whether a UUID from creation, a VIP to be addressed by, an FQDN backed by SRV records, et al. Any of those is suited to either be directly presented as a DUID or hashed into a suitable value.
IAID - instead of this being an interface in a system, make it the Service identifier using any of the same types of ID noted for DUID.
Taking this approach means we have a stable cluster and service identity, which in turn allow s a site admin to create a lease for a stable address by which a given cluster/service can be known. This decouples the specific address config from the cluster itself and puts it in the hands of the environment in which it is active.... which is very much a 12factor app approach.
It allows a cluster spanning L2s to ask in each domain what it should serve a Service as, potentially having a different IP in each yet without the cluster or service author needing to be aware of it or embed it in config during deployment. Instead the binding of a specific address is left as an exercise for the site administrator and not the cluster admin.