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