-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
Allow the DNS stack to be backward compatible with an old dns_domain #10630
Allow the DNS stack to be backward compatible with an old dns_domain #10630
Conversation
Hi @VannTen. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
0e658ea
to
9006476
Compare
/retest |
@VannTen: Cannot trigger testing until a trusted user reviews the PR and leaves an In response to this:
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. |
/ok-to-test |
/retest |
Looks like /retest does not work. Not sure if it's prow not picking it up or the CI in disarray. @floryut not sure if you can re-trigger it ? |
Handle all old dns domains: - for nodelocaldns: in the same server block as the current dns_domain - for coredns: uffix rewrite of each of the old dns domains to the current one
9006476
to
9ef25c4
Compare
By the way, I tried to use #10045 before doing this, but it does not work with nodelocaldns, because dns queries outside of the cluster dns_domain are routed to upstream nameservers, and so never reach Coredns to be rewritten (also, the rewrite_block is not actually the block, since you need to manually specifiy |
@cristicalin @liupeng0518 Any idea when you'll get a chance to look at this ? |
/cc @MrFreezeex @mzaian |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohh that's pretty nice, I think this use case come somewhat pretty often so 👍
/lgtm
@@ -49,6 +49,9 @@ data: | |||
{% if coredns_rewrite_block is defined %} | |||
{{ coredns_rewrite_block | indent(width=8, first=False) }} | |||
{% endif %} | |||
{% for old_dns_domain in old_dns_domains %} | |||
rewrite name suffix {{ old_dns_domain }} {{ dns_domain }} answer auto | |||
{% endfor %} | |||
ready | |||
kubernetes {{ dns_domain }} {% if coredns_kubernetes_extra_domains is defined %}{{ coredns_kubernetes_extra_domains }} {% endif %}{% if enable_coredns_reverse_dns_lookups %}in-addr.arpa ip6.arpa {% endif %}{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hum.
Looking at that just now I wonder if I should instead extend coredns_kubernetes_extra_domains
(I don't think that setting can work currently since nodelocaldns won't forward it to coredns)
Thanks @VannTen |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: MrFreezeex, VannTen, yankay The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
…ubernetes-sigs#10630) Handle all old dns domains: - for nodelocaldns: in the same server block as the current dns_domain - for coredns: uffix rewrite of each of the old dns domains to the current one
What type of PR is this?
/kind feature
What this PR does / why we need it:
All domains in
old_dns_domains
are handled by nodelocaldns in the same server blockas the current dns_domain, while coredns performs a suffix rewrite of
each of the old dns domains to the current one.
This facilitates changing your dns_domain, for whatever reason, especially if some of your users/workloads embed the cluster dns_domain in their config.
(they should'nt, but they will)
Does this PR introduce a user-facing change?: