容器网络方面的挑战和要求

在最近于加拿大温哥华召开的OpenStack峰会上，6000多名与会人士接受了使用容器情况方面的调查。被问及是否在生产环境中有容器时，台下一小部分听众举手示意――据我估计大概有5%。但是被问及谁在接下来几年考虑将容器迁移到生产环境时，几乎人人都举手。

这一幕生动地表明，虽然容器是一项现处于早期阶段的技术，但众多企业组织为它制定了宏伟计划。由于Docker和Kubernetes等多种选择，用户们在认真考虑自己的选择道路。容器提供了几个明显的优势：简化和加快了应用程序的部署、可移植性以及占用少量的资源，但是也存在风险。

容器网络方面的挑战和要求

一大风险就是整合。开源社区正在考虑如何将容器整合到现有的云和自动化框架当中，比如Magnum和几个OpenStack项目。另一个问题就是容器网络。用户们常常问我如何设计一套同时支持容器和虚拟机的网络解决方案。虚拟机和容器(以及部署的裸机系统)通常带来了全然不同的网络模型。

不妨后退一步，考虑一下如今的容器网络是如何工作的。容器网络基于一种简单的架构，主要是单主机解决方案。比如说，Docker网络模型基于几个简单的假定：

•它充分利用与容器相连接的本地(每个主机里面的)Linux网桥。

•每个计算节点都有集群看得见的IP地址。

•每个容器都有集群看不见的专有的IP地址。

•网络地址转换(NAT)协议用来将容器的专有IP地址绑定至计算节点的公共IP地址。

•此外，负载均衡系统可用来将服务映射至一组IP地址和端口。

•iptable用于应用程序与租户之间的网络分段和隔离。

如果运用到容器网络上，这种模型在许多方面显得不尽如人意。它限制了用容器构建的多租户云解决方案跨多个主机进行扩展的功能。高可用性方面的配置很有限。无论工作负载的移动性如何，一致的连接性和安全性也成问题。另外，iptable和NAT的结合使用限制了可扩展性和性能，这让使用容器的主要优势之一荡然无存。

那么，面向容器的网络解决方案应该提供什么呢?另外，你又该如何评估解决方案与特定应用程序的契合度?我们不妨把这分成三个问题;这些答案应该可以帮助你更深入地了解容器网络方面的独特之处。

这直接影响到你网络基础设施的蓝图以及如何构建网络基础设施。你的应用程序需要丰富的网络拓扑结构以及高级服务吗?它们是多租户模式，还是简单的“扁平网络”就足以胜任?

面向容器的虚拟网络解决方案让最终用户(租户)和云操作人员都可以定义并控制各自的网络要求。解决方案还必须提供跨多个物理主机的微分段(micro-segmentation)和隔离所需要的构件。

你在思考这个问题时，要考虑基础设施上应用程序的要求。应当考虑这样的解决方案：在一种完全分布式的架构中提供隔离和网络功能，从而为你应用程序的发展和扩展铺平道路。随着部署的云越来越庞大，网络解决方案应该跨多个物理主机向外扩展，还应该在云编排框架里面紧密地整合起来。

大多数应用程序需要用容器支持混合工作负载，所以要寻求同时支持两者的解决方案。一致的抽象模型(网络、子网、路由器、接口和浮动IP地址)和一套用于配置和自动化的一致的API，是完成这项工作的方法。

云用户呼吁面向任何工作负载的网络模型与功能强大的网络抽象结合起来，从而简化容器到容器的联系，并且增添先进的网络功能和微分段。

你在网络和容器方面有什么样的挑战和要求?欢迎留言交流!