Change:
func (config *NetworkingTestConfig) EndpointHostnames() sets.String { expectedEps := sets.NewString() for _, p := range config.EndpointPods { if config.EndpointsHostNetwork { <del> expectedEps.Insert(p.Spec.NodeSelector["kubernetes.io/hostname"]) </del> <ins> // Hostname behavior for hostNetwork pods is not well defined and when // using the flag hostname-override in the kubelet, the node reported // hostname on host network pods will not match the node's hostanme. // It seems that the node.status.addresses hostname value is the only // one that matches the value returned by os.Hostname // used by the agnhost web handler, so we'll use that value. // If by any circumstances the node does not provide that hostnae address // we use the value of the node name. // xref: https://issues.k8s.io/126087 hostname := p.Spec.NodeSelector["kubernetes.io/hostname"] for _, n := range config.Nodes { if n.Name == p.Spec.NodeSelector["kubernetes.io/hostname"] { for _, address := range n.Status.Addresses { if address.Type == v1.NodeHostName { hostname = address.Address break } } break } } expectedEps.Insert(hostname) </ins> } else { expectedEps.Insert(p.Name) }

Discussion:
In addition to this cluster, there are a few others: There's something wrong i am probably doing when setting up things for EC2/kubeadm based clusters in but can't put my finger on what's wrong. /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig network
/assign /triage accepted
related that was superseded by .

The problem seems similar to , these jobs are setting the --hostname-override flag The test expects to get the override hostname value but the agnhost image returns the actual os.Hostname The problem seems to be that hostname-override on nodes didn't consider hostNetwork Pods in the design, where the Pod will use the host network namespace and at least in containerd, the host UTS namespace I'm not sure, but it seems that CRIO uses a custom UTS namesapce for the host network pods I think that if the operator sets the hostname override , is reasonable to assume that hostNetwork Pods will use that value as the , however, this is a long standing issue It seems that at least the reported hostname in the matches ]NodeAddress{NodeAddress{Type:InternalIP,Address:172.20.217.68,},NodeAddress{Type:ExternalIP,Address:3.239.3.31,},NodeAddress{Type:InternalDNS,Address:i-.ec2.internal,},NodeAddress{Type:Hostname,Address:i-.ec2.internal,},NodeAddress{Type:ExternalDNS,Address:ec2-3-239-3-31.compute-,},},DaemonEndpoints:NodeDaemonEndpoints{KubeletEndpoint:DaemonEndpoint{Port:,},},NodeInfo:NodeSystemInfo{MachineID:,SystemUUID:-03af-42ec-0fb5-,BootID:-7b40-4536-a690-,KernelVersion:6.1.96-102.177.amzn2023.x86_64,OSImage:Amazon Linux 2023.5.,ContainerRuntimeVersion:containerd://1.7.16,KubeletVersion:v1.31.0- so instead of using the existing we use the hostname value we may fix this bug and
we definitely use in the ec2/kubeadm harness
yeah, that should not be a problem, the problem is that all these things grew organically and with the cloud provider migration it is very chaotic, specially because it seems every project and cloud provider implemented its own workaround instead of reporting this back and build a unified and consistent solution