为何在Docker Swarm集群中选用Worker节点角色？附Manager故障场景分析

为什么要给Docker Swarm节点分配Worker角色？ #

核心逻辑其实是职责分离，把集群的管理工作和业务负载运行工作拆解开，带来的好处主要有这几点：

• 提升集群安全性：Manager节点握着集群配置、密钥、节点管控等核心权限，如果让它同时跑业务容器，相当于把高权限节点暴露给了业务负载，一旦业务容器出安全问题，很容易波及整个集群的控制层。Worker节点只负责接收Manager的调度指令运行容器，权限更低，风险更小。
• 优化性能与稳定性：Manager需要处理集群心跳同步、服务调度、Leader选举等管理任务，要是再承担业务容器的运行压力，很容易因为资源不足导致管理响应变慢，甚至影响集群稳定性。Worker节点专注于运行业务负载，能让Manager把资源集中在管理工作上，整个集群的运行效率更高。
• 灵活扩展集群：Worker节点的扩展非常自由，你可以根据业务负载的需求随时添加或移除Worker，不用考虑集群管理层面的quorum（法定人数）限制。而Manager节点的数量是需要严格规划的，不能随便乱加。

关于Swarm集群提示The swarm does not have a leader的原因 #

这个问题本质是Docker Swarm使用的Raft一致性协议在起作用。Raft协议要求集群必须有超过半数的Manager节点在线，才能选举出Leader并维持集群的正常管理状态——这就是所谓的quorum机制。

拿你提到的4个Manager节点的场景来说：

• 总共有4个Manager，半数是2个，所以必须要有3个及以上的Manager在线，才能满足“超过半数”的要求。
• 当Leader故障后，剩下3个Manager能选举出新Leader；但如果新Leader也故障，只剩2个Manager在线，此时在线数量刚好等于半数，没有超过，Raft协议就无法达成共识，没法选举出有效的Leader，集群也就失去了管理核心，所以会返回那个错误提示。

简单说，要避免这种情况，规划Manager节点数量的时候最好选奇数（比如3、5个），这样在部分节点故障时更容易维持quorum。比如5个Manager的话，只要有3个在线就能正常运行，容错性比4个更强。

内容的提问来源于stack exchange，提问作者Cravid