Support Gloo VirtualService as an Endpoint Source

[ilackarms]

What would you like to be added:

Support Gloo VirtualService objects as a source of Endpoints for creating DNS records.

Why is this needed:

Because Gloo is great! And automatic DNS provisioning is something our users are requesting.

[Raffo]

I think that for custom CRDs, the same reasoning made in #1403 (comment) applies. It would be great to have a pluggable way or any other proposal to make CRDs used as sources be pluggable.

[ilackarms]

@Raffo how do you propose these CRDs be made pluggable? From reading the Contour and Istio code, it seems that there's a bit of domain-specific knowledge in each implementation.

[szuecs]

I tried to summarize the issue raised by @Raffo in #1447 and added my opinion on that, too.

[Raffo]

@ilackarms I think we can totally discuss this issue in #1447 by @szuecs .

[gigi-at-zymergen]

We are using Gloo in EKS, and I think we might be able to use the CRD source as documented at https://github.com/kubernetes-sigs/external-dns/blob/master/docs/contributing/crd-source.md .

I can certainly apply the dnsendpoints.externaldns.k8s.io CRD manifest and adjust our external-dns RBAC and source, but am a little unclear on how we might supply aws provider specific information like indicating we want an alias Route53 record pointed at a service NLB.

We have a gateway-proxy k8s LoadBalancer service pointing at Gloo, which is an AWS NLB. We would like to specify Route53 A record aliases pointing at the service NLB. I was thinking we could use the spec.endpoints.providerSpecific field on the endpoint manifest to indicate an alias record, but currently not clear on what that would look like. Any guidance ?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[seanmalloy]

/remove-lifecycle stale

[bradenwright]

Any update on this. @gigi-at-zymergen were you able to get anything to work. Curious b/c right now this is the only thing having me use Istio gateways over trying Gloo virtualservices. I'd be down for a work around or do I need to be patient and wait for #1558 to be resolved

[gigi-at-zymergen]

@bradenwright we did end up getting the CRD source to work.

• Created the external-dns dnsendpoints.externaldns.k8s.io CRD in our cluster
• Updated our external-dns container with the --source=crd arg
• Wrote a utility that generates external-dns dnsendpoint resources for us and we auto apply them with Flux

An example of dnsendpoint yaml spec we generate looks like the following:

apiVersion: externaldns.k8s.io/v1alpha1
kind: DNSEndpoint
metadata:
  name: zowie
  labels:
    environment: development
  namespace: tools
spec:
  endpoints:
  - dnsName: zowie.mydomain.com
    recordTTL: 60
    recordType: CNAME
    providerSpecific:
    - name: alias
      value: "true"
    targets:
    - *****************.elb.us-west-2.amazonaws.com

The target is the AWS NLB associated with our gateway-proxy service. The thing that threw me for a bit of a loop initially was that even though it says recordType: CNAME, it creates an A record alias.

[mrballcb]

I wonder if that's because you're setting alias=true in the providerSpecific section. Does it behave differently if you set the recordType to A instead of CNAME? Does it behave differently if you don't set the alias=true setting?

[gigi-at-zymergen]

recordType = "A" failed validation with a string target. It expects an IP.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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.