Today's Trends
mediumInvestigatingKubernetes

Kubernetes Kubelet: Node /etc/hosts Entries Shadow hostAliases in hostNetwork Pods

  1. Investigating(current)
  2. Trending(upcoming)
  3. Workaround available(upcoming)
  4. Resolved(upcoming)

Executive summary

In hostNetwork: true Pods, kubelet writes the node's /etc/hosts entries before appending spec.hostAliases. Consequently, when the node already contains an entry for the same hostname, lookups resolve to the node's IP first rather than the intended hostAlias IP.

No verified workaround yet

None of the linked reports describe a mitigation. Follow this incident to hear when one appears.

Official fix
Technical root cause

Kubelet writes the node's /etc/hosts file content to the buffer before appending hostAliases entries from the spec, causing standard resolvers to return the node IP first for matching hostnames.

Evidence

1 report · 1 GitHubShow
  1. [1]
    GitHub First report
    kubelet: node /etc/hosts entries shadow hostAliases in hostNetwork Pods(opens GitHub issue in a new tab)

    What happened? For hostNetwork: true Pods, kubelet writes the node's /etc/hosts first and appends spec.hostAliases after it (nodeHostsFileContent): buffer.Write(hostsFileContent) // node /etc/hosts buffer.Write(hostsEntriesFromHostAliases(hostAliases)) // spec.hostAliases When the node already has an entry for the same hostname, lookups return the node's address first. For example, Go's resolver returns [<node IP> <hostAliases IP>]. Clients connect to the first address, so the Pod's…

    by sprait 0upvotes 2comments

Timeline

  1. First report on GitHub issue

    kubelet: node /etc/hosts entries shadow hostAliases in hostNetwork Pods

    Source