我了解，如果我将主机网络驱动程序用于容器，则该容器的网络堆栈不会与 Docker 主机隔离。 我也相信从概念上理解，仍然这样做的一个很好的理由可能是当“安全不是问题或担忧”并且网络吞吐量性能很重要时，但我正在努力思考一个真实世界的例子，说明我何时可以或应该这样做.我能想到的一个天真的例子是面向公众的负载均衡器或静态文件 Web 服务器。
我意识到，如果托管在 AWS 或 Google Cloud 之类的主机服务之外，可能会减轻安全问题，但如果这不是一个选项怎么办！
您何时会或应该在生产环境中使用它？ 无论托管环境如何，您如何减轻安全问题？ 您应该如何与其他 docker 网络中的其他服务交互？
【问题讨论】：
标签： docker docker-swarm
我正在努力想一个真实世界的例子，说明我何时可以或应该这样做。 ...您何时会或应该在生产环境中使用它？
您的应用程序不是在 TCP 或 UDP 上运行，而是在另一个协议上运行
您的应用程序需要发布大范围的传入端口（默认情况下，每个发布的端口都会生成一个 docker-proxy 进程，这对于大范围而言可能过多）
您的应用程序适用于多播或广播网络流量
您的应用程序需要修改主机本身的网络层，例如一个VPN
无论托管环境如何，您如何缓解安全问题？
您需要信任此应用程序。您已经删除了一层 docker 命名空间，此时，容器是一种打包格式，可能适合您的其他工具，但不需要与其他容器相同的安全方法。
您应该如何与其他 docker 网络中的其他服务交互？
您将通过其他容器的已发布端口进行交互，就像您在容器外运行的应用程序需要连接到容器内的应用程序一样。
【讨论】：
但我很难想出一个真实世界的例子，说明我什么时候可以或应该这样做。
这是现实世界的示例：我们使用主机网络来加快 gitlab ci/cd 管道的构建阶段。
有问题的容器仅在构建阶段启动并运行，没有暴露任何端口，需要更快的网络来下载所有必要的部分来构建和推送 docker 映像，我们遇到了（在某些间歇性情况下）吞吐量问题以及我们通过主机网络解决的构建阶段的不一致行为。尽管使用主机网络我们“公开”了此类容器的 ip，但我们仍然不公开任何端口，并且在构建阶段完成后容器被丢弃。
我知道这并不能回答您的所有问题，但要求提供真实世界的示例。
【讨论】：