面向Docker的覆盖网络搭建探究*

2015-07-03张青刘剑朱晓民

电信工程技术与标准化 2015年9期

张青，刘剑，朱晓民

（1 北京邮电大学网络与交换技术国家重点实验室，北京 100876; 2 东信北邮信息技术有限公司，北京 100191)

1 引言

云计算产业正处在高速发展的时期，各种新技术层出不穷，Docker就是这样一款颠覆性的产品。云计算的服务模型大致分为3类，分别为软件即服务（SaaS）、平台即服务（PaaS）和基础设施即服务（IaaS），正是Docker的出现让PaaS受到了极大的关注，也很大程度上引领了PaaS的架构走向。

Docker是一款类似于LXC（Linux Containers，Linux容器）的开源应用容器引擎，它的轻量、快速和强大的可移植性吸引了众多的开发者，并逐渐成为了PaaS容器的主流。Docker使用镜像技术实现了其高可移植性，开发者将他们的应用和全部的环境依赖打包成一个镜像，这个镜像可以被发布到任何一台安装了Docker的机器上，并运行起来成为容器，向外提供服务。最重要的是,镜像不依赖于任何语言、框架或系统，独立成为一个运行单元，根本上解决了云计算中复杂的环境依赖关系。

Docker容器使用沙箱机制在机器上创建出了一个独立的空间，即使处于同一台机器，不同的容器之间也是相互隔离的，它们之间的通信只能像两台机器一样通过网络互访问来实现，这样保证了应用之间不会互相干扰。然而现在的应用越来越复杂，不可能只是运行在一个容器中，而是多个容器相互协作来实现应用的功能，这样容器与容器之间的网络互访问至关重要。

然而，Docker容器本身的网络结构导致实现网络互联较为困难。根据Docker主机通过端口号来标识服务的特点，业界通过服务发现的方式实现了容器的编排和整合，取得了不错的效果，但是这并不完美，所以开源社区开始探索基于SDN（Software Defined Network，软件定义网络）的网络解决方案，覆盖网络成为关注点之一。

覆盖网络的宗旨是在已有网络的基础上新建一层虚拟网络，它旨在跨越不同机器，让同一个应用下的各个容器处于同一个虚拟链路中，从而解决Docker容器的网络问题。本文提出了一种覆盖网络的搭建方式，并且具有很好的可伸缩性。

2 Docker网络结构

2.1 Docker网络

图1 Docker网络结构

图1展示了Docker的内部网络结构，多个container通过网桥docker0连接在了一起，构成一个内部网络，每个container都是一个独立运行的个体，都具有自己的MAC地址和IP地址，此时两个container可以畅通无阻地通信。外部网络与container的通信需要依赖Docker主机的NAT转换，即container中的每个服务都需要被Docker主机上的端口标识才能被访问到，这种情况下Docker表现得更像是一个内部网络。

2.2 多主机场景

图2中展示了处于不同主机上的container之间的互访问：IP为172.16.25.90的container能够对外提供服务，在其主机上暴露的端口号为3306，即所有到达192.168.100.5的3306端口的服务请求都会被转发到容器中，这样外部网络就可以实用container内部的服务。如果在另一台机器上有一个容器172.19.25.100想要访问上述服务，则必须通过地址192.168.100.5:3306来寻址，这样就需要在容器中配置另一主机（192.168.100.5）的地址。

图2 跨主机访问容器

这样的网络访问方式大大地增加了服务与主机的耦合程度，将一个主机的IP地址作为配置写入容器的镜像中去显然不太明智，如果提供服务的容器发生故障或者需要转移到别的主机上运行，那么服务的使用者必须要更新配置，甚至要重新制作镜像，这是在运行环境下无法忍受的。

一般可以通过服务发现的方式来解决云环境中的服务变更问题，但在Docker场景下通用的服务发现方式也遇到了困难。

图3中演示了一个失败的服务发现案例，discovery是服务注册集群地址，容器在注册自身服务的时候会使用自己的IP地址进行注册，生成服务名，但在另一侧获取到的服务地址并不是一个外部地址，所以并不能顺利访问。通用的服务发现方案在Docker环境下需要修改才可以使用，但是这种方法也并没有从根本上解决不同主机上container之间的透明访问难题，然而通过搭建覆盖网络可以让容器之间通过各自IP地址互相通信，就可以解决这个问题。

图3 容器访问失败

3 面向Docker覆盖网络搭建

