I'm developing a high-throughput data streaming application and I'm worried about the latency overhead introduced by the Docker bridge's NAT (Network Address Translation). I’ve read that the "host" network driver offers better performance by sharing the host's stack. What are the security risks involved, and is the performance gain significant enough to justify losing container isolation?
3 answers
If you need high performance but want to keep isolation, look into the Macvlan driver. It gives the container its own MAC address on the physical network.
The performance gain is definitely noticeable for high-PPS (packets per second) workloads because you bypass the virtual bridge and iptables overhead. In "host" mode, the container doesn't get its own IP; it uses the host's IP directly. The primary security risk is that the container has full access to the host's network services; if the container is compromised, the attacker can easily scan your local network or shut down host services. Also, you face port conflicts—you can't run two containers on port 80 if they both use the host network. Use it only for performance-critical components like load balancers or telemetry collectors
Are you specifically seeing a bottleneck in your current tests, or are you just trying to optimize prematurely before reaching a certain scale?
Gary, we actually hit a wall at 50k concurrent connections where the kernel's conntrack table for the bridge was getting exhausted. Patricia, the port conflict issue is a bit of a headache for our scaling strategy, but for our primary ingestor node, it seems like a necessary evil. We’ve decided to put only the ingestor on the host network and keep the rest of the microservices on a segregated bridge network to maintain at least some level of isolation for the sensitive parts of the app.
Kevin's suggestion is excellent. Macvlan is often the "middle ground" for enterprise networking where you need bare-metal speeds but strict logical separation