094、Swarm 中最重要的概念（Swarm01）

参考https://www.cnblogs.com/CloudMan6/p/7845365.html

 

从主机层面来看，Docker Swarm 管理的是 Docker Host 集群。所以先来讨论一个重要的概念 - 集群化（Clustring）

 

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

 

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

 

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

 

实现集群化后我们的思维方式就必须改变了：不再考虑一个一个的服务器，而是将集群看做是一个整体。

 

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

 

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

 

本章，我们会创建 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 mode 上执行部署命令，manager node 会将部署任务拆解并分配给一个或者多个 worker node 完成部署。

 

manager node 负责执行编排和集群管理工作，保持并维护swarm 处于期望的状态。swarm中如果有多个manager node，他们会自动协商并选举出一个leader执行编排任务。

 

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

 

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

 

重要概念    -    service

 

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

 

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

 

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

 

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

 

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