3.1 覆盖网络

覆盖网络即在已有的网络拓扑的基础上重叠出一层虚拟网络，它避免了改变已有网络层结构所带来的巨大代价，而是从应用层上解决网络透明性问题。覆盖网络的虚拟链路对应着一条或多条物理路径，其网络节点也可以是各种网络功能节点，如路由器、服务器等。覆盖网络实际上就是在底层网络提供的基本网络连接基础上，在应用层上用软件的方法实现的一个新的网络。比较著名的覆盖网络系统有Spines等。

图4 Spines网络架构图

如图4所示，Spines是一个源代码公开的通用覆盖网络系统，由约翰-霍普金斯大学的分布式网络实验室所建立。Spines分为两个层次：用户层和覆盖网络节点层。用户程序要使用Spines覆盖网络提供的服务，首先要连接到最近的节点，这样就可以通过Spines覆盖网络向其它的用户发送数据了。当节点接收到来自用户或者其他节点的数据时，就选择适当的路由转发数据。经过逐跳的传输，数据到达目的节点，目的节点根据数据分组的端口，把数据提交给用户程序。Spines提供了端到端的可靠传输和不可靠传输，可靠传输使用了类TCP传输模式。

显然在Docker的场景下我们不能照搬Spines的设计，Spines中用户层实际上是应用的接口层，是覆盖网络提供的接口API，这与我们使用覆盖网络来保持Docker容器的可移植性与增加网络透明性的宗旨相违背，所以并不需要这一层，但是节点层是需要保留的。

3.2 容器互访原理

解决不同主机上容器的互访问题，让它们的IP地址互相可见，是搭建覆盖网络的第一步，原理如图5所示。

图5 router转发数据分组

箭头的指向即为在容器172.16.25.90中ping容器172.16.25.101的过程中数据分组的流向，其中router容器承担了数据分组的转发任务。数据分组的转发过程中需要克服的难点如下：

（1）以container1（172.16.25.90)向container2 （172.16.25.101)发送数据分组为例，为了屏蔽容器对于网络拓扑的感知，即两个容器就像处于同一个虚拟网段一样通信，这样的情况下将container1处封装好的MAC帧送到另一个主机的网桥下就可以完成任务，所以需要考虑的是MAC帧的转发。

（2）将一台主机的MAC帧送到另一台主机上并不是一件容易的事情，使用隧道可以解决这个问题。所谓隧道就是一种网络协议被封装到另一个网络协议中以跨过网络传输，数据分组在发送端被封装，在接受端被解开，传输过程中的中间路由器并不在意被封装的协议是什么。在这里显然需要在router之间使用传输层协议来封装链路层的数据分组。

克服了上述两个难题，数据分组就可以在任意两个容器之间传输，但是我们仅仅是完成了端到端之间的联通，而并没有构成一个网络。

3.3 网络拓扑

本文的宗旨是构建一个高度可伸缩的覆盖网络，所以在上述工作的基础上，需要描绘出路由器router的网络拓扑和维护网络拓扑的协议。

图6显示的是5台Docker主机构成的覆盖网络拓扑结构，与图4中的Spines网络结构相似。要维护这个拓扑结构，需要两种协议，这两种协议在Spines中被广泛使用。

（1）Hello协议负责建立、拆除、检测和维护邻居节点之间的连接，节点间要建立连接，首先要向对方发送Hello分组，而且连接建立起来之后，每隔1 s都要向邻居节点发送心跳，以保持联系。

（2）State Flood协议采用“洪泛”的方式来向整个网络传播拓扑结构信息，它让每个节点知道整个网络的结构，这种洪泛法扩散拓扑信息的方法很容易造成网络的拥堵，所以文中覆盖网络不宜过于庞大。

在上文搭建的网络拓扑中，一个数据分组的精准送达需要有路由算法的支持，Spines也给了两种选择：Dijkstra算法和Floyd-Warshall算法，它们都是计算两点之间最短路径的算法。

4 结束语

本文所搭建的覆盖网络将各个主机上分散的容器聚集到一个虚拟网络中，从底层解决了网络数据分组不可达的问题，使得Docker容器可以透明地进行网络编程。它屏蔽了底层的网络拓扑，对于云环境中各种复杂的网络结构有很好的穿透能力。同时本文提出了该网络搭建方案的理论可行性，并没有给出实践过程和数据，也难免存在一些不足之处，需要在后续的研究过程中不断改进和创新。