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

Make listener can expose >1 ports #1765

Open
izturn opened this issue Mar 2, 2023 · 3 comments
Open

Make listener can expose >1 ports #1765

izturn opened this issue Mar 2, 2023 · 3 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. priority/backlog Higher priority than priority/awaiting-more-evidence. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@izturn
Copy link

izturn commented Mar 2, 2023

What would you like to be added:
The Gateway Listener only gives us one port to specify, there is no way to set the specific node port for the service type: LoadBalancer instead of generate it by random, I hope there is a method to accomplish it

We had talked about it in the project contour, but maybe here is the right place.

xref: projectcontour/contour#5072

Why this is needed:

@izturn izturn added the kind/feature Categorizes issue or PR as related to a new feature. label Mar 2, 2023
@shaneutt
Copy link
Member

shaneutt commented Mar 2, 2023

Hi @izturn, thanks for your request! 👋

I understand that fundamentally what you'd like to be able to do is have a field on Gateway listeners to explicitly declare a port that will then be used as the NodePort in the underlying Service type LoadBalancer that your implementation is creating, correct?

It's important to note that while Service type LoadBalancer is in use "under the hood" in several Gateway API implementations, there is no explicit relationship between Gateway and Service and nor is there any relevant requirements. Some implementations of Gateway API today do not use the Service API. So the Gateway listener may not be the right place to put such a thing, but we can certainly explore the problem you're trying to solve further and look for solutions.

I noticed in your initial issue that the Why this is needed field has been omitted. To find an optimal solution it could be helpful for us to better understand the underlying need. Could you please fill out this section with details about what problem(s) this solves, including example situations?

@shaneutt shaneutt added the priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. label Mar 2, 2023
@costinm
Copy link

costinm commented Mar 3, 2023

In Istio implementation - and the pattern can probably be used by any other implementation that does have associated Service objects - the user can create a Service with the same name as the Gateway, and the implementation will just use it ( or create one if it doesn't exist ). If I remember correctly - the selector will be patched or needs to have a specific value.

@shaneutt shaneutt added the triage/needs-information Indicates an issue needs more information in order to work on it. label Mar 10, 2023
@robscott
Copy link
Member

/priority backlog
/triage accepted

@k8s-ci-robot k8s-ci-robot added priority/backlog Higher priority than priority/awaiting-more-evidence. triage/accepted Indicates an issue or PR is ready to be actively worked on. labels Apr 10, 2023
@robscott robscott removed priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. triage/needs-information Indicates an issue needs more information in order to work on it. labels Apr 10, 2023
@shaneutt shaneutt added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Mar 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. priority/backlog Higher priority than priority/awaiting-more-evidence. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

No branches or pull requests

5 participants