Change:
When I passing to kubelet, it did not respect the option, and still copy the to the pod. What makes it special is that the provided by myself is empty. After skimming the code, I found the logic here is problematic: Because is empty, an empty array and no error is returned. Then, if the dnsPolicy is (that is the default config for CoreDNS deployment), the turns to be : Then, containerd will get an empty , so it will copy from the host to the container: Finally, CoreDNS reports forwarding loop error. Kubelet should refuse to use the wrong empty to create a pod, and complains with errors. to kubelet, and make sure the specified file is empty. the output of CoreDNS, and its . No response_ <detailsk8s v1.28.2 containerd v1.7.6 </details<detailsNone </details<detailsAny major Linux distribution. </details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig node
/sig network
why if someone wants to pass an empty to the pods? is that a possibility? I do not know if kubelet should compensate what it seems an operator problem, or am I reading it wrong?
This situation MAY occur when systemd-resolved is used, and the operator pass the to kubelet. Although systemd-resolved create this file in manner of "create temp, write temp, rename" ... ... the UPLINK config () file may still be full of comments if there is no available name server at the time.
And after a while, systemd-resolved got an available dns server by any way, then the UPLINK config should be recreated, however the kubelet have taken the stale and full-of-comments .
I see there is a race there, thanks for the explanation ... the only question I have is if someone is relying on this behavior of passing an empty to the pods, a change like this will break it
/remove-sig node. This is on network team to decide how to migrate a new behavior for empty file..
Those labels are not set on the issue: <detailsIn response to : /remove-sig node. Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/remove-sig node
If set , it means will use the default value , so this change may be not a break, but should be a warning.
It is suggesting to change the behavior to stop the pod creation
/assign But if already have design on this, please go ahead.
I still don't have clear what is the proposal and how to maintain compatibility
Cool, may be it's like new warning events just like , or something else.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/lifecycle frozen
This is a fun bug, but not that hard to comprehend, I think. Forget whether it's a "good idea" or not. Is it valid to pass an empty file to ? If yes, should it mean the same as not passing that flag or should it mean "no config". I think it IS valid and it SHOULD mean "no config". What really happens is that kubelet gets empty slices (but no error, so not ambiguous). When it creates the DNSConfig message, it appears empty, because it is comprised entirely of fields with no instances. That is ambiguous - it could mean "no data" or "not specified". It's unclear to me if we can tell the difference between those? - do you know? can return nil. Containerd further conflates those two by parsing into a string, and assuming means "not specified". Even if it WAS specified! Then, containerd "helpfully" decides that, if you don't specify any contents, it should copy the host's I am not 100% confident in CRI semantics - is it valid for CRI to NOT populate the message? Or is that effectively required? If a CRI caller does not specify , is the CORRECT behavior to go look at the host? That seems like over-stepping, to me. If I wanted a DNS config, I would have sent it. Agree or disagree? So IMO, the fix here is either (in my pref order): 1) containerd should not fall back on host's AT ALL 2) containerd should differentiate "not provided" from "provided and empty" ( returned nil) 3) we should add a "this struct intentionally left blank" marker to , so containerd can do the above So I think this very much is a SIG Node issue. /sig node As to the question of how this problem was are you setting the kubelet to an empty rather than just configuring the specific Pods in question?
This is because CoreDNS reports a forwarding loop issue due to systemd-resolved is used in the node, and I pass to kubelet. But it has a race condition here when the node restarted, the file may be full of comments if there is no available name server at the time. And after a while, systemd-resolved got an available dns server by any way, then the UPLINK config should be recreated, however the kubelet have taken the stale and full-of-comments . Of course passing an empty is incorrect, but it is not deliberately.
Fixed in containerd
you should check if you need to fix this too in cri-o ^^^
It looks like . I'm going to create a PR in .
Thank you and thanks for the hint! :heart:

Discussion:
# Emacs save files *~ <ins> #*# .#* </ins> # Vim-related files [._]*.s[a-w][a-z]

# Karma output www/test_out <ins> # precommit temporary directories created by ./hack/verify-gendocs.sh and ./hack/lib/util.sh _tmp/ doc_tmp/ </ins>