danopia
commented
3 years ago So this is a bit of an open question because external-dns doesn't have multiple provider support (that I'm aware of). I added very basic support, where every single endpoint that gets pulled in by a source is equally eligible to be exported to each configured provider. I currently only offer annotation filters at the source level.
As far as adding multiple providers, I actually have an example, which includes zone filters to be a bit more explicit: https://github.com/cloudydeno/kubernetes-dns-sync/blob/6fb5d81c32a535a75c43037752d084f722841c76/examples/complex.toml#L14-L20
In your example, configuring both providers today would result in iot.home.example.org getting created in both providers, given that the parent zones already exist in both. I have a similar zone layout & I personally run two copies of this program, with different annotation-filters on each instance. So one instance acts as an internet instance and the other as a vpn instance. This works because these instances have different source and provider configurations.
I'm open to ideas on how to solve this with a single instance, but I also have some of my own:
-
Allow for further annotation filtering at the
providerside.- I believe this is your suggestion.
- Downside: all sources used must have the same annotation, e.g. your nodes must have your ingress-class annotation to use the
nodesource in this configuration. This solution wouldn't be applicable to my current usage.
-
Automatically recognize nested zones and prevent matching records from being presented to a less-specific zone.
- In your example, with home.example.org and example.org as two zones, any record under home.example.org would only be presented to the zones named home.example.org. Other records are unaffected
- Downside: doesn't allow having two different versions of the same zone managed by a single kubernetes-dns-sync instance
-
Optionally allow a
sourcedefinition to include a "context" of sorts, which places the endpoints into a non-default list which only aproviderdefinition with a matching "context" will pick up. So you'd have two different source blocks with your different annotation filters.- Downside: repetitive source blocks, probably error-prone to configure
-
Maybe some sort of zone or provider priority thing, so that records are only given to the highest-priority zones that somehow match them. This is like a non-automatic version of idea 2.
- I can't really imagine when this solution would be more useful than the other.
-
Allow for blocking a particular list of names from being managed by a provider, including child names. In your example, this would involve adding home.example.org to the block list for the Cloudflare provider. This can be forgotten easily but I feel it could be quite robust, as the providers don't need to interact to provide this feature.
samip5
Please document how to utilize your application with multiple providers.
I would like to do the following:
home.example.org => PowerDNS, if annotation filter allows example.org => Cloudflare, if annotation filter allows
Similar how you can in external-dns do public=true annotations and only then push it to Cloudflare.