最近在加拿大温哥华举行的OpenStack峰会上，超过6,000名与会者接受了有关容器使用情况的调查。当被问及他们是否在生产中使用容器时，一小部分观众举起了手——据我估计，大约为5%。但当被问及谁在考虑在未来几年内将容器投入生产时，几乎每个人都举手了。这一幕生动地表明，尽管容器是一项处于早期阶段的技术，但许多企业组织都对它有着宏伟的计划。借助Docker和Kubernetes等选项，用户正在认真考虑他们的路径。容器提供了几个明显的优势：简化和更快的应用程序部署、可移植性和较小的资源占用，但也存在风险。一大风险是整合。开源社区正在考虑如何将容器集成到现有的云和自动化框架中，例如Magnum和几个OpenStack项目。另一个问题是容器网络。经常有用户问我如何设计一个同时支持容器和虚拟机的网络方案。虚拟机和容器（以及部署的裸机系统）通常会导致截然不同的网络模型。退后一步，考虑一下当今容器网络的工作原理。容器网络基于简单的架构，主要是单主机解决方案。例如，Docker网络模型基于几个简单的假设：?它利用本地（每个主机内部）Linux桥接容器。?每个计算节点都有一个集群可见的IP地址。?每个容器都有一个集群不可见的专用IP地址。?网络地址转换(NAT)协议用于将容器的私有IP地址绑定到计算节点的公共IP地址。?此外，负载平衡系统可用于将服务映射到一组IP地址和端口。?iptables用于应用程序和租户之间的网络分段和隔离。当应用于容器网络时，该模型在很多方面都存在不足。它限制了使用容器构建的多租户云解决方案跨多个主机扩展的能力。高可用性的配置是有限的。无论工作负载移动性如何，一致的连接性和安全性也是问题。此外，iptables和NAT的组合限制了可扩展性和性能，这否定了使用容器的主要优势之一。那么，面向容器的网络解决方案应该提供什么？此外，您如何评估解决方案是否适合特定应用程序？让我们将其分解为三个问题；这些答案应该可以帮助您更深入地了解Web特有的容器。1.您将在基于容器的基础架构上运行什么类型的应用程序？这直接影响您的网络基础设施的蓝图以及您构建它的方式。您的应用程序是否需要丰富的网络拓扑和高级服务？它们是多租户，还是一个简单的“平面网络”就足够了？面向容器的虚拟网络解决方案允许最终用户（租户）和云运营商定义和控制个人网络需求。该解决方案还必须提供跨多个物理主机的微分段和隔离所需的构建块。2.在性能和可扩展性方面有什么要求？在考虑这一点时，请考虑应用程序对基础设施的要求。考虑在完全分布式架构中提供隔离和联网的解决方案，为您的应用程序的增长和扩展铺平道路。随着云部署变得越来越大，网络解决方案应该跨多个物理主机横向扩展，并且还应该紧密集成在云编排框架中。3.您是否需要将容器与虚拟机和裸机工作负载互连？大多数应用程序都需要容器来支持混合工作负载，因此请寻找同时支持两者的解决方案。一个一致的抽象模型（网络、子网、路由器、接口和浮动IP地址）和一组一致的用于配置和自动化的API是实现这一点的方法。云用户需要一种适用于任何工作负载的网络模型，结合强大的网络抽象，简化容器到容器的连接并添加高级网络功能和微分段。您在网络和容器方??面有什么样的挑战和需求？欢迎留言交流！
