-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Initial implementation of ForwardCRD plugin #4512
Initial implementation of ForwardCRD plugin #4512
Conversation
plugin/kubernetescrd/apis/coredns/v1alpha1/groupversion_info.go
Outdated
Show resolved
Hide resolved
53e9e14
to
855394a
Compare
very interesting idea. What the data model for the zone data? And how do you envision lookup taking weird DNS stuff into account, like wildcards and in-zone CNAMEs? You want to depend on |
Currently I'm thinking this would handle the very narrow case of forwarding dns messages to other dns servers based on the zone name (basically implementing stub-domains, but through crds). Not currently thinking of handling any individual records for a zone. I imagine handling requests at that point would be similar to how CoreDNS handles dns mux-ing now for server blocks. E.g there will be a map of zone names that map to forward plugins and we would loop through the map looking for a match, popping off subdomains of the zone until a match is found and we call that forward plugin's I can envision that this plugin can become more flexible, through additional crd(s). Not sure what this might look like yet, since there are probably a few ways to slice it so starting with a pretty limited crd. |
855394a
to
35f4471
Compare
35f4471
to
9af4761
Compare
9af4761
to
2806df8
Compare
I've updated the PR to include my initial implementation of the plugin. Apologies for what is now a massive PR, it felt like it made sense to continue iterating on the single PR, but let me know if you prefer breaking this down in any way. I did try and keep commits focused, which may help digest the PR. Would appreciate feedback, I imagine being new to this codebase there were design decisions I made that might not be the best approach for a given problem, so let me know if you spot ways this can be improved. One design decision that might be worth pointing out, I added a function to the forward plugin |
2806df8
to
2e96adc
Compare
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.
Thanks @christianang! Lots to digest, but from what I understand, it looks good so far.
// New returns a new Forward. | ||
func New() *Forward { | ||
f := &Forward{maxfails: 2, tlsConfig: new(tls.Config), expire: defaultExpire, p: new(random), from: ".", hcInterval: hcInterval, opts: options{forceTCP: false, preferUDP: false, hcRecursionDesired: true}} | ||
return f | ||
} | ||
|
||
// NewWithConfig returns a new Forward configured by the provided | ||
// ForwardConfig. | ||
func NewWithConfig(config ForwardConfig) (*Forward, error) { |
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.
I think I like this direction. I presume forward's existing Corefile parsing functions will also be refactored to create a ForwardConfig
, and then use NewWithConfig
to create the Forward
struct. This also opens the way for other plugins to reuse the "forwarding" function of the forward plugin (e.g. adding a forwarding action to coredns/policy).
@miekg, WDYT?
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.
@chrisohaver I love this idea and implemented a similar solution in #4583. Anyway config parsing logic should be separated from plugin logic according to the single-responsibility principle. It will not only decouple components but also allow to thoroughly cover the parsing functionality with tests.
4253808
to
ff56369
Compare
Co-authored-by: Aidan Obley <aobley@vmware.com> Signed-off-by: Christian Ang <angc@vmware.com>
- Place forwardcrd before forward plugin in plugin list. This will avoid forward from preventing the forwardcrd plugin from handling any queries in the case of having a default upstream forwarder in a server block (as is the case in the default kubernetes Corefile). Co-authored-by: Aidan Obley <aobley@vmware.com> Signed-off-by: Christian Ang <angc@vmware.com>
Signed-off-by: Christian Ang <angc@vmware.com>
- allows external packages to instanciate forward plugins Co-authored-by: Aidan Obley <aobley@vmware.com> Signed-off-by: Christian Ang <angc@vmware.com>
8ab82af
to
7dc40a0
Compare
- add a Kubernetes controller that can read Forward CRs - instances of the forward plugin are created based on Forward CRs from the Kubernetes controller - DNS requests are handled by calling matching Forward plugin instances based on zone name - Defaults to the kube-system namespace to align with Corefile RBAC Signed-off-by: Christian Ang <angc@vmware.com> Use klog v2 in forwardcrd plugin
Co-authored-by: Christian Ang <angc@vmware.com> Signed-off-by: Edwin Xie <exie@vmware.com>
- to ensure that the bitsize is 32 for later casting to uint32 Signed-off-by: Christian Ang <angc@vmware.com>
7dc40a0
to
58974b2
Compare
Hi, revisiting this PR since its been some time. @miekg do you think you can give this a review? I would appreciate it. |
@christianang, can you add this plugin and yourself as the owner, in the CODEOWNERS file? |
Signed-off-by: Christian Ang <angc@vmware.com>
Done! |
@miekg, is it OK with you if we merge this new plugin without your review, or would you like to review it first? |
[ Quoting ***@***.***> in "Re: [coredns/coredns] Initial imple..." ]
***@***.***, if it OK with you if we merge this new plugin without your review, or
would you like to review it first?
I don't have the time to thorougly review this. If I can find time for deeper coredns
reviews it would be focussed on some long standing PRs in the *file* plugin.
|
ok, wsn't expediting that,. Think this is perfectly fine as an external plugin. Never saw the use-case why this needs to be in coredns proper |
Sorry - I misinterpreted your response as an OK. I'll revert it. |
This reverts commit 2e6953c.
@christianang, sorry for the mixup. If you have time, please register the plugin as an external plugin on coredns.io ... |
Sorry - its been so long since I had looked at the code... quickly scanning it over, I remember now that this plugin required some refactoring of the forward plugin... so it cannot stand as-is as an external plugin unless we also create a new external plugin from a copy of the forward plugin with those modifications ... or we merge the mods to the forward plugin. |
Alternatives to consider, that (maybe) won't require changes to any existing plugins:
Of course (1) requires zero changes to CoreDNS. |
1 was originally suggested, but I had suggested a coredns plugin idea. Sorry folks! |
Sad to hear. I'll hit pause on making any attempts at this for now since (as @chrisohaver brought up), this does require a refactor to the forward plugin so it can be used by the newly introduced crd plugin so just making it an external plugin will take some effort. I am open to continuing discussion on the feature and how best to implement if someone wants to continue (perhaps it makes sense to reopen and continue on #4382?), but for now I'll put down the effort. |
* Add forwardcrd plugin README.md Co-authored-by: Aidan Obley <aobley@vmware.com> Signed-off-by: Christian Ang <angc@vmware.com> * Create forwardcrd plugin - Place forwardcrd before forward plugin in plugin list. This will avoid forward from preventing the forwardcrd plugin from handling any queries in the case of having a default upstream forwarder in a server block (as is the case in the default kubernetes Corefile). Co-authored-by: Aidan Obley <aobley@vmware.com> Signed-off-by: Christian Ang <angc@vmware.com> * Add Forward CRD Signed-off-by: Christian Ang <angc@vmware.com> * Add NewWithConfig to forward plugin - allows external packages to instanciate forward plugins Co-authored-by: Aidan Obley <aobley@vmware.com> Signed-off-by: Christian Ang <angc@vmware.com> * ForwardCRD plugin handles requests for Forward CRs - add a Kubernetes controller that can read Forward CRs - instances of the forward plugin are created based on Forward CRs from the Kubernetes controller - DNS requests are handled by calling matching Forward plugin instances based on zone name - Defaults to the kube-system namespace to align with Corefile RBAC Signed-off-by: Christian Ang <angc@vmware.com> Use klog v2 in forwardcrd plugin * Refactor forward setup to use NewWithConfig Co-authored-by: Christian Ang <angc@vmware.com> Signed-off-by: Edwin Xie <exie@vmware.com> * Use ParseInt instead of Atoi - to ensure that the bitsize is 32 for later casting to uint32 Signed-off-by: Christian Ang <angc@vmware.com> * Add @christianang to CODEOWNERS for forwardcrd Signed-off-by: Christian Ang <angc@vmware.com> Co-authored-by: Edwin Xie <exie@vmware.com> Signed-off-by: jinglinax@163.com <jinglinax@163.com>
…oredns#4981) This reverts commit 2e6953c. Signed-off-by: jinglinax@163.com <jinglinax@163.com>
1. Why is this pull request needed and what does it do?
This PR is the initial implementation of the KubernetesCRD plugin that sets out to implement #4382. Namely, it allows CoreDNS to watch a DNSZone CRD to configure stub-domains for Kubernetes clusters.
Edit: This PR has been updated from just the readme to the initial implementation of the plugin.
2. Which issues (if any) are related?
#4382
3. Which documentation changes (if any) need to be made?
4. Does this introduce a backward incompatible change or deprecation?