-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Connect sidecar proxy does not honor removal of upstream #10422
Comments
After the reconfig the upstream listener is listed as https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/operations/draining If you wait long enough do you see this envoy log on the downstream?
I locally reproduced the scenario and by the time I was executing the curl it didn't work anymore. It may have also been one of those fun connection pooling issues if you weren't explicitly switching the service to an L7 protocol. Connections would have been established when the now-draining listener was actively listening, but after the listening socket was destroyed if you were using a pooled long-lived connection from curl it wouldn't have re-dialed, instead preferring to use the established socket. If you set this config entry out of band before redoing your test scenario does the errant behavior still manifest?
|
Annnnnd it did start finally failing, after about 12 minutes
Feel free to close this out if that's working as intended, but this long of a lingering listener seems like a lot? |
The envoy default value is 10m: |
Awesome |
While working on hashicorp/nomad#10776 which fixes Nomad to update a Connect proxy's upstreams without restarting the proxy or parent task, I noticed this behavior where my tasks would still be able to make use of proxy upstreams even after updating the sidecar proxy to no longer have upstreams. Seems like the envoy should stop the listener when the upstream is removed. Not using ACLs or intentions.
$ consul version Consul v1.9.5 Protocol 2 spoken by default, understands 2 to 3 (agent will automatically use protocol >2 when speaking to compatible agents)
Checking our service registrations has upstream as expected
Connection working as expected
Modify client service to remove upstreams
Run modified job
Consul synced service
Checking upstream removed from service definition
Notice connections still working (!)
Exec into container, lets look around
config dump response
At this point I don't know what I'm looking at, but it seems like the envoy config is still holding on to my
destination
destination? LMK if I'm just holding it wrong.The text was updated successfully, but these errors were encountered: