Docker 1.12 Swarm 模式剖析

Docker 1.12 在 2016 年 7 月 28 日正式 GA，除了大量的在使用上的改进和 bug 修复外，最引人瞩目的是原生支持了 Swarm 模式。

熟悉 Docker 的读者都知道 Docker Swarm 是官方三剑客之一，提供了轻量级容器云的支持，以性能卓越出名，跟 K8s 面向应用的较为复杂的容器云方案一时瑜亮，各有千秋。

本次 Swarm 模式特性的发布可谓重要变革，不仅仅是减低使用门槛那么简单，还引入了不少新的围绕应用的特性，从中可以一探 Docker 团队对于容器云的理念。

基本概念

Swarm 定义为一组合作在一起的 Docker 主机集群，由节点组成，每个节点都是一个独立的 Docker 主机。

集群中包括两种节点：管理节点和工作节点。参考 k8s 的结构，也是如此。

• 管理节点：负责对任务进行调度和其它管理任务，多个管理节点通过 Raft 协议组成集群；
• 工作节点：负责运行具体的任务，管理节点可以同时作为工作节点。

如果把所有节点配成管理+工作，那就是绝对的对等了，实际上从性能角度考虑，管理节点数量不宜过多，并且相互之间的互联网络要保证好的质量。

此外，还引入了服务的概念。服务也包括两种类型：

• 复制服务（replicated services）：类似 k8s 中复制集的概念，保持一定数量的相同任务在集群中运行；
• 全局服务（global services）：类似 k8s 中 daemon 的概念，每个工作节点上运行一个。

一个服务由多个任务组成，一个任务即一个运行的容器。

主要特性

负载均衡和服务地址管理

k8s 中让人印象深刻的是它的服务自带了负载均衡和服务地址功能，Swarm 也通过 ingress load balancing （基于 ipvs 的四层代理）来实现，为每一个服务提供一个 DNS 地址，维护一个公共的端口。这点上跟 k8s 默认方式略有不同，但效果是一致的，都保证了无论容器如何变化，任意节点对应用的访问保持不变。

跨主机网络

这点还是基于 overlay 网络来实现。

监控管理

基于服务的概念，对运行状态进行管控，自动保持服务的运行状态。

支持命令

目前围绕对集群和服务进行管理，命令都很容易理解。

• swarm init
• swarm join
• service create
• service inspect
• service ls
• service rm
• service scale
• service ps
• service update

Swarm2k

很有意思的项目，就是基于最新的 Swarm 模式来在全球范围内构建一个超过 2000 个节点，1 M 个容器的大集群。

目前已经达到预定目标，具体可以关注 [这里]（https://github.com/swarm2k/swarm2k/blob/master/PROPOSAL.md）。

这个项目的成功，也再次证明官方的 Swarm 方案，在性能上确实首屈一指！

小结

跟 Docker 技术自身的火爆不同，Docker 团队一直以来就面临着未来发展的困境，几乎所有人都希望他们只安心做好容器引擎。但作为一个商业化公司来说，这样下去毫无疑问是自掘深坑。于是，他们积极的在基于容器的各种平台和工具上进行构建。包括三件套、包括容器云，都是很好的尝试。

从 Swarm 的特性来看，Docker 团队在应用为中心这点上是认同了 K8s 的理念的，但是自身又同时保持了一定的独立性。这对于 Docker 来说自然是利好。但是目前来看，并没有完全解决团队发展的困境。

云计算容器服务该何去何从

容器技术最近很火，各家项目纷纷提出自己的支持方案，比如 OpenStack、CF、Mesos，以及一堆本身就基于容器的平台方案，更是跟容器技术脱不开关系。

容器是个啥？它不是虚拟机这样单纯的底层虚拟化，也不是纯应用，它恰好位于两者之间，位置极其重要。简直就像是 IP 协议层一样，无论自顶向下还是自底向上都无法绕开。

这也直接导致了暧昧已久的 IaaS 领域和 PaaS 领域正式开始正面的冲突。

在 IaaS 工程师们看来，做 PaaS 无非就是提供几个应用模板嘛，原来虚机不好做，现在有了 Docker，瞬间给你把服务整起来。更别提还有最近出来搅局的 hyper，虚机号称要跟容器比性能，那原来熟悉虚机的工程师可是太喜欢了。

