search

kubernetes-sigs / gateway-api

Repository for the next iteration of composite service (e.g. Ingress) and load balancing APIs.
https://gateway-api.sigs.k8s.io
Apache License 2.0
1.86k stars 482 forks source link

GEP: Enable egress use case for the Gateway API #1856

Closed vinod4linux closed 5 months ago

vinod4linux commented 1 year ago

Kubernetes does not have a standard way of dealing with egress traffic - i.e. traffic originating in a cluster with a destination outside the cluster. We want to create a standard way of handling this traffic using Gateway API.

Details of this use case are specified in the document below: https://docs.google.com/document/d/13xAF_pqH2bV8x4MfXWde47esCdVwow1-nig6iy_rafA/edit?usp=sharing

quangnguyen101 commented 1 year ago

Thank you for opening this issue @vinod4linux.

shaneutt commented 1 year ago

Thanks @vinod4linux! Glad to see the continued interest in the egress topic. I think the next best step would be for someone to take this on and create an initial GEP that covers the high level "what" and "why" topics, so that we can iteratively progress towards the desired implementation. It seems most likely that we can just start that GEP using the content already provided in the google doc and take some small steps to raise awareness and build alignment with the community.

/help

k8s-ci-robot commented 1 year ago

@shaneutt: This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed by commenting with the /remove-help command.

In response to [this](https://github.com/kubernetes-sigs/gateway-api/issues/1856): >Thanks @vinod4linux! Glad to see the continued interest in the egress topic. I think the next best step would be for someone to take this on and create an initial GEP that covers the high level "what" and "why" topics, so that we can iteratively progress towards the desired implementation. It seems most likely that we can just start that GEP using the content already provided in the google doc and take some small steps to raise awareness and build alignment with the community. > >/help Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
shaneutt commented 1 year ago

Talked about this in the community meeting, there's active work from Philip Klatte's team starting on this:

/assign @vinod4linux

k8s-triage-robot commented 1 year ago

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot commented 1 year ago

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

shaneutt commented 5 months ago

As per the PR it unfortunately seems we've been unable to move forward on this, largely because we don't have multiple aligned implementations coming together that need it, but also because the problem domain has felt a bit out of scope for what Gateway API itself is trying to do.

We're going to close this for now, but we're always open to the suggestions to re-open it just let us know here if you think we should, what your thoughts are, and your plan for how we move this forward.