解决 Docker Swarm 集群节点故障：从问题剖析到修复实战

解决 Docker Swarm 集群节点故障：从问题剖析到修复实战

在使用 Docker Swarm 构建容器编排集群时，可能会遭遇各种难题。本文将分享一次处理 Docker Swarm 集群节点故障的实战经历，涵盖问题出现的缘由、详细剖析以及完整的解决步骤，助力大家应对类似困境。

一、故障背景

我所管理的 Docker Swarm 集群由三个节点构成，分别是 ts3、ts4 以及 harbor 节点。起初，ts3 担任主管理节点（Leader），肩负着统筹集群的重任；ts4作为可到达的管理节点（Reachable），辅助 ts3 维持集群的稳定运行；harbor 节点则作为工作节点，默默承担着各类容器任务的执行工作。整个集群各司其职，有序运转。

二、问题爆发

然而，平静的表象下暗流涌动。一次在 ts3 节点的操作，如同投入湖面的巨石，激起千层浪。

当我在 ts3 节点输入 docker swarm leave 指令，满心期望进行节点调整时，系统却给出严厉警告：

Error response from daemon: You are attempting to leave the swarm on a node that is participating as a manager. Removing this node leaves 1 managers out of 2. Without a Raft quorum your swarm will be inaccessible. The only way to restore a swarm that has lost consensus is to reinitialize it with '--force-new-cluster'. Use '--force' to suppress this message.

这一报错背后，隐藏着 Docker Swarm 集群的核心运行机制 ——Raft 一致性算法。该算法为保障集群的可靠性与数据一致性，要求集群中多数（即超过一半）的管理节点时刻保持在线状态。在当前集群架构下，共有两个管理节点，若 ts3 贸然离开，剩余管理节点数量将低于半数，Raft quorum 被打破，集群必将陷入混乱，无法正常提供服务。

但我当时并未充分领悟这一警告的深意，错误地选择强行执行 docker swarm leave --force 命令。瞬间， ts3 节点强硬地脱离了集群。紧接着，当我在 ts4 节点尝试执行 docker node ls ，期望查看节点状态以评估局势时，新的报错又接踵而至：

Error response from daemon: rpc error: code = Unknown desc = The swarm does not have a leader. It's possible that too few managers are online. Make sure more than half of the managers are online.

此刻，问题已然清晰明了。由于ts3的强制离开，集群内管理节点数量锐减，无法满足 Raft 算法的苛刻要求。ts4作为硕果仅存的管理节点，在失去同伴的支撑后，无法独自确定集群领导权，致使整个集群的管理层面陷入瘫痪，连最基本的节点管理操作都无法开展。

三、修复之旅

（一）重新初始化集群核心：ts4 节点的担当

面对如此严峻的局面，我迅速冷静下来，着手在 ts4 节点展开修复行动。首要任务便是执行 docker swarm init --force-new-cluster 命令，此命令的重要性不言而喻，它能够强制 ts4 节点摒弃原有混乱的集群关联，重新建立一个全新的、以它为唯一管理节点的集群，为后续的修复工作搭建起稳定的基石。

执行该命令后，系统反馈关键信息：

Swarm initialized: current node (eitl9c0yyuizhy84lzrdlr56v) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-4988kvb923xv8xpymmkqbgket37b4wg2mueujcetis0f2mq1ly-9vm9dwxq8jl59gap5aszkeohq 172.16.10.111:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

这表明 ts4 节点已然成功 “登基”，成为新集群的核心领导者，集群初步恢复了单点管理能力，为后续召回其他节点奠定了基础。

（二）召回 “叛将”：ts3 节点重新入网

仅有 ts4 孤掌难鸣，为重塑集群原有的高可用性，将 ts3 节点重新纳入麾下势在必行。

1. 首先，在 ts4 节点执行 docker swarm join-token manager 命令，获取添加管理节点所需的令牌和连接信息，得到类似如下格式的命令：

   docker swarm join --token SWMTKN-1-4988kvb923xv8xpymmkqbgket37b4wg2mueujcetis0f2mq1ly-e369ql9o0mom51vw80bi8j6w2 172.16.10.111:2377
   

   此信息如同连接 ts3 与集群的桥梁，至关重要。

2. 接着，在 ts3 节点执行上述获取到的命令，成功将 ts3 以管理节点身份重新融入集群。不过，此时一个小插曲悄然出现，当在 ts4 节点执行 docker node ls 查看节点状态时，发现ts3出现了两个条目，一个状态为 Down ，一个为 Ready 且 MANAGER STATUS为Reachable 。这是由于 ts3 旧的节点信息尚未完全清除，新加入的信息又已生成，两者并存导致了这一混乱局面。

（三）清理冗余：重塑节点信息

为恢复节点信息的清爽与准确，果断在ts4节点（作为当前集群的有效管理者）执行以下操作：

1. 通过 docker node ls 命令仔细查找 ts3 旧节点的 ID，假设为 oenfkuqg01ezrqb22866o7v2a。
2. 执行 docker node rm oenfkuqg01ezrqb22866o7v2a 命令，清理掉ts3的旧节点记录。

再次执行 docker node ls ，此时集群节点状态终于回归正轨：

ID                            HOSTNAME   STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
p0iv5a6339hiybx7pplzs1t32     harbor     Ready     Active                          24.0.7
ql0ttka2k8noden0hs1ilagy9     ts3        Ready     Active         Reachable        26.1.4
eitl9c0yyuizhy84lzrdlr56v *   ts4        Ready     Active         Leader           26.1.4

至此，历经波折，Docker Swarm 集群成功恢复如初，重新稳定高效地运行起来，各项容器编排任务得以顺畅执行。

总结此次经历，在 Docker Swarm 集群管理过程中，管理节点的操作务必慎之又慎。务必深入理解 Raft 一致性算法背后对节点数量的严格要求，一旦遭遇类似问题，严格按照上述步骤冷静排查、精准修复，便能从容化解危机，确保集群持续高效运行。