Kubelet should not add IPv6 entries to /etc/hosts on systems where IPv6 is disabled
PaulFurtado opened this issue · comments
What happened?
Kubelet unconditionally adds IPv6 entries to /etc/hosts even when system has IPv6 totally disabled. This results in strange errors due to "happy eyeballs" fallback behavior: when clients see both an IPv4 and an IPv6 address for a host, they first try IPv4 and then fall back to IPv6, but if IPv6 is disabled in the kernel, they then get an "Address family not supported by protocol" exception instead of "Connection refused".
This happens with standard HTTP clients, etc, but here's an example with netcat:
# nc -v 127.0.0.1 1111
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connection refused.
vs
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connection to 127.0.0.1 failed: Connection refused.
Ncat: Trying next address...
libnsock nsock_make_socket(): Socket trouble: Address family not supported by protocol
Ncat: Address family not supported by protocol.
That results in clients needing to handle a different exception. However, even if IPv6 were enabled on the system, it would still be invalid to put loopback addresses in /etc/hosts for localhost when they are not actually configured on the loopback interface.
Code here: https://github.com/kubernetes/kubernetes/blob/v1.29.4/pkg/kubelet/kubelet_pods.go#L373-L377
What did you expect to happen?
Kubelet should not add localhost entries to /etc/hosts for addresses that do not actually exist on the pod's loopback interface.
How can we reproduce it (as minimally and precisely as possible)?
I don't think you need a reproducer for this one since the code is just unconditionally doing this. However, if you're looking to test this on a system with ipv6 disabled such that you get the "Address family not supported by protocol" error, or guarantee that CNI does not add an IPv6 loopback address, you can boot your kernel with ipv6.disable=1 on the kernel command line.
Anything else we need to know?
No response
Kubernetes version
N/A all versions impacted
Cloud provider
N/A
OS version
N/A
Install tools
N/A
Container runtime (CRI) and version (if applicable)
N/A
Related plugins (CNI, CSI, ...) and versions (if applicable)
N/A
This issue is currently awaiting triage.
If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members by writing /triage accepted in a comment.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
/sig network