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

Requests from inside a pod targeting an external LB IP address bypass the LB and go directly towards the service #4

Closed
timoreimann opened this issue Jul 11, 2019 · 5 comments
Labels
enhancement New feature or request

Comments

@timoreimann
Copy link
Contributor

Several users have expressed the need to have an internal pod reach reach out a service by running through an external load-balancer. Reasons for the extra routing step are to have the proxy handle TLS and/or Proxy Protocol in a consistent manner.

The reason for the described behavior is that kube-proxy explicitly implements a bypassing logic. There is already an upstream issue describing this as a problem for users.

A workaround is outlined in the originating CCM issue. The only other alternative is to have pods speak to the service natively, which often isn't desired.

We should look into ways to support external routing one way or another in DOKS.

@timoreimann timoreimann added the enhancement New feature or request label Jul 11, 2019
@timoreimann
Copy link
Contributor Author

timoreimann commented Jul 11, 2019

The issue has been brought forward in the SIG Networking meeting from 4. April 2019 (recording). It wasn't completely clear why the requested routing pattern isn't supported by default.

There was agreement in submitting a PR that changes the behavior and continue discussions based on that.

@timoreimann
Copy link
Contributor Author

timoreimann commented Jul 11, 2019

AWS manages to support this case by means of using ingress hostnames, which is something that we currently cannot do at DigitalOcean. (See also this comment.)

@timoreimann
Copy link
Contributor Author

If anyone is willing to work on a PR please let us know. Otherwise, someone at the DOKS team is going to try to work on that.

@timoreimann
Copy link
Contributor Author

/cc @jcodybaker

@timoreimann
Copy link
Contributor Author

Closing this one in favor of #8 that was transferred over from the CCM repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant