Optionally use the pod IP to connect to un-intercepted workloads.

[jmalloc]

Please describe your use case / problem.

I am trying to work around a 502 Bad Gateway issue that occurs when accessing our application(s) after terminating an intercept. The 502 occurs because the agent is attempting to forward to our container on 127.0.0.1, but our app is bound to the pod's IP address in the 10.x range.

Describe the solution you'd like

An option to proxy via the pod IP, which is already known to the traffic-agent, instead of the loopback interface.

I'm inclined to suggest this should be the default, as the container would have to bind to the pod IP to be accessible under normal circumstances, but understand that would likely break things for others somewhere.

By preference such an option would be configured globally as opposed to per-pod. Perhaps rather than (or in addition to) an explicit option for this behaviour, the agent could auto-detect the best approach.

Describe alternatives you've considered

As far as workarounds:

1. We have changed some of our applications to bind to 0.0.0.0, such that they accept requests on both the pod IP and the loopback interface. This is mostly OK, but is the first instance we've had to change our applications specifically to work with Telepresence.

2. Where 1. is problematic or difficult, we manually uninstall the agent after terminating the intercept. The biggest downside to this, other than the the fact that its manual is that it adds an appreciable delay each time the pod is intercepted again.

Versions (please complete the following information)

❯ telepresence version
Client         : v2.18.0
Root Daemon    : v2.18.0
User Daemon    : v2.18.0
Traffic Manager: v2.18.1

❯ kubectl version
Client Version: v1.29.0
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.4-eks-8cb36c9

Additional context

The cause of this 502 took us some time to diagnose as the only error message we were seeing from the traffic agent (after enabling debug logging, IIRC) was delayed connect error: 111. I realise now that this message is from Envoy, but that wasn't obvious to me at the time. I'm not sure if there's anything Telepresence can do to improve this, but thought it was worth mentioning just in case.