而在 PaaS 工程师们看来，IaaS 就该老老实实地做底层物理资源给抽象成虚拟资源的事。原来底层都是虚机的时候，感觉好复杂，什么 SR-IOV，Libvirt/KVM，SDN，Overlay，Ceph……搞 PaaS 的人一般看不懂。而现在有了一堆现成提供 Docker 的容器平台，再往上就是应用了，都是做软件的人可以做的事情了，所以以后其实 IaaS 就没那么关键了。

这些讨论就像当年的单内核和微内核之争一样，是不光涉及到技术，还涉及到模式的关键战役。

可以说，看起来现在已经到了一个很关键的节骨眼上，中间这一层的设计将决定未来至少十年内云计算产业的形态。

当前状况

姑且放下这些争论，我们来看一下 IaaS 领域的 Top 开源项目 OpenStack 现在是怎么对待容器的。

目前有三种方案：

• Nova-Docker：把容器作为虚机管起来。基本上其它组件都不需要动。唯一的问题就是容器毕竟不是虚机，比如需要提供一些额外的参数支持啦，需要引入组的概念啦，需要性能的优化啦。这导致玩 PaaS 的人很不喜欢。
• Heat Docker Driver：用 Heat 来管容器。Heat 大家都知道，是个十分灵活且强大的解释引擎，理论上 Docker 需要的支持它都能有。唯一的问题是 Heat 毕竟是个解释引擎，它本质上还是要基于其它服务提供的 API。由于不是个运维引擎，导致运行时的管理没法保障，比如自动的资源调度啊，网络功能啊，等等。如果这些都做了，那就等于在更高一层上重复发明轮子了。
• Magnum：玩容器的人看问题当然基本上都是从应用层往上开始考虑。一帮人兴冲冲跑去 Nova 项目谈，应该怎么支持基于容器的 DevOps 啊，应用模板啊，Nova 组一帮做系统的人就傻了，这事我们咋能干？这分明是 PaaS 该做的事情。但架不住大家都觉得 Docker 很火啊，我们肯定还是要玩点花样的，于是一个新的项目诞生了。但玩应用的人毕竟不懂系统，调研了下，发现现在能管理 Docker 的开源方案还真有几个，比如 Swarm 和 Kubernetes。太好了，那么，怎么把 Swarm 和 Kubernetes 这样的 PaaS 平台给集成到 OpenStack 这样的 IaaS 平台上呢？这个听起来好像也不懂唉，有人又想起 Heat 来了，一拍脑袋，可以先拿 Heat 来装一套啊。每次需要的时候就调个 Heat 命令，动态的装一套。所有问题看起来都解决了，皆大欢喜啊，真是皆大欢喜！

就这样，最为关键的容器服务提供这一层反而有意无意的被大家忽略了。

思考云计算

某位名人说过，我之所以能看得远，是因为站在了前人的肩膀上。

让我们抛开系统和应用之争，姑且也大胆地站在前人的肩膀上来重新发明轮子。

首先还是要忍不住重复强调，信息技术的领域最为核心的思想就是分层和抽象。历史上，在不同位置进行分层和抽象，诞生了小型机，诞生了处理器，诞生了编程语言，诞生了 Web 服务，诞生了云计算……

抛开 IaaS，抛开 PaaS，云计算到底要提供啥？这个问题大家都知道，是服务。

啥叫服务？用户需要操作系统，可以直接给你一个；用户需要一个运行环境，可以直接给你一个；用户需要一套软件，也可以直接给你一个；用户需要一套方案，这个目前还没法直接给你一个，属于外包公司的业务。

那么，对于云平台的设计者来说，就是要提供这些不同层次的服务给用户，这才有了所谓的 IaaS 和 PaaS。所以，要记住，各种 XaaS 是呈献给用户的服务层次的不同，根本不是设计层次和技术方案的不同。

就好比你买了一个手机，可以玩游戏，也可以打电话。游戏和电话是手机提供给你的不同服务形态而已，并非说游戏是一种特殊的手机，电话是另外一种特殊的手机。

OK，那么，下面的问题就是讨论为了满足用户的这些需求，在设计上该如何分层。前人总结出了计算、存储、网络这三个根本的基础业务。其中计算又是最核心和最直接的。

我们来看直接面向用户的计算业务。数据中心里面放着的都是物理机器，物理机器上可以装操作系统，操作系统上可以装各种软件，可以运行虚拟机，可以运行容器。无论物理机、虚拟机、容器，都是属于计算资源。统统都应该用云平台给实现和供应出来。

如果说 IDC 是让用户可以拿物理机作为计算资源载体，那么现在的云计算是更进一步，让用户可以直接忽略计算资源的实际载体，无论是操作系统还是应用，直接提供给你即可，无需关心具体的载体。

