Skip to content
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

Load Balancing with network redirect #15057

Closed
bmsan opened this issue Feb 16, 2021 · 7 comments
Closed

Load Balancing with network redirect #15057

bmsan opened this issue Feb 16, 2021 · 7 comments
Labels
question Questions that are neither investigations, bugs, nor enhancements stale stalebot believes this issue/PR has not been touched recently

Comments

@bmsan
Copy link

bmsan commented Feb 16, 2021

Title: Configuring Load Balancing with network redirect

Description:

Is there a way to configure envoy to load balance by redirecting to one of the backends?
The traffic would then go directly between user <--> backend_X (backend_X was selected by envoy for redirection), without all the network traffic passing through envoy.
Usecase : Scenarios of high throughput data traffic where the machine where envoy is hosted would become a bottleneck if all the traffic would pass through it.

In nginx there is ngx_http_split_clients_module

split_clients "${remote_addr}" $destination {
  40%   server1:port1;
  30%   server2:port2
  20%   server3:port3;
  10%   server4:port4
}

server {
  listen       myport;
  location /  {
    return 302 http://$destination$request_uri;
  } 
}
@bmsan bmsan added the triage Issue requires triage label Feb 16, 2021
@lambdai
Copy link
Contributor

lambdai commented Feb 16, 2021

Can you clarify? This nginx config doesn't seem to bypass nginx. In theory, you cannot because "http request lb" and "bypass HTTP proxy" is contradicting. A L7 proxy cannot determine the http request/response boundary if the byte stream is not parsed by http proxy.

@bmsan
Copy link
Author

bmsan commented Feb 16, 2021

I will try to describe the behavoir I would like to obtain.
We have N identical servers, which should handle data from the users.
When an user contacts my_domain.com I would like the entity behind my_domain.com(could that be envoy?) to select one of the N servers and issue a redirect to the user (you contacted my_domain.com but you should contact serverK).
The user would get redirected and it would see serverK instead of my_domain.com in the address bar.
After the redirect the redirecting entity wouldn't be involved at all in the communication between the user and serverK.

@junr03 junr03 added question Questions that are neither investigations, bugs, nor enhancements and removed triage Issue requires triage labels Feb 16, 2021
@bmsan
Copy link
Author

bmsan commented Feb 16, 2021

One more thing to point out in my nginx example, the bypassing nginx and creating a direct connection user<-->backend is done by returning http code 302 which can be used for URL redirection

@mattklein123
Copy link
Member

We don't support anything like this today, though I suppose it could be relatively easily implemented with an HTTP upstream plugin that just returns a redirect? cc @alyssawilk

@lambdai
Copy link
Contributor

lambdai commented Feb 18, 2021

Aha, I misinterpreted the requirement. I thought you are asking for LVS on HTTP + DSR.

Looks like envoy acts as a dynamic content server. The future http upstream may cover this as Matt mentioned.

It's also possible to intercept the upstream request by a new cluster upstream extension. When your self-defined HttpConnPool is touched, a backend host is already selected by lb defined in cluster.
See the host info fetched by the HttpConnPool here. You HttpConnPool can respond 302 using the host info.

It's not a trivial approach though but this is the most reasonable one in my head

@github-actions
Copy link

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale stalebot believes this issue/PR has not been touched recently label Mar 20, 2021
@github-actions
Copy link

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Questions that are neither investigations, bugs, nor enhancements stale stalebot believes this issue/PR has not been touched recently
Projects
None yet
Development

No branches or pull requests

4 participants