7、Swarm集群中的服务发现：原理、实践与应用

Swarm集群中的服务发现：原理、实践与应用

1. 服务发现的必要性

在Swarm集群中，如果总是使用同一个管理器，会存在单点故障的问题。例如，若整个节点1发生故障，可能就没有可用的管理器，或者只能被迫使用节点2上的管理器。此外，还有许多其他因素可能导致差异，比如某个容器意外停止。当决定将服务扩展到三个实例时，节点1上的管理器可能认为已有两个实例在运行，从而创建一个任务来运行另一个实例，但实际上集群中最终运行的实例可能只有两个。

为了避免这些问题，每个管理器都需要拥有与其他管理器相同的信息，每个节点都需要监控Docker引擎生成的事件，并确保对其服务器的任何更改都能传播到所有管理器。也就是说，每个管理器都需要对整个集群有最新的了解，这样才能将我们对期望状态的请求转化为任务，并分配给Swarm节点。

为了实现这一点，我们需要一个分布式服务注册表和一个监控系统。可以使用服务注册表或键值存储来满足分布式服务注册表的需求，旧版Swarm（Docker 1.12之前的独立版本）支持Consul、etcd和Zookeeper，其中Consul是一个不错的选择。

2. 独立Docker Swarm与服务发现的工作流程

当我们了解了服务发现的需求和原因后，可以定义向Docker Swarm管理器发出请求的实际流程：
1. 用户向其中一个Swarm管理器发送具有期望状态的请求。
2. Swarm管理器从服务注册表中获取集群信息，创建一组任务，并将它们分配给Swarm工作节点。
3. Swarm工作节点将任务转换为命令，并将其发送到本地Docker引擎，由Docker引擎运行或停止容器。
4. Swarm工作节点持续