External-dns: Feature Request: Istio VirtualServices

[bradenwright]

Currently I am able to sync DNS records from Istio Gateways which is great, much appreciated!

It would be great if External DNS could sync hostnames from VirtualServices too though. It would make the organization for me better. Let me explain via example:

Currently I have a common chart to deploy istio gateways, and a few other istio related things. This chart is called my-istio-common, I have VirtualServices setup in my Services / Application charts e.g. my-service-a, my-service-b.

I'm currently doing routing in my-service-a, my-service-b by authority / hostname, and the hostname is specific to the service. So it ends up that I need to update my-istio-common to get the dns record to sync and then setup everything else hostname related in my-service-a, my-service-b. I'd rather only but service related hostname on VirtualService and just have a wildcard on the Gateway. It would keep things a lot cleaner, and follow the Kubernetes pattern(s) better.

[vinixaavier]

+1

Kiali Console show warning message: More than one Gateway for the same host port combination - because im controlling DNS records with resource Gateway and not VirtualService.

[w32-blaster]

There is a known issue in istio which doesn't allow having multiple gateways pointing to the same domain but using different certificates. Because of that limitation, when using multiple domains, private and public gateways, the only option is to have a global gateway per domain and use wildcard on that domain (*.example.com).
Additional complexity is when the domain is used to host other services (not routed to k8s and istio). For example:
service1.example.com, service2.example.com is going to the ingressgateay
service3.example.com is going to somewhere else.
In this case we can't set wildcard on our DNS using external-dns and because external-dns knows about the Gateway resources only we can't manage those DNS entries via external-dns.

An option would be to use virtualservice to determine the required DNS entry/entries instead of using the gateway(s).

[edsonmarquezani]

I'm currently unable to use external-dns because I set one VirtualService per application, not a gateway (which is a single one for all). This feature would be much appreciated.

[bradenwright]

I've also run into a situation where on deploy of the chart we need to chart a dynamic record and extra level up so doing so via Gateway is ugly, I'll explain via example.

We currently deploy versions of myapp, lets say to prod.example.com, this work fine with gateways b/c we use a wildcard so *.prod.example.com resolves. So when I deploy different versions: v1-myapp.prod.example.com, v2-myapp.prod.example.com both resolve, but I actually also need to create *.v1-myapp.prod.example.com and *.v2-myapp.prod.example.com these records get created in prod.example.com dns zone. This is currently working great with using Service type Load Balancer.

But with Istio the Gateway is shared so it lives in an istio chart, where the application lives in myapp chart. B/c the name v1-myapp isn't known when istio chart is deployed this gets ugly. If I wanted to fix I would need to deploy the istio chart everytime I deploy the service, further that chart would have to get the output of all the current hosts (creating dns entries for) and then append the host to it. This would be super ugly. Support for VirtualServices would solve this issue and allow me to use Istio over Service LB

[olusinae]

I am currently working on this feature to have external-dns resolving hostnames from Istio virtualservice, which has been set up as one VirtualService per application.

I would like to know if anyone else is already looking into this. Cheers

[MarcMielke]

@olusinae not looking into this but very much needing this functionality - glad to see it's being worked on!

[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

[nesl247]

/remove-lifecycle stale

[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.