Swarm架构

图1 Swarm架构

我们先看一下Swarm是什么？Swarm，是Docker官方推出的，它的特点就是跟Docker本身有很好的集成，另外，它也是一个非常简单易用的工具，所以目前吸引了很多开发者在用。

Swarm是Docker公司继Docker Engine之后推出的很重要的集群管理系统和容器编排与调度系统。架构底层是集群的机器资源，可以是一些物理机也可以是一些虚拟机，上面经过Swarm这一层把容器调度和部署到这些机器上去，它对外提供跟Docker类似的API。

具体来看，Swarm的框架分成三块，第一块是Engine，第二是Manager，第三是KV store。它有几个特点，第一依赖外部存储来完成节点发现并保证一致性；第二，Manager只跟Daemon通信，不跟Agent通信；第三，Manager可以有多副本,这是为高可用设计的，采用一主多热备模式，所有manager都同时连接所有Daemon，备转发请求至主，另外，它依赖外部KV选主。

API

Swarm提供的API，主要是有这么几类：

● 集群类：info events
● 容器类：get/list、create、start/stop等
● 镜像类：get/list、push、pull、tag等
● 数据卷类：get/list、create、delete
● 网络类：get/list、create、delete等

调度

资源维度层面有三个： CPU 、Memory、 端口，CPU / Memory支持超卖；调度策略有两种：spread / binpack，另外，它不支持优先级、抢占。

它比较有特点的一些功能有两个，一个是叫节点约束，约束可以有两种类型，比如说你可以约束我这个节点是哪一个，你可以给节点去一个名字或者打一个标签什么的，另外一个可以通过打标签去选择一种机器，你在部署的时候，可以指定这些容器部署到哪些机器上去。

节点约束：

● 节点名：constraint:node==XXX
● 标签：constraint:key==value

亲和性也有两种，一种是image，一种是service，比如我有一个应用镜像很大，我不希望它在集群各个地方去部署，我希望他部署下来已经下载镜像的地方，这样的话可以减少一些启动的时间和下载的过程，你可以说我这个服务不是跟某个镜像做亲和，也可以跟某个服务做亲和。

亲和性：

● 镜像：affinity:image==foo
● 服务：affinity:service==foo

总结一下Swarm这个产品，Swarm整体来说有几个特点，第一个是部署简捷，只有三个模块，外部的依赖只有KV Store和Docker Daemon这两个，所有组件都容器化。第二高效友好的用户交互，高度兼容Docker Engine API，可直接使用Docker Client。第三是灵活的约束与亲和性描述，可以在一定程度上弥补调度策略的不足。

同时，我们也看到它有一些不足的地方，首先一个不足的地方就是它是容器级别的API，所有的API都是针对单个容器的，抽象层次较低。其次，响应式设计，不方便执行常驻后台的操作，它在内存中不保存任何的状态，所有的状态都是从Docker上统计过来的。有一个好处，它一旦挂掉了，能够很方便地恢复状态，但也有一些坏处，比如你要跑一个离线的任务，就不太好做。除此之外，它依赖定期同步跟Docker Engine保持一致状态。

Swarm Mode

针对Swarm这个产品的一些不足，从1.12版本开始，Docker就提供了Swarm Mode的功能，这个功能是将Swarm的集群管理、容器调度功能集成进Docker Engine，并且提供Service级别抽象和自带的负载均衡，它从容器级别的调度器进化到了服务级别的调度器。

架构

图2 Swarm Mode架构

它的架构比Swarm更简单一些，首先就是它没有任何的外部依赖，只要你装 Docker Engine，它就可以构成一个容器集群，DockerDaemon本身会兼Engine、Manager、Agent三职。Managers之间通过RAFT协议组成分布式强一致性KV Store，Manager与Worker的Daemon不通信。

同时，它也是有高可用设计的，Manager数量需要大于等于3才可以实现高可用，它也是一主多热备，另外也可以动态添加/删除Manager，如果有的机器宕机或者挂掉了，你不需要把这个机器再恢复起来，很多系统对Manager控制器的机器是有依赖的。如果一旦挂掉了你只能把它修好之后再上来，但是这个是不需要的，你可以任意在里面编程。这样他会通过RAFT协议把原来集群状态信息统一到Manager上去，这样有实现了高可用。

Swarm Mode API

在刚才Swarm的API之上，多提供了两类的API:

集群管理类:

● init、join、leave
● token

服务类:

● get/list
● create、delete、update
● inspect、ps

同时，Swarm的API有两个特点，它分两类，一类是像Swarm、Service、Network类，只有Manager能处理的。还有一类容器、镜像、数据卷类，所有节点都能处理。另外它的API还是高度兼容旧的API，你可以拿低版本的去访问Swarm mode的集群。

Service

我们来看一下Swarm Service的概念，它提供了三级的概念：

● Service：相同功能的一组容器
● Task：任务调度单元，由Manager生成，同步至Worker
● Container：Task落地

另外，还提供Rolling Update功能。

在Swarm mode里面Service分为两类，一类是有Replicated Service，一类是Global Service。

Replicated Service：

● 用户指定副本数
● Reconciled：自动确保副本数
● constraint

node.id node.hostname：

● node.role
● node.labels engine.labels

Global Service：

● 每个节点有且仅有一个容器
● 添加加点时自动扩展
● 可附加constraint

网络模型方面，支持overlay网络，同一网络内，服务名、容器名可解析；一个服务一个网络；服务发现支持不同服务可加入同一个网络。

Routing Mesh

下面我们看一下Swarm自带的负载均衡，它取的名字叫做Routing Mesh，Service自带的负载均衡是基于LVS，主要有两种模式，

VIP模式：每个服务一个VIP，通过LVS实现；服务名解析至VIP；

DNS模式：服务名解析至容器IP，RoundRobin方式。另外，服务发生变化时，自动调整后端。

总结一下Swarm Mode的产品，第一个它是无任何依赖，可以安装Engine+一个命令，无中心架构。第二个它可以部署高可用服务，你可以在集群这边进行访问的，比如说你的容器只布在了三台机器，这个集群所有的机器都可以访问到这个服务，这样的话就很容易做成高可用的。再一个Secure by default,自带证书颁发、更新功能，Manager与Worker之间通过SSL连接。

当然它也有一些不足的地方，第一个只有Service级抽象，Stack级抽象仍无API，另外，部署有状态服务比较复杂。第二，Service API有很多容器特性不支持，如host network、host pid、privileged等。还有一个缺点，它无法自举，是需要手工init的。

本文转自微信公众号： CSDN云计算