<p>Saw on a few issues (such as <a href="https://github.com/docker/for-mac/issues/2716" rel="nofollow noreferrer">https://github.com/docker/for-mac/issues/2716</a>) that <code>network_mode: host</code> is not supported on Mac.</p>
<p>However, when I was trying to run a Kubernetes cluster using <a href="https://kind.sigs.k8s.io/" rel="nofollow noreferrer">kind</a>, and run Spark on K8s, using the Spark master address as <code>k8s://127.0.0.1:59369</code> which is the same address and port as the K8s control plane, I get a Connection Refused error unless I am using <code>network_mode: host</code>. Error line:</p>
<pre><code>Caused by: java.net.ConnectException: Failed to connect to /127.0.0.1:59369
</code></pre>
<p>This confuses me as I thought <code>network_mode: host</code> should have no effect on Mac, yet there is an effect, and it is blocking me from using bridge network and adding port mapping for another application in this container.</p>
<p>Any ideas how to resolve this?</p>

bqiu
<p>Specifying host networking on Docker Desktop setups does something; the problem is that the &quot;host&quot; network it specifies isn't actually the &quot;host&quot; you'd intuitively expect as someone typing on the keyboard.</p>
<p>Docker Desktop on MacOS launches a hidden Linux VM, and the containers run inside that VM.  When you run <code>docker run -p</code>, Docker Desktop is able to forward that port from the VM to the host, so port mappings work normally.  If you use <code>docker run --net=host</code>, though, you get access to the VM's host network; since this generally disables Docker's networking layer, Docker isn't able to discover what the container might be doing, and it can't forward anything from the actual host into the VM to the container.  That's the way host networking &quot;doesn't work&quot;.</p>
<p>In practice I see host networking suggested for four things:</p>
<ol>
<li>Processes with unpredictable or a very large number of port mappings, where <code>docker run -p</code> can't be used</li>
<li>To actually manage the host's network environment, in spite of running in a container</li>
<li>To access non-container processes on the same host, where <code>host.docker.internal</code> would also work</li>
<li>To access the published ports of other containers, without setting up Docker networking</li>
</ol>
<p>I think here's you're running into this last case.  Kind is publishing a port for the Kubernetes API service, so port 59369 is accessible on both the actual host and in the Linux VM.  Now if your Spark container activates host networking it is using the VM's host network, but the other container's published port is still accessible there, which is why the <code>http://localhost:59369</code> URL still works.</p>
