Swarm概念及功能

Swarm概念介绍
从主机层面来看，Docker Swarm 管理的是 Docker Host 集群。有一个重要的概念 - 集群化（Clustring）

集群化的概念
服务器集群有一组网络上互相连接的服务器组成，他们一起协同工作。一个集群和一堆服务器最显著的区别在于：

集群能够将单个系统那样工作，同时提供高可用、负载均衡 和 并行处理。

如果在部署应用和服务时选择的是多个独立的服务器而非集群，资源的整体利用率则很难达到最优，因为无法提前知道如何分布这些应用才能达到资源利用的最大化。而且，应用使用资源的趋势是有波动的，早上某些服务器可能需要大量的内存，而下午使用量就降下来了。提前指定应用应该运行在哪个服务器会丧失业务的弹性，当某个服务器宕机了，我们不得不手工将受影响的应用迁移到其他服务器上。

使用集群部署应用时，只考虑需要多少内存和CPU，而不是考虑会使用哪台的CPU和内存。我们不应该关心应用会被部署在哪里，我们关心的是运行这个应用需要哪些资源，然后将它部署到集群，集群管理程序（比如Docker Swarm）会帮你搞定这些细节。

集群整理容量的调整是通过往集群中添加和删除主机节点实现的。但不管做怎么样的操作，集群始终是一个整体。

Docker Swarm Mode
Docker v.112是一个非常重要的版本，Docker重新实现了集群的编排方式。在此之前，提供集群功能的Docker Swarm 是一个单独的软件，而且依赖外部数据库（比如 Consul、etcd 或者 Zookeeper）

从 v1.12 开始，Docker Swarm 的功能已经完全与 Docker Engine 集成，要管理集群，只需要启动Swarm Mode。安装好 Docker ，Swarm和服务发现就已经存在，服务发现也在那里了，而且不需要安装Consul等外部数据库。

相比Kubernetes ，用Docker Swarm创建集群非常简单，不需要额外安装任何软件，也不需要做任何额外的配置

重要概念
Swarm
swarm 是运行Docker Engine的多个主机组成的集群

从 v1.12开始，集群管理和编排功能已经集成到 Docker Engine 中。当Docker Engine 初始化了一个swarm 或者加入到一个存在的swarm时，他就会启动 swarm mode。

没启动 swarm mode 时，Docker 执行的是容器命令。运行swarm mode 后，Docker 增加了编排service的能力。

Docker 允许在同一个Docker Host 上即运行 swarm service，又运行单独的容器。

node
swarm 中的每个 Docker Engine 都是一个node，有两种类型的node：manager 和 worker

为了向swarm 中部署应用，我们需要在manager node 上执行部署命令，manager node 会将部署任务拆解并分配给一个或者多个 worker node 完成部署

manager node 负责执行编排和集群管理工作，保持并维护swarm 处于期望的状态。期望表示在所有的swarm集群服务器当中，永远保持容器的总量不变。swarm中如果有多个manager node，他们会自动协商并选举出一个leader执行编排任务。

在上一个文档的部署中，知道了除了一个leader之外，还有一种Reachable状态，当leader宕机之后，会有一个Reachable被选为leader继续管理集群工作

worker node 接受并执行由manager node 派发的任务。默认配置下manager node 同时也是一个 worker node，不过可以将其配置成manager-only mode，让其专职负责编排和集群管理工作。

worker node 会定期向manager node 报告自己的状态和他正在执行的任务状态，这样，manager 就可以维护整个集群的状态。

service
service 定义了 worker node 上要执行的任务，swarm的主要编排任务就是要保证service 处于期望的状态下。

如：在swarm 中启动一个http访问，使用的镜像是httpd:lastes，副本数是3

manager node 负责创建这个service ，经过分析指导需要启动3个httpd 容器，根据当前各worker node 的状态将运行容器的任务分配下去，比如worker1 上运行两个容器，worker2上运行一个容器。

运行了一段时间，worker2 突然宕机了，manager 监控到这个故障，于是立即在worker3 上启动了一个新的httpd容器。

这样就保证了 service 处于期望的三个副本状态。

service是swarm中最小的管理单元，容器在service中运行。swarm不能去直接管理容器，而是间接的通过service来管理容器

swarm功能亮点
与Docker Engine集成的集群管理：使用Docker Engine CLI创建大量Docker Engine，可以在其中部署应用程序服务。不需要其他编排软件即可创建或管理群体。这样的集群管理与k8s的性能有所偏差。可以算作这样的集群管理已经接近淘汰。

