前言
在云原生的世界,经过十多年的进化,Docker已经形成了较完备的“后勤”
保障服务和建立了荣辱与共的“密友圈”
。用一句话可以概括:“Docker走遍天下,Swarm功不可没”
。
因此,我们需尽可能做到对Swarm
有充分的认识,才能笑傲运维,笑傲云原生。今天博主带着各位继续深挖Swarm
,熟练掌握它的核心能力。
Q:如何管理Swarm cluster
上图是一个基于Swarm
的docker集群部署/运行架构图,在此图中你可以获得这样一个生产链条(基于Docker engine
):
序号 | 操作 | 目的 |
---|---|---|
1 | docker compose | 基于Compose 完成基础的容器编排并生成镜像。 |
2 | docker swarm init | 通过Docker engine 创建Swarm集群。 |
3 | docker service | 通过Swarm 向集群发布服务,一键启动多容器的集群。 |
一句话总结
:通过Swarm + Compose的组合,你完全可以掌握docker的集群化管理之钥。那么,针对Swarm而言,它是怎么实现分布式容器部署并如何掌握它的动态管理机制呢?
1. Raft算法
这里,首先不得不提Raft算法了,在多数支持分布式的工具里,你都可以看到它的身影。
Raft是一种更为简单方便易于理解的分布式算法,主要解决了分布式中的一致性问题。相比传统的Paxos算法,Raft将大量的计算问题分解成为了一些简单的相对独立的子问题。——百度百科
博主不对算法本身做太多解释(如感兴趣,可查阅相关资料),我们只需知道这个算法是实现分布式选举的重要支撑。比如节点down了怎么办?
2. 心跳机制
在master-slave
模式中,通常存在心跳检测机制。在manager节点中,我们通过docker info
命令,可得知Swarm的心跳(默认5s):
一旦manager出现down,会立即开始选举,创建新的leader;或者worker节点down,任务也会在其他worker进行自动迁移。
3. 动态扩容和缩容
Swarm
支持动态扩容和缩容,什么意思?比如当前集群有2个worker,你可以随时邀请新的worker
加入,也可以对已有的worker说:“go away”
。只需要选择执行以下2个:
序号 | 操作 | 目的 |
---|---|---|
1 | docker swarm join – token xxx [MANAGER_HOST_IP] :2377 | 加入swarm 集群 |
2 | docker node update --availability drain [NODE_NAME ] | 剔除 swarm集群中的成员 |
3 | docker service scale [SERVICE_NAME] =扩展后的副本数量 | 动态分配任务 |
那么,如何验证它的扩容或缩容“如你所愿”
?
简单,我们可做如下实验。前提是根据上篇文章(快捷方式)中的步骤,新建一个cluster(其中包含1个manager,2个woker)。
3.1 发布一个3副本的Service
3.1.1 查看当前cluster nodes
在manager节点中,通过docker node ls
,得知当前实验集群中,有1个manager,2个worker,且看下图:
3.1.2 发布service
接下来,你可以通过如下命令,发布一个3副本的service(以nginx镜像
为例):
# --replicas指定副本个数,--network指定运行网络,--name指定容器名,-p指定映射端口
docker service create --replicas 3 --network service-nginx --name my_nginx -p 8888:80 nginx
发布完成后,可通过docker service ps my_nginx
命令,查看服务的运行节点:
至此,你成功完成了Swarm集群
的创建并发布了一个service(my_nginx
),且每个节点(含manager)均运行了1个副本,接下来我们就可以进行情景推演了。
3.2 删除 worker node
3.2.1 剔除worker1
我们先来一个剔除worker的操作吧。在manager节点中,可以通过docker node update
命令,改变worker1的状态为drain。
提示
:drain节点代表不再受manager节点的支配,游离于集群之外。
docker node update --availability drain docker-worker1
执行后,结果为:
3.2.2 查看service运行节点
此刻,你可以通过docker service ps my_nginx
命令观察到如下结果:
因为worker1节点罢工,所以woker2节点自动完成副本叠加,保障集群仍然是3副本运行状态。当然,你也可以通过登录worker1和worker2节点,查看(输入docker ps
)各自认领的Task
:
3.3 新增 worker node
上一节演示了worker down的情景,这一节我们再看看扩容后会发生什么。这里的扩容其实有2种实现方式:一种是通过docker swarm join
实现,另一种就是通过docker node update
实现。这里只呈现第2种方式。
3.3.1 恢复worker1
首先通过docker 把worker1恢复为active(待命状态)。
提示
:active节点代表受manager节点的支配,是集群的一份子。
接下来,我们通过如下命令完成:
docker node update --availability active docker-worker1
结果为:
3.3.2 更改service scale
我们在manager节点中,通过增加副本实现service自动扩容,命令如下:
docker service scale my_nginx=6
结果显示,每个node均认领了2个Task
:
4. docker down
当然,你也可以通过systemctl stop docker
服务,制造“事故现场”
,比如worker1宕机了:
此刻在manager节点中,再查看cluster nodes,发现worker1节点已Down:
接下来重复3.1.2
节的动作,你会发现worker1真的光荣退休了:
结语
Docker Swarm
提供了很多适合各类生产场景的选项和操作,你可以根据实际情况进行选择和部署。通过Docker集群化管理,可以免去不必要的重复操作,提高工作效率。
各位盆友,如有任何疑问,可留言O。
系列回顾
微服务实战系列之玩转Docker(十)
微服务实战系列之玩转Docker(九)
微服务实战系列之玩转Docker(八)
微服务实战系列之玩转Docker(七)
微服务实战系列之玩转Docker(六)
微服务实战系列之玩转Docker(五)
微服务实战系列之玩转Docker(四)
微服务实战系列之玩转Docker(三)
微服务实战系列之玩转Docker(二)
微服务实战系列之玩转Docker(一)
微服务实战系列之云原生