<p dir="auto">Docker 1.12 is going to be relased in a week and it will contain feature  "The option --dns and --net=host should not be mutually exclusive" (<a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="151798040" data-permission-text="Title is private" data-url="https://github.com/moby/moby/issues/22408" data-hovercard-type="pull_request" data-hovercard-url="/moby/moby/pull/22408/hovercard" href="https://github.com/moby/moby/pull/22408">moby/moby#22408</a>)<br>
Let's enable using this functionality in kubelet. For now in case of "hostNetwork: true" set all dns settings are ignored if any.</p>
<p dir="auto">With 1.1, we allow pods to be created with hostNetwork = true.<br>
These pods should be allowed to use Cluster DNS, if the pod spec says so.</p>
<p dir="auto">We have already wired the kube-proxy to support traffic from the host machine to be directed to kube-services. We should similarly allow cluster dns names to be looked up by pods with hostNetwork=true.</p>
<p dir="auto">This way, pods can use hostNetwork = true and still leverage kubernetes' service discovery mechanisms.</p>
<p dir="auto">I currently have a use case, where I am writing a GCE Firewall pod, that configures iptables on the nodes. This pod needs to run with hostNetwork=true to configure iptables and the same time needs to look up a kubernetes pod service to read some metadata.<br>
Refer to <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="117484732" data-permission-text="Title is private" data-url="https://github.com/kubernetes/kubernetes/issues/17405" data-hovercard-type="pull_request" data-hovercard-url="/kubernetes/kubernetes/pull/17405/hovercard" href="https://github.com/kubernetes/kubernetes/pull/17405">#17405</a><br>
<a href="https://github.com/ArtfulCoder/kubernetes/blob/prototype2/contrib/gce-firewall/client.yaml#L19">https://github.com/ArtfulCoder/kubernetes/blob/prototype2/contrib/gce-firewall/client.yaml#L19</a></p>
<p dir="auto">Currently, I have hard-coded a Kubernetes service-ip since we dont have cluster dns for hostNetworked-pods.  This is hardly a workable solution.</p>
<p dir="auto">I would imagine that third-party network plugins would also face similar issues if they try to do a clean implementation.</p>
<p dir="auto">Option 2:<br>
The other option is to query API server to do service discovery. But this doesn't seem like a clean solution, especially since we have put in so much effort into our DNS based service discovery approach.</p>