apiserver-network-proxy
apiserver-network-proxy copied to clipboard
kubernetes-sigs
Proxy server should load-balance connection requests to all available agents.
Currently the proxy server will send all connection requests to a single agent. While all requests for an established connection should go through the same agent on which it was established, connection requests should be balanced across available agents.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
While all requests for an established connection should go through the same agent
I'm not sure if this is true. It seems that the proxy server always sends traffic to the last agent that establishes connection (see here). If the KAS is making a long running request, and there is a new agent establishes the connection, proxy server will switch to that new agent.
Also, sticking to the last connected agent makes that agent a bottleneck, which can be problematic in a large cluster.
Also, the proxy server won't fallback to other agents if the last connected agent fails, that also seems problematic.
While all requests for an established connection should go through the same agent
I'm not sure if this is true. It seems that the proxy server always sends traffic to the last agent that establishes connection (see here). If the KAS is making a long running request, and there is a new agent establishes the connection, proxy server will switch to that new agent.
Also, sticking to the last connected agent makes that agent a bottleneck, which can be problematic in a large cluster.
Also, the proxy server won't fallback to other agents if the last connected agent fails, that also seems problematic.
all true. I am in the middle of implementing this support, but got distracted on other priorities. I am gonna find some time picking this up in the following couple of weeks. Thanks @caesarxuchao to bring this back to my attention.