分散式设计： Docker Engine无需在部署时处理节点角色之间的差异，而在运行时处理任何专业化问题。可以使用Docker Engine部署节点，管理者和工作者。这意味着可以从单个磁盘映像构建整个群集。

需要注意的一点，manager node不是生产环境中最多有七台，而且最好是奇数数量的manager node，下面有说到

声明性服务模型： Docker Engine使用声明性方法来让您定义应用程序堆栈中各种服务的所需状态。例如，您可能描述了一个包含Web前端服务和消息队列服务以及数据库后端的应用程序。

缩放比例：对于每个服务，您可以声明要运行的任务数。当您放大或缩小时，群管理器会通过添加或删除任务以保持所需状态自动进行调整。

缩放比例：对于每个服务，您可以声明要运行的任务数。当您放大或缩小时，群管理器会通过添加或删除任务以保持所需状态自动进行调整。

任务可以理解为容器数量

所需状态协调：群集管理器节点不断监视集群状态，并协调实际状态与您表示的所需状态之间的任何差异。例如，如果将服务设置为运行一个容器的10个副本，并且承载其中两个副本的工作计算机崩溃，则管理器将创建两个新副本来替换崩溃的副本。群管理器将新副本分配给正在运行且可用的服务器。

多主机网络（overlay）：您可以为服务指定覆盖网络。群管理器在初始化或更新应用程序时会自动将地址分配给覆盖网络上的容器。

服务发现：群集管理器节点为群集中的每个服务分配唯一的DNS名称，并平衡正在运行的容器。可以通过群集中嵌入的DNS服务器查询群集中运行的每个容器。

负载平衡：可以将服务端口公开给外部负载平衡器。在内部，群集可指定如何在节点之间分配服务容器。

分为外部和内部的负载均衡

外部负载均衡：集群管理器的入口，也就是使用第三方的负载均衡服务器

内部负载均衡：根据服务的dns，在集群内进行分配

默认情况下安全：群集中的每个节点都执行TLS相互身份验证和加密，以保护自身与所有其他节点之间的通信安全。您可以选择使用自签名根证书或来自自定义根CA的证书。

滚动更新：在推出时，您可以将服务更新逐步应用于节点。群管理器使您可以控制将服务部署到不同节点集之间的延迟。如果有任何问题，可以回滚到该服务的先前版本。

不同节点的功能
从上面的内容中指定swarm分为两种节点，manager node和worker node.

Docker Engine 1.12引入了swarm模式，可以创建一个或多个Docker Engine集群，称为swarm. 一个群集由一个或多个节点组成

manager node管理节点
管理器节点处理集群管理任务：

维持集群状态
调度服务
服务群模式HTTP API端点
使用Raft实施，管理人员可以维护整个群集及其上运行的所有服务的一致内部状态。出于测试目的，可以由一个管理器运行一个集群。如果单管理器群中的管理器发生故障，那么您的服务将继续运行，但是您需要创建一个新的集群以进行恢复

为了利用群集模式的容错功能，Docker建议您根据组织的高可用性要求实现奇数个节点。 如果拥有多个管理器，则可以从管理器节点的故障中恢复，而无需停机

一个由三名经理组成的群体最多可以容忍一名经理的损失

五个管理器群最多可同时损失两个管理器节点

N管理器群集最多可以承受(N-1)/2管理器的丢失

Docker建议最多为七个管理器节点

重要说明 ：添加更多管理器并不意味着增加可伸缩性或更高性能. 通常，情况恰恰相反。manager越多越不好管理

worker node工作节点
工作程序节点也是Docker Engine的实例，其唯一目的是执行容器。工作程序节点不参与Raft分布式状态，不制定调度决策或服务于群体模式HTTP API。

可以创建一个manager node的群集，但是如果没有至少一个管理节点，则不能有一个worker node默认情况下，所有manager也是worker node。在单个管理器节点集群中，您可以运行诸如docker service create类的命令，而调度程序会将所有任务放在本地引擎上.

为了防止调度程序将任务放置在多节点集群中的管理器节点上，请将管理器节点的可用性设置为Drain . 调度程序会以” Drain模式正常停止节点上的任务，并在Active节点上调度任务. 调度程序不会将新任务分配给具有Drain可用性的节点。

本文地址：https://blog.csdn.net/weixin_46389583/article/details/109637682