51CTO旗下网站
Docker 1.9新特性：跨主机网络为最大亮点
十一月四号，Docker对1.9进行了发布，新的发行版中添加了很多有趣的特性，下面本文就对新的发行版中的新特性做一个简单的介绍。
作者：高相林来源：dockone| 09:52
【编者的话】11月4日，Docker 1.9 正式发布。其中Docker Swarm 和多跨主机网络正式可在生产环境使用，Docker Engine
提供了全新的存储卷管理系统，Docker Compose
对更多环境提供了更好的支持。所有的这些都为大规模部署生产环境下的分布式应用打下了坚实的基础。本文详细分析了Docker 1.9的种种新特性。
新特性简介
十一月四号，Docker对1.9进行了发布，新的发行版中添加了很多有趣的特性，下面我就对新的发行版中的新特性做一个简单的介绍。
跨主机网络：新的网络设备可以支持用户创建基于多个主机的虚拟网络，使容器间可以跨网络通信。
持久化存储：Docker 1.9 包含一个重新设计的完整存储卷管理系统，这使得用户可以更加容易的从前端来管理这些数据卷。
Docker Swarm
1.0：修复bug并对其进行大量优化。Docker公司在1000个节点上测试了30000个容器，swarm可以如丝般润滑的运行。
Docker Engine 1.9：新的Docker Engine中加入了如下新特性：Dockerfile 的构建时参数、并行镜像 pull、自定义
stop 信号、AWS CloudWatch logging driver和磁盘 I/O metrics。
Docker Compose 1.5：Docker Compose 是一个定义并运行多容器应用的工具，它有如下更新：支持 Windows、Compose
文件中的环境变量、对多环境更好的支持、和 networking 集成和Compose file 校验。
Docker Toolbox：这个工具可以使Mac和Windows支持这些新特性。
Docker Registry 2.2：主要做了以下更新：支持 Google Cloud
Storage、只读模式、支持可配置主机名、基于文件的存在配置、可配置的 HTTP 健康检查和可配置的 HTTP 响应
headers。详细的更新说明可以参照《Docker 1.9 发布：Swarm 和跨主机网络进入 production-ready 阶段》和Announcing
Docker 1.9: Production-ready Swarm and Multi-host Networking。
新特性原理解读
下面就对我比较感兴趣的几点，做一下详细的介绍。
首先，此次发行版最引人注目的就是Docker的跨主机网络了。早在六月的DockerCon大会上Docker公司就宣布已经开始进行对 Docker
Network的试验性工作。在1.9中docker
network命令脱离了实验分支，正式进入了发行版中。有了新的Networking我们可以创建虚拟网络，然后将container加入到虚拟网络中，以获得最适合所部署应用的网络拓扑结构。
和传统的links模式相比，新的Networking有如下三点改进：
可以跨越不同的物理和虚拟主机，连接不同的容器。
用户可以轻松的停止，开启和重启容器，而不用担心破坏容器之间的相互连接。
用户可以以任何顺序创建容器。
在清楚了新的Networking的特性之后，我们来看一下这部分的实现原理。
Networking的跨主机部分使用的时ovs(Open vSwitch)和VXLAN隧道进行实现。关于容器之间的隔离，则使用了iptables。
要清楚Networking的执行流，首先要清楚如下三个概念：
Sandbox：一个Sandbox包含了一个容器的网络栈。其中包括容器的管理接口，路由表和DNS设置。主要是通过namespace和cgroup进行实现。一个Sandbox可以包括多个Endpoint。
Endpoint：一个Endpoint通过加入一个Sandbox来加入一个Network。Endpoint就相当于一个网卡。
Network：一个Network是一组直接互联的Endpoint组成的。它相当于一个二级网络。
清楚了以上三个基本概念之后我们来看看Network的执行流。
指定network的驱动和各项相关参数之后调用
libnetwork.New()创建一个NetWorkController实例。这个实例提供了各种接口，Docker可以通过它创建新的NetWork和Sandbox等。
通过controller.NewNetwork(networkType, &network1&)来创建指定类型和名称的Network。
通过network.CreateEndpoint(&Endpoint1&)来创建一个Endpoint。在这个函数中Docker为这个
Endpoint分配了ip和接口，而对应的network实例中的各项配置信息则会被使用到Endpoint中，其中包括iptables的配置规则和端口信息等。
通过调用controller.NewSandbox()来创建Sandbox。这个函数主要调用了namespace和cgroup等来创建一个相对独立的沙盒空间。
调用ep.Join(sbx)将Endpoint加入指定的Sandbox中，则这个Sandbox也会加入创建Endpoint对应的Network中。
总的来说，Endpoint是由Network创建的，隶属于这个创建它的Network，当Endpoint加入Sandbox的时候，就相当于这个Sandbox加入到了这个Network中来。下面的图可以简要说明三者的关系。
然后是关于Volumes，即持久化存储这一块，Docker也做了比较大的改动。首先最明显的就是--volume不再仅仅作为docker
run的一个flag，也作为一个单独的子命令出现在Docker中。底层也为volume添加了诸如ls、create、inspect和rm等
volume子命令的api。新的volume子命令可以允许用户先创建volume，然后在启动的container的时候进行挂载，此举也更加方便了
volume的管理。
一个简单的例子方便大家快速上手新特性：
$&docker&volume&create&--name&hello&hello&$&docker&run&-d&-v&hello:/world&busybox&ls&/world&
通过这个例子可以创建一个名为hello的volume，然后将其挂载到容器内的/world目录下。
在Docker Engine 1.9中也有一些有趣实用的特性。
前面提到的磁盘 I/O metrics就是一个很实用的特性。这个新特性通过抓取系统内blkio
IoServiceBytesRecursive中的信息对磁盘的I/O进行计算，并通过docker state命令打印出来。所以现在通过docker
state获得的容器信息就变成了如下的形式：
并行镜像 pull也是一个有趣的新特性。现在可以做到如果用户pull的镜像正在被其他进程
pull，进度条会显示这个信息并正确退出。上一个版本的Docker Engine在处理用户pull的镜像正在被其他进程
pull这个问题中，用的是管道，这样的话就很容易出现管道堵塞，就会卡死在&Layer already being pulled by another
新的版本中使用了名为progressreader的工具包，如果遇到上述问题的话，Docker
Engine可以调用这个工具包，通过共享的Broadcaster读取其他进程pull用户所指定镜像的进度，显示这个进度，并做出正确的返回。
最后来讲讲Docker Engine 1.9中的自定义 stop 信号。这个特性可以在Dockerfile 指令中新增
STOPSIGNAL，通过使用这个指令Docker允许用户自定义应用在收到docker
stop所收到的信号。这个新特性主要通过重写Docker中signal库内的stopsignal来支持自定义信号的传递，在上层调用时则将用户自定义的信号传入底层函数即可。
Q：请问ovs和vxlan在吞吐和延迟方面有性能损失吗，有无测试指标?
A：损失肯定是有的，但是具体的指标，Docker方面没有给出测试结果。
Q：本地化创建images咋样了，ovs是本地化吗，物理网卡需要多少带宽?
A：这个本次更新没有提到。ovs的配置会本地化，具体物理网卡多大Docker官方没有给出说明。
Q：1.9之后容器的网络栈是在容器启动之前就配置好了还是启动之后，之前版本的Docker，网络初始化是在容器启动前还是启动后?
A：网络栈启动之前就会配置，启动时候进行加载。之前的Docker也是这样。
Q：docker daemon为跨主机网络增加了哪些配置项，跨主机网络的信息存放在哪里?
A：这个问题太具体了，需要仔细看看代码才知道，我只是大概看了一下，毕竟网络这部分更新太多了。
Q：请问从1.9开始Docker就支持ovs了么，ovs还是需要自行安装吧?
A：1.9开始使用ovs实现networking部分，底层还是调用的ovs。ovs需要自己安装。
Q：也就是说从1.9以后ovs就是直接通过隧道使用，而不是通过route来实现，对么?
A：可以这样理解。
Q：请问volume特性现在有类似kubernetes persist volume的功能吗，对接第三方存储?
A：现在的volume还是对接本地文件夹的，拥有了子命令，更多的是方便使用和管理。
Q：1.9版本特性，是不是更容易建立固定IP类虚拟机的容器?
Q：跨主机的容器网络是由Docker daemon来维护的吗?
A：是通过daemon维护的。
Q：Docker1.9的CRIU方案相对前几个版本有哪些改进，新版本使用热迁移有哪些坑?
A：Docker还是不能热迁移，runC才可以。
Q：跨主机网络功能是全部在docker engine实现的么，还是需要依赖安装好的ovs相关环境?
A：底层还是调用ovs。
Q：如果容器重启或重新生成对已经构建的虚拟网络有影响吗?
A：没有影响。
Q：D能不能给个1.9网络新特性的实际使用的例子?
A：我上面给的那个执行流大概就和实际使用的例子类似，就是创建Network，然后创建ep，创建沙盒，将ep装入沙盒中。实际使用的例子可以参考Docker官方文档。
Q：多个容器共享一个存储如何解决同时写的问题?
A：其实本质上Docker的数据卷就是一个bindmount，其工作原理和Linux主机上的共享卷原理一致。
===========================
以上内容根据日晚微信群分享内容整理。分享人高相林，浙江大学SEL实验室硕士研究生，目前在云平台团队从事科研和开发工作。浙大团队对PaaS、Docker、大数据和主流开源云计算技术有深入的研究和二次开发经验，团队现联合社区将部分技术文章贡献出来，希望能对读者有所帮助。
DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesx，进群参与，您有想听的话题可以给我们留言。
原文链接：
【编辑推荐】
【责任编辑： TEL：（010）】
大家都在看猜你喜欢
头条热点头条关注头条
24H热文一周话题本月最赞
讲师：6508人学习过
讲师：14526人学习过
讲师：880人学习过
精选博文论坛热帖下载排行
Java是当前最流行的程序设计语言之一。本书以Java最新版本Java SE5为基础，涵盖了Java SE5最新特性，由浅入深地介绍了Java SE5的主要内容。...
订阅51CTO邮刊Docker容器跨主机通信方案选哪一种_百度知道
Docker容器跨主机通信方案选哪一种
我有更好的答案
1.用-v挂载主机数据卷到容器内 [plain] view plaincopy docker run -v /path/to/hostdir:/mnt $container 在容器内拷贝 cp /mnt/sourcefile /path/to/destfile 2.直接在主机上拷贝到容器物理存储系统 A. 获取容器名称或者id : [plain] view plai...
采纳率：15%
为您推荐：
其他类似问题
您可能关注的内容
勃兰兑斯的相关知识
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。关注51Testing
Docker跨主机通信解决方案探讨
发表于： 09:20 &作者：佚名 & 来源：IT解忧知识库
推荐标签：
　　背景　　 容器正在被企业应用在越来越多的领域中，比如快速部署环境、简化基础设施的配置流程等等。当你开始在真实的生产环境使用 Docker容器去部署应用系统时，你可能需要用到多个容器部署一套复杂的多层应用系统，其中每个容器部署一个特定的应用系统。此时可能就会遇到如下问题：有多台宿主机，我们事先不知道会在哪台宿主机上创建容器，如何保证在这些宿主机上创建的容器们可以互相联通？　　本文介绍了Docker容器平台中的跨主机通信方案，包括libnetwork，calico，weave，flannel，Kuryr，并对各个方案的原理进行阐述，最后对Calico，Weave，Flannel，overlay(libnetwork)四种常见网络模式进行了对比，为和生产环境的方案选型提供参考。　　一、Libnetwork　　Libnetwork是从1.6版本开始将docker网络部分抽离出来成为一个单独的项目，libnetwork 的目标是定义一个健壮的容器网络模型（Container Network Model），提供一个一致的编程接口和应用程序的网络抽象。从1.9版本开始，docker已经实现了基于Libnetwork和libkv库的网络模式—多主机的Overlay网络。　　1、模型　　libnetwork 引入了容器网络模型（CNM）的概念，CNM 定义了三个新的术语，分别是网络沙箱、Endpoint、Network。　　1）Sandbox。Sandbox包含容器网络栈的配置，包括容器接口，路由表，DNS配置等的管理。
network namespace是常见的一种sandbox的实现。Sandbox中包含众多网络中的若干Endpoint。　　2）Endpoint。Neutron中和Endpoint相对的概念应该是VNIC，也就是虚拟机的虚拟网卡（也可以看成是VIF）。Endpoint的常见实现包括veth pair、Openvswitch的internal port。当Sandbox要和外界通信的时候就是通过Endpoint连接到外界的，最简单的情况就是连接到一个Bridge上。　　3）Network。Network是一组可以互相通信的Endpoints集合，常见的实现包括linux bridge,vlan等。libnetwork中的Network大家可以认为是Neutron中的network即可，更加贴切点的话可以认为是Neutron中的一个拥有一个subnet的network。　　2、结构体对象　　下面我们看下libnetwork为了对外提供这几个概念而暴露的编程结构体：　　1）NetworkController。用于获取一个控制器，可以认为通过这个控制器可以对接下来的所有网络操作进行操作。Neutron中并没有这么一个概念，因为Neutron中的网络是由agent通过轮询或者消息的方式来间接操作的，而不是由用户使用docker命令直接在本机进行操作。　　2）Driver。这里的Driver类似于Neutron中的core_plugin或者是ml2下的各种driver，表示的是底层网络的实现方法。比如有bridge的driver，也有基于vxlan的overlay的driver等等。这个概念和Neutron中的driver概念基本上是一样的。　　3）Network。这里的Network结构体就是对应的上面CNM中的Network，表示建立了一个网络。通过这个结构体可以对建立的网络进行操作。　　4）Endpoint。这里的Endpoint结构体就是对应上面CNM中的Endpoint，表示建立了一个VNIC或者是VIF。通过这个结构体可以对Endpoint进行操作。　　5）Sandbox。这里的Sandbox结构体就是对应上面CNM中的Sandbox，表示建立了一个独立的名字空间。可以类比Nova的虚拟机或者是Kubernetes的Pod，亦或是独立的Docker容器。　　3、API使用步骤　　接着我们看下一般使用libnetwork的方法，具体的步骤一般是下面这样的：　　（1）获取一个NetworkController对象用于进行下面的操作。获取对象的时候指定Driver。　　（2）通过NetworkController对象的NewNetwork()建立一个网络。这里最简单的理解就是现在我们有了一个bridge了。　　（3）通过网络的CreateEndpoint()在这个网络上建立Endpoint。这里最简单的理解就是每建立一个Endpoint，我们上面建立的bridge上就会多出一个VIF口等着虚拟机或者Sandbox连上来。假设这里使用的是veth，则veth的一头目前接在了bridge中，另一头还暴露在外面。　　（4） 调用上面建立的Endpoint的Join方法，提供容器信息，于是libnetwork的代码就会建立一个Sandbox对象（一般这里的Sandbox就是容器的namespace，所以不会重复建立），然后将第三步建立的veth的一头接入到这个Sandbox中，也就是将其放到Sandbox的namespace中。　　（5）当Sandbox的生命周期结束时，调用Endpoint的Leave方法使其从这个Network中解绑。简单的说就是将veth从Sandbox的namespace中拿出来回到物理机上。　　（6）如果一个Endpoint无用了，则可以调用Delete方法删除。　　（7）如果一个Network无用了，则可以调用Delete方法删除。　　4、driver类型　　包含四种类型的driver包：　　Host：主机网络，只用这种网络的容器会使用主机的网络，这种网络对外界是完全开放的，能够访问到主机，就能访问到容器。　　Null：无网络，使用这种网络的容器会完全隔离。　　Bridge：桥接网络，除非创建容器的时候指定网络，不然容器就会默认的使用桥接网络。属于这个网络的容器之间可以相互通信，不过外界想要访问到这个网络的容器呢，需使用桥接网络，有点像主机和容器之间的一座桥，对容器有一点隔离作用。　　Overlay：Overlay驱动可以实现通过vxlan等重叠网络封装技术跨越多个主机的网络，目前Docker已经自带该驱动。　　Remote：Remote驱动包不提供驱动，但是提供一个支持远端传输的方式，驱动的实现可以由你自己喜欢的语言来实现。　　二、Calico　　Project Calico 是纯三层的 SDN 实现，没有使用重载网络，它基于 BPG 协议和 Linux 自己的路由转发机制，不依赖特殊硬件，没有使用 NAT 或 Tunnel 等技术。能够方便的部署在物理服务器、虚拟机（如 OpenStack）或者容器环境下。同时它自带的基于 Iptables 的 ACL 管理组件非常灵活，能够满足比较复杂的安全隔离需求。　　所有的容器均通过配置使用calico-node实现网络互通及访问以太网。　　基本原理　　拓扑图　　模块间的关系（控制平面）：　　Calico把每个的协议栈认为是一个路由器，然后把所有的容器认为是连在这个路由器上的网络终端，在路由器之间跑标准的路由协议——BGP的协议，然后让它们自己去学习这个网络拓扑该如何转发。所以Calico方案其实是一个纯三层的方案，也就是说让每台机器的协议栈的三层去确保两个容器，跨主机容器之间的三层连通性。对于控制平面，它每个节点上会运行两个主要的程序，一个是Felix，它会监听ECTD中心的存储，从它获取事件，比如说用户在这台机器上加了一个IP，或者是分配了一个容器等。接着会在这台机器上创建出一个容器，并将其网卡、IP、MAC都设置好，然后在内核的路由表里面写一条，注明这个IP应该到这张网卡。绿色部分是一个标准的路由程序，它会从内核里面获取哪一些IP的路由发生了变化，然后通过标准BGP的路由协议扩散到整个其他的宿主机上，让外界都知道这个IP在这里，你们路由的时候得到这里来。　　由于Calico是一种纯三层的实现，因此可以避免与二层方案相关的数据包封装的操作，中间没有任何的NAT，没有任何的overlay，所以它的转发效率可能是所有方案中最高的，因为它的包直接走原生TCP/IP的协议栈，它的隔离也因为这个栈而变得好做。因为TCP/IP的协议栈提供了一整套的防火墙的规则，所以它可以通过IPTABLES的规则达到比较复杂的隔离逻辑。　　Calico已知问题　　（1） 只支持tcp,udp,icmp,icmpv6协议，如果需要支持其他L4协议，需要选择其他网络模式；　　（2） 没有对数据路径进行加密，因此对于不信任的网络是不安全的；　　（3） 在公众网络上需要使用-ipip选项，该选项采用IP-over-IP的效率很低；　　（4） 通常 跑在一个大二层的网络里，对于大二层网络其实就是没有任何三层的网关，所有的机器、宿主机、物理机在二层是可达的，此时任何一个都会有一定的硬件风险会让整个大二层瘫痪；　　（5） Calico跑在了一个三层网关的物理网络上时，它需要把所有机器上的路由协议和整个物理网络里面的路由器的三层路由全部用BGP打通。这其实会带来一个问题，这里的容器数量可能是成千上万的，然后你让所有物理的路由学习到这些知识，这会给物理集群里的BGP路由带来一定的压力　　Calico既可以单独配置也可以作为docker libnetwork的一个驱动使用。　　三、Weave　　其中Weave是由Zett.io公司开发的，它能够创建一个虚拟网络，用于连接部署在多台主机上的Docker容器，这样容器就像被接入了同一个网络交换机，那些使用网络的应用程序不必去配置端口映射和链接等信息。　　外部设备能够访问Weave网络上的应用程序容器所提供的服务，同时已有的内部系统也能够暴露到应用程序容器上。Weave能够穿透防火墙并运行在部分连接的网络上，另外，Weave的通信支持加密，所以用户可以从一个不受信任的网络连接到主机。上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-7)，我们将立即处理。
搜索风云榜
51Testing官方微信
51Testing官方微博
测试知识全知道}