总之一句话，云计算就是要方便提供计算资源！

问题与方向

Magnum 目前被认为 OpenStack 里面最有活力的容器项目，但是很可惜，一开始的路子就是偏的。

Magnum 的定位是提供一套 OpenStack API，底下可以兼容/依赖多种第三方的容器管理平台。OpenStack 本来就是要做一套资源管理平台，现在是用别人的，意味着这跟 OpenStack 其实关系不大。但是如果抛开 OpenStack，上面封装的一套 OpenStack API 又没有了意义。第三方的管理平台都有自己现成的 API。

真正的 Container as a Service，其实应该是在 OpenStack 中实现一套容器平台，而不是在 OpenStack 中安装了别人的一套平台，然后进行了 API 的封装。

或许有人会猜测，之所以不做底下的实现，可能跟 Nova-Docker 有关。

如果只谈技术，其实很容易在 Nova 中实现真正的 Container as a Service。在 Nova 看来，都是计算节点，但计算节点可以带上各自的类型，比如有的计算节点是物理机、有的是虚拟机、有的是容器甚至容器组。不同的类型意味着底层不同的驱动。用一套抽象的资源调度的框架（参考 Mesos 的二层调度机制），带上不同的底层 framework，问题很容易得到解决。

但偏偏是现在已经有了 Nova-Docker，已经有了 Magnum，不知道要经过多少波折才可能走到这个方向上来。或许在 OpenStack 的大环境下，是一件太困难的事情了。

或许，这就是开源的魅力，分分合合，曲折中前行。

OpenStack Magnum 项目简介

背景

Magnum 项目是 2014 年 11 月加入 OpenStack 的年轻项目，由 Rackspace主导发起，其定位是提供容器即服务（Container as a Service）的 API 框架，计划在 2015 年 10 月推出的 Liberty 版本时成熟。

我们知道，目前 OpenStack 中 Nova 项目已经通过 nova-docker 的形式支持了 Docker 容器（把容器当虚机管）。但在实际使用中，会发现有不少的问题。毕竟，Nova 设计的初衷是管理虚拟机，而容器跟虚拟机在行为和特性上存在较大的不同，无论是管理层还是底层的虚拟化支持层都完全不同。而且，让 Nova 支持各种各样的容器机制（Docker、OpenVZ、Rocket、LXC 等）要进行修改的地方着实不少，可能跟现有框架形成冲突。

此外，Heat 项目也支持 Docker 官方插件，来直接通过 Docker 的 REST API 来管理容器，并且支持容器的高级特性。然而，不支持资源的调度和网络功能。

社区之所以接收 Magnum 项目，一方面是容器技术现在着实火热，另一方面，也是往更高一层发展提供更好的支持。

设计原理

Magnum 在设计上，希望调用其它的容器管理平台的 API 来实现功能，自身作为一套 API 框架，目前支持 Docker、Kubernetes、Swarm 等。主要优势包括多租户、多后端框架、完善的容器功能、支持资源调度等。

如果说 Nova 是一套支持不同 Hypervisor （KVM、VMWare 等虚拟机平台）的 API 框架，那么 Magnum 则是支持不同容器机制的 API 框架。

基本概念

从小往大的顺序：

• Node：容器运行的节点，可以是裸机、虚拟机甚至容器。
• Bay：一组 Node 的集合（底层同一个驱动机制），是 Magnum 中容器调度的基本单元。Bay 在租户之间是隔离的。
• BayModle：类似于 Nova 中的 flavor，定义一个 Docker 集群的规格。

下面几个是来自 Kubernetes 中的概念。

• Container：容器。
• Pod：最小的管理单元，一个或多个相互关联的容器（一般运行相同应用），运行在同一个 Minion Node 上，共享同样的数据挂载和网络空间，代表某种应用的一个实例。
• Service：由一个或者多个 Pod 组成，代表一个抽象的应用服务，对外呈现为同一个访问接口，这样访问可以通过 service 来路由，而无需具体知道 Pods 的地址。
• ReplicationController：对 pod 指定副本数，RC 可以保证一直存在该数目的副本存在并运行。

主要服务

主要服务有两个，Magnum API 和 Magnum Conductor。

前者提供调用的接口，接收 python-magnumclient 的请求。可以同时运行一个或者多个实例。这些请求最终扔给 AMQP 消息队列，发送到 magnum-conductor 服务。

后者运行在控制节点上，具体负责将 client 的请求转发到具体的后端机制（Kubernetes API 或者 Docker API），目前限制只能存在一个实例。