Support multiple edgeDNS types in parallel to enable hybrid and multi-cloud scenarios

[ytsarev]

Problem statement

Currently, k8gb is limited to work only with a single specific edgeDNS type and tested to work exclusively in a single DNS environment.
It limits the ability of operating in a hybrid scenario, e.g.

• deploying k8gb in parallel to on-prem clusters with Infoblox and to AWS with Route53 as edgeDNS and orchestrating DNS zone delegation to k8gb instances between cloud and on-prem
• deploying k8gb in parallel to multiple clouds like AWS/Azure/GCP and orchestrating DNS zone delegation to k8gb instances between multiple clouds

Possible solution

• Enable multiple edgeDNStypes handling
• Test it in hybrid/multiple cloud scenario
• We already have some configuration logic semantically prepared to handle this case https://github.com/k8gb-io/k8gb/blame/master/controllers/depresolver/depresolver.go#L75

[somaritane]

@ytsarev to my understanding, with one k8gb instance, deployed to environment A and configured to use that environment-specific EdgeDNS (e.g. AWS and Route53), and then another k8gb instance deployed on environment B with specific EdgeDNS (e.g. on-prem with Infoblox) - we got this scenario covered.

[somaritane]

Or did you mean some complex scenario, when for example we have workloads exposed with different zones in the cluster that need to be resolved using different EdgeDNS providers?

[ytsarev]

@somaritane was thinking about it more and it can actually take many forms. Let's treat on-prem as just another cloud environment for simplicity. In case when k8gb deployed to two clouds. We can have many cases

• One edgeDNS(e.g. route53 only) is actively resolving application gslb fqdn, regardless of workload location. Then we got it already covered, correct?
• gslb fqdn is getting resolved in parallel by multiple edgeDNS, e.g. Route53 in cloud and infoblox on-prem. That's a very special setup, where DNS resolution path within this environment is strongly isolated. I am not sure if it is even a valid one.
• k8gb is configured with multiple edgeDNS providers and only one of them is active at the moment for resolution, still both of them are getting updated in parallel. Use case? Possible global failover even on edgeDNS level (e.g. Route53 has issues, we can switch to Azure DNS or vice versa)

[ewassef]

How about having multiple HostedZones ( Route53 example) and allowing K8GB to manage those? It seems like only a single host can be configured in the operator at a time
For example, ExternalDNS will watch all zones if we exclude this filter: https://github.com/k8gb-io/k8gb/blob/master/chart/k8gb/templates/external-dns/external-dns.yaml#L25

[ytsarev]

@ewassef good point, we can both relax the filter to handle multiple zones and also orchestrate multiple external-dns instances to handle multiple DNS environments/clouds in parallel

[ytsarev]

stale, we manage a single edge DNS zone, meanwhile workloads can be placed in a multi-cloud manner. Closing.