dnscache: use nameservers from cli (remove node/proxy)#48
dnscache: use nameservers from cli (remove node/proxy)#48k8s-ci-robot merged 3 commits intokubernetes-sigs:mainfrom
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: aojea The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
33d5e3a to
8fb74ca
Compare
kindnet was using a "smart" hack to obtainer the cluster nameservers for the dnscache functionality, so the nfqueue didn't have to inspect all DNS traffic and just the one associated to the cluster. However, the node/proxy permissions are risky and users can pass this information via flags, since is not likely going to change and despite is per node, it was always used as a global value. It also makes this feature disabled by default, since there is some flakiness associated that we never were able to figure out, but it can also be possible it is associated to some kernel bug or behavior associated to the resolvers (happy eyeballs and similar)
8fb74ca to
629dc20
Compare
| } | ||
|
|
||
| d.clusterDomain = kubeletConfig.ClusterDomain | ||
| resolvPath := "/etc/resolv.conf" |
There was a problem hiding this comment.
I see the CLI arg for the nameservers, do we not need to be told what resolv.conf to read any more?
There was a problem hiding this comment.
this feature needs the DNS nameserver IP to narrow the network filter down and avoid the impact of diverting traffic from kernel to userspace.
The trick I was using is to read the resolv.conf that was going to be populated on the pods, to get the cluster DNS nameserver IP, but this requires to read the kubelet config ... I tried to get as much information as possible from all the sources, but it looks it was just a bad idea and now we can ask admins to configure those ips directly
Co-authored-by: Jordan Liggitt <jordan@liggitt.net>
|
@liggitt PTAL |
|
/lgtm |
/hold cancel This feature is inherited from my own fork, and in hindsight it was not a good idea |
kindnet was using a "smart" hack to obtainer the cluster nameservers for the dnscache functionality, so the nfqueue didn't have to inspect all DNS traffic and just the one associated to the cluster.
However, the node/proxy permissions are risky and users can pass this information via flags, since is not likely going to change and despite is per node, it was always used as a global value.
It also makes this feature disabled by default, since there is some flakiness associated that we never were able to figure out, but it can also be possible it is associated to some kernel bug or behavior associated to the resolvers (happy eyeballs and similar)
Fixes #47
/cc @liggitt