-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Support of target annotations in gateway source #3749
Comments
My thoughts are that we should deprecate the If the workload deployer needs to specify the target, what's the advantage of having it be specified on the |
For clarification: It needs to be specified on
When setting up any Gateway API implementation, I think gateway source will be what users have a look first. Otherwise we would need to ask users to use CRD source and explicitly avoid the use of gateway source. This does not look straightforward personally. Also I would like to have controller take care of target override dynamically, instead of letting users specify a fixed endpoint spec. In this case adding annotation seems more straightforward than managing a new resource. |
Thank you for the additional information. For background, I am working on a proposal to promote some of the external-dns annotations to stable. The It would be helpful to me to have more details as to why If it is the workload deployer who is creating the If the Gateway controller is what is supplying the target, that is something that should be going into a |
While I didnt have the exact use-case as @solmonk in this issue. We did need to override the We ultimately did not settle on gateway but the general use-case for us was to use google external https load balancers as a TLS-terminating edge proxy and CDN, provisioned via terraform and point that to one or more internal clusters where we handle the actual routing with other ingress controllers(or in our case at the time, istio). We are still running a similar solution but not via gateway, but The ultimate reason is that googles ingress support essentially no features we needed/wanted, and very few ingress controllers or gateway api implementations support overriding the status address of ingress/gateways. |
In VPC Lattice each ingress endpoint of I would say Gateway API has enough |
Annotations, especially those that are expected to be written as controllers, are a code smell indicating that either the API is missing fields or that the controller is misapplying the API. Controllers should be writing to In this case, I suspect that VPC Lattice is misapplying the Gateway API. If there are two different ingress points, there should be two different If we were to support |
@BadLiveware thank you for describing the "extra proxy in front" use case; that was quite helpful. We will probably want to update the documentation of the annotation to describe that use case. |
Implemented in #3452 |
@johngmyers: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
What would you like to be added:
LIke other sources, it would be great if Gateway source also has
external-dns.alpha.kubernetes.io/target
annotation support.Why is this needed:
We are working on AWS Gateway API Controller which is a Gateway API implementation using AWS VPC Lattice. We would like to have ExternalDNS as a default way of user to configure customized domain names.
Currently Gateway source uses
gateway.Status.Addresses
as DNS record target for all hostnames. This is fine in most cases, but AWS Gateway API Controller does not have a centralized entrypoint for the Gateway - because it varies based on VPC, AZs, etc. To support those kind of different address behaviors, it would be great if DNS record targets are configurable at Route level.external-dns.alpha.kubernetes.io/target
annotation seems like the right way to support this use case, but this is not supported in Gateway source yet. Support of target annotation will give better flexibility to lots of Gateway API implementations.The text was updated successfully, but these errors were encountered: