dynamicforward: the new plugin implementation #7105
Conversation
There was a problem hiding this comment.
There isn't guarantee the ServeDNS will be called after df.forwarder will be initialized and the mutex won't help. Need another solution.
Signed-off-by: Paramoshka <[email protected]> Signed-off-by: Beastlex <[email protected]> Signed-off-by: Andrey Polovov <[email protected]> Co-authored-by: Beastlex <[email protected]> Co-authored-by: Andrey Polovov <[email protected]>
8c9f509 to
df0a446
Compare
Signed-off-by: Paramoshka <[email protected]>
Signed-off-by: Paramoshka <[email protected]>
…ugin Signed-off-by: Paramoshka <[email protected]>
Signed-off-by: Paramoshka <[email protected]>
|
I haven't really looked at the code, but a few organizational points:
|
|
Thank you, @johnbelamaric, for your feedback. Let me answer your questions:
The main purpose of the plugin is not to reduce latency by eliminating an extra "hop," but to increase reliability.
Scheme with the new plugin:
Good name, it is better, will rename if there won't be better options.
This tool uses coredns and it's Corefile under the hood, so here we are. Also, this tool is handy when you use some classic CNI with kube-proxy as Service implementation, but in clusters with eBPF-powered kube-proxy implementations (i.e. Cilium), it is overhead. |
|
I think this should be an external plugin that node local dns can pull in. |
|
Thank you @chrisohaver for the idea, I think this is a good option for our plugin to make it external. We will look at the documentation soon and redo the current PR. Is there no objection if we add an interface function |
|
Hello, @chrisohaver and @johnbelamaric, Following the suggestions above, we have decided to move our dynamicforward - now under a new name kubeforward - to the external plugins In addition, we identified the need for an interface for passing parameters to the forward plugin. We implemented a separate PR for this purpose. Thank you for your recommendations and feedback! |
|
Hey @Paramoshka, shall we close the PR now that kubeforward is handled as an external plugin? |
@thevilledev Yeah, I think we can close, thanks for the reminder. |
1. Why is this pull request needed and what does it do?
This pull request introduces a new CoreDNS plugin, dynamicforward, designed for dynamic tracking of Kubernetes Services and seamless updates to the forward server list. The plugin monitors EndpointSlices associated with a specified Service, dynamically adjusting the DNS forwarding configuration as endpoints are added, removed, or updated.
The dynamicforward plugin is particularly useful for organizing node-local-dns caching mechanism. In standard scheme we use ClusterIP as upstream, so we are delegating responsibility for load balancing to CNI. In case of apiserver failure, CNI don't know which upstream endpoints are alive or not.
But coredns itself can handle upstream healthchecks and in case of apiserver failure it will still keep the endpoints list and will load balance the requests.
There are some design imperfections:
2. Which issues (if any) are related?
3. Which documentation changes (if any) need to be made?
Added man.
4. Does this introduce a backward incompatible change or deprecation?
No.