本文讲的是三种容器网络方案【编者的话】本文是
TheNewStack容器电子书
的一部分，着重介绍了容器的网络互联方案。有兴趣的同学可以关注下电子书。
任何云端部署容器的关键之一是管理容器间的网络。在研究编写我们最新的电子书
《Networking, Security & Storage with Docker & Containers》
期间，我们总结了三种通过插件集成容器网络的方式。
前一篇文章中
，我们介绍了容器网络模型（CNM）和容器网络接口（CNI），这篇文章中我们会介绍它们的起源和另一个领域：
Apache Mesos
生态。
CNM与Libnetwork
Docker的可扩展性设计模型使得我们可以通过向daemon代码添加扩展库的方式来扩展系统的功能，这涉及一个代码库，类似于Docker运行时，但库仅用作补充。这个库是
libnetwork
，最初由SocketPlane团队开发作为Docker第三方项目发布，SocketPlane公司在2015年3月份被Docker收购。
本质上讲，libnetwork提供了一种支架，开发人员可以基于它编写网络驱动。libnetwork的约束规则称为容器网络模型（CNM），CNM被认为是容器的一个权利法案。权利之一是平等地访问网络中所有其它容器;分割，隔离和流量分配是通过划分网络地址来实现的。服务发现模型为容器提供了一个互相通信的方法。
libnetwork目的是实现和使用任何类型的网络技术来连接、发现容器。对任何网络覆盖方案，它没有指定一个首选方案。
Calico
就是一个独立、开源、供应商中立的Layer 3网络覆盖方案。开发人员最近将Calico的calicoctl库修改为可寻址，可以作为Docker的一个插件。
ClusterHQ
是第一批为数据库实现持久性容器系统的公司之一，产品名为
Flocker
。Flocker使用libnetwork库和Weaveworks的
Weave Net
网络覆盖方案。ClusterHQ产品副总裁
Mohit Bhatnagar
告诉我们：“我认为我们正处于一个临界点，最初那些用容器部署无状态服务的客户出现了部署有状态服务的潜在需求。而有状态服务需求的客户数量，令非常惊喜。”
Docker方案的关键架构区别在于正在扩展的部分。在Docker架构中，Docker Engine的守护程序运行在要暂存应用程序的主机服务器上，Docker Swarm重新配置了Docker Engine的网络视图，将其替换为集群中运行的服务器的混合网络视图。Swarm实际上是编排器，但插件可以在较低层扩展Docker Engine。
容器网络接口
Kubernetes
项目发布了实现网络可扩展性的
指南
。（指南认为）网络扩展应该不借助网络地址转换（NAT）就能寻址到容器的IP，并且允许以相同的方式解决自己的寻址问题。基本上，只要组件是IP可寻址的，组建就可以很好地运行在Kubernetes上。在这种背景下，理论上任何你想实现的功能不需要必须绑定到Kubernetes上，把它作为Kubernetes的扩展组件就可以了。
Google技术经理
Tim Hockin
解释到：“我们一直关注我们在Kubernetes网络上所做的，显然，核心系统没有办法处理每一个网络用例。世界上的每个网络都像雪花一样独一无二，我们没有办法全部实现到我们的系统中。我们必须把它外部化，插件化是我们的方式。”
CoreOS后来发布了自家的容器网络接口（CNI），它比CNM更基础，因为它只有两个命令：创建容器、删除容器。配置文件放在JSON中，通过json文件实例化容器内容和分配IP地址。因为这遵循Kubernetes的网络指南，Google发布的指南对CNI友好。因此，Flannel和Weave Net已经使用CNI实现各自的Kubernetes插件。
Hockin承认这些扩展把灵活新颖的网络连接带到Kubernetes环境中，但是它们也带来了损耗。“一般Kubernetes对overlay网络的观点是，如果你真的必须使用overlay，那就使用它们吧。这会给他们带来更多的复杂性、管理和沟通成本。我们发现越来越多的Kubernetes用户直接使用Layer 3路由，相比overlay方案，Layer3减少了他们的时间成本。”
在重新评估了可扩展框架当前状态后，ClusterHQ得出结论：模型的选择将取决于，或许完全取决于集成到容器的工作量。ClusterHQ工程和运营高级副总裁
Sandeepan Banerjee
解释到：“如果你的作业以前运行在VM上，VM有IP地址并且可以与项目中的其他VM通信，CNI模型和Kubernetes以及Weave是你的最佳选择。”Banerjee然后引用Kubernetes的no-NAT约定作为关键理由。他又继续讲到“如果你之前不了解这些，但是你想充分尝试Docker，包括Docker的网络库、编排框架Swarm等，你可能会发现Docker提供的解决方案很强大，它有很多优势、对overlay网络也很灵活。”
Mesosphere和它的插件
Mesosphere已经发布了或许是最复杂的Mesos商业实现
DC/OS
，并且发布了编排系统
Marathon
与Kubernetes直接竞争。
作为一个调度平台，扩展Mesos功能的工作早就开始了。实现了Hadoop大数据任务调度、Jenkins的任务管理和Docker容器部署等，这些功能已经在各自的平台内实现。但在2016年夏天，Mesosphere开始有了不同的观点，开始准备利用CNI扩展容器连接的新方案。在撰写本文时，Mesosphere已经发布了一份文件，在DC/OS路线图实施阐明其支持SNI的意图。
Mesosphere创始人兼首席架构师
Ben Hindman
讲到：“我们现在的世界中有足够多的供应商、接口和网络存储的实现方案。我认为插件的实现方式非常重要。现在尚不明确是否由Docker定义的插件将成为通用插件。我认为你今天在行业中所看到的，并不一定是未来的样子。”
目前DC/OS使用开源的负载均衡服务发现系统
Minuteman
实现容器互连。它截取两台主机上容器的网络包，然后重写包，添加目的地的IP地址。这种跨云网络通信的实现方式将DC/OS与其它实现方式区别开来。同样，DC/OS提供了设置虚拟可扩展局域网（VXLAN）的功能，建立的VXLAN中的路由规则。Mesosphere并没有重新发明轮子，实际上，它让用户基于性能或其它因素自己选择overlay方案。
Hindman告诉我们，他认为Flannel，Weave和其它overlay网络系统在解决容器网络问题上，比VXLAN方案更有价值。事实上，这种替代方案将出现，他说到，“作为一个行业（容器网络解决方案），我们发现一个事实：我们正在尝试不同的解决方案来实现我们的想法。我认为我们可能会解决一些问题，overlay方案也会继续存在。但是我相信还会有其它方案，没有使用现存的SDN技术，就可以连接容器。”
Integration Towards the Future
今天，在IT和数据中心预算中，容器化通常不是一个单独的订单项。当签署支票的人不明白他们的钱的花在什么地方时，就需要详细的解释来让他们弄明白这些概念。有些人可能过多的解释淡化了容器集成的主题。事实上，集成的方案把一些基本的思想提升到共同讨论的层面。大家都理解到基本需求是让新旧系统共存，让它们通过接口通信。尽管这些方法在几年内可能看起来很复杂或不切实际，但为了达到一个良好的解决方案而迸发出来的灵感将使这一切都值得追求。
原文连接：THREE APPROACHES TO CONTAINER NETWORKING（翻译：adolphlwq）
=========================================
译者介绍
adolphlwq，博客地址：QuanTalk
原文发布时间为：2016-10-14
本文作者：adolphlwq
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：三种容器网络方案
