You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
The text was updated successfully, but these errors were encountered:
@jmalloc this is now fixed in the OSS version of the traffic-agent, and the fix will be included in the next release. I opted to not make this new behavior configurable, because the implementation should work for all situations that I can think of, and actually fix some that didn't work in the past.
If you'd like to give it a spin, you can try using agent image ghcr.io/telepresenceio/tel2:2.20.0-test.11. One way of installing it is:
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. The502
occurs because the agent is attempting to forward to our container on127.0.0.1
, but our app is bound to the pod's IP address in the10.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:
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.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)
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) wasdelayed 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.The text was updated successfully, but these errors were encountered: