Can we extend external-dns.alpha.kubernetes.io/ingress features to Kubernetes Gateway API?

[wiceywkus]

trafficstars

What would you like to be added: To the Kubernetes Gateway support, please add the same/similar Istio-style support for cross referencing external LBs, like AWS ALBs, via a specific Ingress resource in the same or different Namespace. I.e. please copy the functionality attached to the Annotation: external-dns.alpha.kubernetes.io/ingress that is used with Istio to Gateway.

Why is this needed: As folks begin to adopt the Kubernetes Gateway API resources to setup their service meshes, there will still be cases of using externally managed load balancers:

1. Manual Deployment - https://istio.io/latest/docs/tasks/traffic-management/ingress/gateway-api/#manual-deployment Folks will still want to create and manage external load balancers, which are not created from the Service resources and not managed by the mesh Controller. For example, with AWS ALB, they can integrate web application firewall (WAF) functionality, which cannot be done with the NLB created from the Service resource.
2. Gateway with Service type ClusterIP - https://istio.io/latest/docs/tasks/traffic-management/ingress/gateway-api/#automated-deployment There is also the supported use case with the Istio implementation where one could direct the Controller to create a Service of type ClusterIP for the Kubernetes Gateway. This implies that any public path to the Gateway would be via an external resource. When implemented, the assigned hostname is the internal name of the service, e.g. myclusteripservice.mynamespace.svc.cluster.local. This name is incorrect for any public DNS records. In both cases, the implementer needs the ability to tell External DNS where to find the public hostname or public IP address to use. The functionality implemented for Istio is right on the mark, expecially with the Event Listener wired up against the Ingress for changes!

[frank-bee]

We use AWS ALB and having this issue. Any news regarding this feature?

[k8s-triage-robot]

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

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

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[k8s-triage-robot]

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:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[k8s-triage-robot]

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

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

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-sigs/prow repository.

[abursavich]

Support was added for external-dns.alpha.kubernetes.io/target in Gateway API Gateways.

It's not exactly what you're asking for, but it might be sufficient.

[remicode]

@abursavich the annotation external-dns.alpha.kubernetes.io/target is a static reference and doesn't allow for dynamically getting the ip/dns name like the external-dns.alpha.kubernetes.io/ingress does.

Looking at the istio-gateway source implementation it seems 2 changes would need to be added to the kubernetes gateway source implementation

Add this function targetsFromIngress https://github.com/kubernetes-sigs/external-dns/blob/1b5c9d3d3bd2b50020839866645746c4f7ddad62/source/istio_gateway.go#L245 and this annotation reference along with the GatewaySource struct referenced below https://github.com/kubernetes-sigs/external-dns/blob/1b5c9d3d3bd2b50020839866645746c4f7ddad62/source/istio_gateway.go#L43