Watch multiple gloo namespaces for domains

[esalter]

What would you like to be added:

This previous PR (#1693) added support for gloo-proxy as a source, and works great. However, it only watches a single namespace for domains. It would be great if it could watch multiple namespaces.

Why is this needed:

Gloo has support for being installed in multiple namespaces: https://docs.solo.io/gloo-edge/latest/installation/advanced_configuration/multiple-gloo-installs/. This supports various scenarios like multi-tenant setups, and in our case we're using it for CI. This works great too, but unfortunately due to being in a separate namespace, external-dns doesn't see any resources here, so as part of the CI build we have to manually add a DNS record.

Adding the ability to watch multiple namespaces would help a lot. It would be even better if the watch could include a wildcard, so you could do things like:

        args:
        - --source=gloo-proxy
        - --gloo-namespace=custom-gloo-system
        - --gloo-namespace=gloo-review-*
        - --provider=aws
        - --registry=txt
        - --txt-owner-id=my-identifier

With this setup, as long as we install gloo to either the custom-gloo-system namespace, or ANY namespace with a gloo-review- prefix, external-dns would see domains and act accordingly.

Of course, the default setup of watching just gloo-system would work perfectly fine. For backwards compatibility you would keep the gloo-namespace name, it just becomes an array rather than a string.

[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

[megum1n]

/remove-lifecycle rotten

[szuecs]

/priority backlog