For traffic that comes in to a node that doesn't have a traefik replica running, serviceLB (I'm assuming) routes the traffic to one of the nodes that is running traefik. But the packet that traefik sees has the pod IP of the serviceLB pod as the source, and not the original source IP. This limits the matching space to the ephemeral ports that serviceLB will choose for routing traffic. This is a lot, but it's a lot less than letting the source IP vary. I worry that it is fragile and that something will break, or that it will fail to load balance correctly because two connections that come in from different IPs but happen to use the same port will be forced to use the same backend replica. For IPv6, serviceLB could just allocate a block of pod IPs and then hash the incoming source IP/port pair to determine the outgoing pod IP/port. This could easily be large enough that you were unlikely to run into problems. For IPv4, the range of pod IPs is small enough that you wouldn't want serviceLB to allocate a large block of them. I'm not sure there is a solution that will do what I want. In order for traefik to reply correctly, it has to know where to send the response packet. If the incoming connection originated on a different node, the response has to be sent there first so that it can be rewritten going the other direction. Maybe the solution is to take traefik out of the loop entirely? Does serviceLB have configurable sourceIP/sourcePort to backend affinity with a timeout? If not, is there another LB that does, where I can replace serviceLB with that LB?

There is extensive information available on this. Search for "traefik source address" in k3s issues and discussions on GH.

I just realized that I have what I need. the source address is from another node only if the connection comes in from a node where traefik isn't running. But that won't be the regular case.

external-dns

only pushes up the node ips where the service is running, and as long as someone connects to one of those, I'm fine. It would only be if one of the traefik pods migrated nodes, during the window before

external-dns

caught the change and it propagated through the dns cache that traffic would be sent to a node where traefik was running. Thank you.

correct!