Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
ytsarev opened this issue Jul 10, 2022 · 6 comments
Milestone

Comments

@ytsarev
Copy link
Member

ytsarev commented Jul 10, 2022

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

@somaritane
Copy link
Contributor

somaritane commented Jul 11, 2022

@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
Copy link
Contributor

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
Copy link
Member Author

ytsarev commented Jul 11, 2022

@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)

@somaritane somaritane added this to the 1.1 milestone Oct 9, 2022
@ewassef
Copy link

ewassef commented Jan 31, 2023

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
Copy link
Member Author

ytsarev commented Jan 31, 2023

@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
Copy link
Member Author

ytsarev commented Jul 20, 2024

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

@ytsarev ytsarev closed this as completed Jul 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

No branches or pull requests

3 participants