Change:
// - container is not an infrastructure (pause) container // - container is not already mounting on /etc/hosts // Kubernetes will not mount /etc/hosts if: <del> // - when the Pod sandbox is being created, its IP is still unknown. Hence, PodIP will not have been set. // - Windows pod contains a hostProcess container </del> <ins> // - the Pod is on the pod network and PodIP has not yet been set (e.g., Pod sandbox is being created). // - the Pod is on Windows, and contains a hostProcess container. </ins> func shouldMountHostsFile(pod *v1.Pod, podIPs []string) bool { <del> shouldMount := len(podIPs) > 0 </del> <ins> shouldMount := len(podIPs) > 0 || pod.Spec.HostNetwork </ins> if runtime.GOOS == "windows" { return shouldMount && !kubecontainer.HasWindowsHostProcessContainer(pod) }

Discussion:
When the node network is not yet connected, start kubelet and create static pod like this The created container file does not contain the configuration of hostAliases. The created container file should contain the configuration of hostAliases. kubelet service. static pod with configuration of hostAliases. network, like . kubelet service. created container file does not contain the configuration of hostAliases. No response <details</details<details</details<details</details<detailskubeadm </details<detailscontainerd 1.6.4 </details<details</details
/sig node
23 is EOL please check if this is happening in a supported release, latest supported is 1.25
You might want to set up a dependency on network from kubelet (assuming you're using systemd), so that it doesn't start until network is ready. Also, could you reproduce this on a later version (eg. 1.27)? /triage needs-information
The kubelet systemd configuration file already declares a network-online target dependency, but it doesn't seem to work. Looks like additional dependencies are required such as NetworkManager-wait-online.service. I think the best way is that kubelet is compatible with this scenario. Also, I also tested on 1.27 and the problem is still reproducible.
Is there any progress in dealing with this issue?
I haven't been working on this, not sure if anyone is actively looking into it.
did you try adding this dependency? Did it work?
NetworkManager-wait-online.service only waits for 60s. If the network is still abnormal after 60s, the problem will still occur.
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]:
The Kubernetes project currently lacks enough active 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 rotten [1]:
/remove-lifecycle rotten
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]:
The Kubernetes project currently lacks enough active 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 rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages 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: Reopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close not-planned [1]:
Closing this issue, marking it as "Not Planned". <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

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 closedReopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] 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
/reopen /remove-lifecycle rotten
Reopened this issue. <detailsIn response to : /reopen /remove-lifecycle rotten 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
/sig network The kubelet wait for the PodIPs to be present to mount the etc hosts files however, it does not check if the pod is host network. If the Pod is using hostNetwork, then it seems the PodIPs are ignored so it seems legit to mount the aliases independently of PodIPs if the pod is using host network /assign /sig network /triage accepted
/remove-sig node