Code change:
} } } <ins> // TestProcessHostnameOverrideFlag tests processing hostname-override arg func TestProcessHostnameOverrideFlag(t *testing.T) { testCases := []struct { name                 string hostnameOverrideFlag string expectedHostname     string }{ { name:                 "Hostname from config file", hostnameOverrideFlag: "", expectedHostname:     "foo", }, { name:                 "Hostname from flag", hostnameOverrideFlag: "  bar ", expectedHostname:     "bar", }, } for _, tc := range testCases { t.Run(tc.name, func(t *testing.T) { options := NewOptions() options.config = &kubeproxyconfig.KubeProxyConfiguration{ HostnameOverride: "foo", } options.hostnameOverride = tc.hostnameOverrideFlag err := options.processHostnameOverrideFlag() assert.NoError(t, err, "unexpected error %v", err) if tc.expectedHostname != options.config.HostnameOverride { t.Fatalf("expected hostname: %s, but got: %s", tc.expectedHostname, options.config.HostnameOverride) } }) } } </ins>

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: kube-proxy came up cleanly but mis-configured iptable rules due to a mis-match in the hostname and node name within the cluster triggering a default behavior. In this case the hostname returned the fqdn of the host and the cluster only had the hostname. This resulted in the following warning messages when kube-proxy started. Which then presents itself as pods not being able to access clusterip ip addresses with no route errors. What you expected to happen: Would it be better to fail to in this scenario rather than try to fall back to some default? I spent a good amount of time trying to track down the Error messages that were a result of this before finally working back to taking a closer at the Warning message. How to reproduce it (as minimally and precisely as possible): Start the kube-proxy with set to an invalid hostname should recreate this issue. Anything else we need to know?: While I think we can chalk up this issue to mis-configuration the purpose of opening this issue is really to have a conversation about the default behavior. I've seen several other issues filed that appear to be related to this behavior: , , . Would throwing an error and exiting non-zero be a better default action when the nodeIP is nil? What use case(s) does a default of support? If there must be a default behavior here maybe the IP address on the interface associated with the default gateway is a better default than ? Maybe the issue isn't in the proxier code but the kube-proxy itself should error when it fails to get node info rather than a warning? Environment: I'm not sure how much of this is important to this but here's what my environment was when I ran into this. Kubernetes version: 1.8.5 Cloud provider or hardware configuration: Bare metal OS (e.g. from /etc/os-release): Centos 7 and Ubuntu 16.04
This is similar (though not the same symptom) to for which was supposed to fix it but was closed. One of the objections was up til now, kube-proxy has had no requirement that the hostname = nodename or even that the hostname be defined.