in data panel, this is the traffic end in xds, traffic redirect to 127.0.0.1:some-port
but in some case, user process listen to a specific pod ip, like 172.18.2.139, result to traffic failure.
this case may because of some security consideration, in some old project.
is there any thing to do to make this case work?
I think it would be technically feasible to have Envoy forward to the pod IP rather than localhost. I don’t see any security issues with that approach, but may want to think about it a bit more. The iptables rules already exempt the Envoy UID from redirection, so that should be fine.
WDPT about making that the default? I can’t see any downside, since pods will generally listen on 0.0.0.0, or run some auto-discovery code and listen on the pod ip. They probably won’t listen on 127.0.0.1, unless they really don’t want external traffic, in which case it’s fine that we won’t forward.
notice there is a listener in xds: pod_id:port. traffic is from this listener.
so if instead of “127.0.0.1”, xds redirect traffic to pod_id:port.
this traffic may be an infinite loop?
or the xds cluster “socket_address” will not try to find listener again, and try redirect to local socket address. if this is true, I do think xds should use pod id, instead of 127.0.0.1.
correct me please.
I think that XDS listener on pod_ip:port is a “non-binding” listener, meaning that it doesn’t cause Envoy to actually open a TCP socket on the OS. Instead, traffic is redirected from other Envoy listeners to it—it’s all internal to Envoy. The long and short of it is that I don’t believe this will cause a traffic redirection loop.
