Docker Swarm 是 Docker 引擎原生内置的集群管理与编排功能。启用 Swarm 模式后，多台 Docker 主机会被组织成一个统一的计算资源池，开发者和运维人员不再需要逐台登录服务器去启动容器，而是通过管理节点向整个集群下发服务定义。Swarm 的控制平面负责维护期望状态，调度器根据资源与约束条件选择节点运行任务，并且持续监控实际状态与期望状态之间的差异，一旦出现节点宕机或容器退出，系统会尝试自动修复。
理解 Swarm 集群管理模式的关键在于区分节点角色、服务、任务和副本这几个层次。节点分为 Manager 与 Worker 两类，Manager 节点负责保存集群状态、处理 API 请求、执行调度决策以及维护成员关系，Worker 节点只负责接收任务并运行容器。服务是用户对应用运行方式的声明，例如镜像、端口、网络、副本数量和更新策略；任务则是服务在某个节点上的一个具体运行实例，每个副本对应一个任务。这种声明式模型显著降低了容器编排的复杂度。
节点角色与 Raft 共识机制
Swarm 集群中的 Manager 节点并不是简单的中央控制器，它本身也采用分布式架构。多个 Manager 节点通过 Raft 共识算法复制集群状态，确保任意一个 Manager 节点故障都不会导致整个集群不可用。Raft 会从所有 Manager 节点中选举出一个 Leader，所有写操作都由 Leader 处理，然后同步给其他 Manager 节点。只有当大多数节点确认写入后，状态变更才会被提交。因此 Swarm 建议保持奇数个 Manager 节点，例如 1 个、3 个或 5 个，这样即使出现部分节点失联，集群仍然能够保持仲裁。
Worker 节点不参与 Raft 选举，也不保存集群状态，它们只接收 Manager 分配的任务。这种职责分离让 Worker 节点可以水平扩展，而不会增加共识算法的压力。生产环境中可以把 Manager 节点同时当作 Worker 使用，但在较大规模集群中，建议让 Manager 节点专注于管理职责，避免高负载容器任务影响控制平面的稳定性。节点角色可以通过 docker node update --role manager 或 docker node promote 进行调整。
Raft 日志持久化在 Manager 节点的 /var/lib/docker/swarm 目录中，因此该目录需要可靠存储。如果 Manager 节点数据丢失，可能造成集群状态不完整。与外部 etcd 或数据库方案不同，Swarm 的 Raft 实现内嵌在 Docker 引擎中，部署和维护成本相对较低，但在极端情况下恢复流程需要按照官方文档操作，不能随意删除该目录。
服务与任务的声明式模型
在 Swarm 模式下，容器不再通过 docker run 单独启动，而是通过 docker service create 创建服务。服务定义包含镜像、环境变量、端口映射、更新策略、限制条件等信息。例如创建一个包含 3 个副本的 Nginx 服务可以这样执行：
docker service create \ --name web \ --replicas 3 \ --publish published=8080,target=80 \ nginx:latest
Manager 节点接收到创建请求后，会将服务定义写入集群状态，调度器根据副本数量生成 3 个任务，然后挑选合适的 Worker 节点运行。每个任务对应一个容器，如果某个任务失败，Swarm 会重新创建新的任务来替换它。用户通过 docker service ls 查看服务数量，通过 docker service ps web 查看每个副本运行在哪些节点以及当前状态。
声明式模型的优势在于用户只需要关心最终状态，而不必手动维护每个容器的运行位置。例如当流量增加需要扩容时，执行 docker service scale web=6 即可，Swarm 会自动分配新任务。升级应用时使用 docker service update --image nginx:1.25 web 可以触发滚动更新，按批次替换旧版本容器。这种模式与 Kubernetes 的 Deployment、ReplicaSet 思路类似，但 Swarm 的命令行和 API 更加贴近 Docker 原有使用习惯。
调度策略与故障自愈机制
Swarm 调度器会在创建任务或重新调度任务时，从所有满足约束条件的节点中选择一个运行节点。默认调度策略是贪心策略，尽量将任务均匀分布到不同节点，同时考虑节点资源可用量。用户可以在服务创建时通过 --constraint 参数限制节点，例如 --constraint node.labels.region==east 只允许任务运行在带有指定标签的节点上。还可以通过 --placement-pref 按节点标签分散副本，提高可用性。
故障自愈是 Swarm 管理模式的重要能力。当运行任务的容器退出、节点失联或健康检查失败时，Manager 会检测到实际状态与期望状态不一致，然后触发重新调度。对于节点故障，Manager 会将该节点标记为 Down，并在其他可用节点上重新创建任务。如果节点只是暂时网络分区，Raft 和任务状态机制会避免重复调度。健康检查可以基于命令或 HTTP 接口定义，例如在服务中配置 --health-cmd 和 --health-interval，只有健康状态通过后任务才被视为正常运行。
滚动更新也与调度机制紧密结合。更新服务时，Swarm 会按照用户指定的并行度和延迟创建新版本任务，并逐步移除旧版本任务。如果新版本任务启动失败或健康检查不通过，可以执行 docker service rollback web 回滚到上一个版本。这种自动化降低了人工干预频率，但需要合理设置更新参数，避免一次性替换过多副本导致服务不可用。
网络、负载均衡与服务发现
Swarm 模式内置了覆盖网络和 DNS 服务发现能力。创建服务时可以指定一个自定义 Overlay 网络，使所有节点上的容器能够通过服务名称直接互相访问，无需关心容器具体运行在哪个节点。例如后端服务监听 3306 端口，前端服务只需要连接 db 这个服务名，Swarm 的 DNS 解析会把请求定向到对应的任务容器。
负载均衡由 Swarm 的 Ingress 网络实现。当服务通过 --publish 暴露端口时，集群中所有节点都会监听该端口，即使某个节点上没有运行该服务的副本，也会把请求转发到真正运行任务的节点。这种机制称为路由网格，它让外部流量可以访问任意节点，而不需要额外的外部负载均衡器。此外 Swarm 还支持 VIP 模式对服务内部流量进行负载均衡，默认按轮询方式分发到各个副本。
对于需要固定源 IP 或特殊协议的应用，可以使用 --endpoint-mode dnsrr 关闭 VIP 负载均衡，改用 DNS 轮询模式。网络配置也支持加密，通过 --opt encrypted 开启 Overlay 网络的数据面加密。生产环境中建议为管理流量和业务流量规划独立网络，避免 Raft 通信与应用流量互相影响。
高可用与安全配置实践
为了保证 Swarm 集群管理平面的高可用，至少需要部署 3 个 Manager 节点，并将它们分布在不同的物理机或可用区中。可以使用以下命令初始化第一个 Manager 节点并获取加入令牌：
docker swarm init --advertise-addr 192.168.1.10 docker swarm join-token manager docker swarm join-token worker
其他 Manager 节点使用 manager token 加入，Worker 节点使用 worker token 加入。加入集群后，通过 docker node ls 可以查看节点状态和可用性。建议为 Manager 节点配置静态 IP 地址，避免 IP 变化导致集群成员关系异常。对于跨数据中心部署，需要评估网络延迟对 Raft 日志复制的影响，通常更适合使用多集群或联邦方案。
安全方面，Swarm 自动使用 TLS 加密节点间通信，包括 API 通信和 Raft 日志复制。集群还支持基于角色的访问控制，但需要配合外部认证系统。敏感配置如数据库密码、API 密钥可以通过 docker secret 创建并挂载到服务容器中，避免明文写入环境变量或配置文件。创建 Secret 的命令如下：
echo "mySecretPassword" | docker secret create db_password - docker service create \ --name db \ --secret db_password \ mysql:8.0
Secret 数据只保存在 Manager 节点的 Raft 日志中，任务容器通过内存文件系统读取，不会明文出现在 docker inspect 输出中。日常运维还应限制 Manager API 端口的暴露范围，并使用防火墙规则只允许可信网络访问 2377 端口和 2376 端口，从而降低集群被恶意控制的风险。
Docker Swarm集群管理服务编排修改时间：2026-08-27 15:19:12