将所有Docker Swarm节点设为管理器的利弊及无专用工作节点的权衡

嘿，我来给你唠唠用3个管理节点兼作工作节点的那些权衡点和容易踩的隐形坑——都是实战里摸出来的干货：

• 性能与资源竞争是头号问题：管理节点本身要跑Raft共识集群、集群状态同步这些核心组件，这些进程对延迟和稳定性要求极高。要是再把业务容器堆上来，CPU、内存、磁盘IO很容易打架。比如集群正在做leader选举或者同步大量状态时，刚好你的业务容器在搞大数据计算，两边都会卡：业务响应变慢是小事，严重时会导致管理节点心跳超时，触发不必要的集群重新选举，甚至有极小概率引发脑裂。
• 容错能力其实打了折扣：3个管理节点的设计是允许挂1个节点还能正常运行，但如果某个节点因为业务负载过高崩了，等于同时损失了一个管理节点和一个工作节点。要是刚好大部分业务容器都跑在这个节点，恢复起来会面临双重压力：既要重新选举管理节点，又要把一堆业务容器调度到剩下的两个节点，这俩本来就有管理负载，很容易过载导致集群短时间内响应迟钝。
• 升级维护的风险翻倍：给管理节点做版本升级（比如Docker升级）时，得先把节点设为drain状态，把上面的业务容器迁走。但如果所有节点都是混合节点，迁容器只能往另外两个管理节点塞，这俩本来就扛着管理任务，再接收迁过来的容器，很容易直接过载。而且万一某个节点升级失败，剩下的节点既要扛整个集群的管理工作，又要扛所有业务，压力山大，搞不好就崩了。

• 必须给管理组件预留资源：别心疼资源！一定要给每个管理节点的swarm核心进程（比如raft、swarmkit）预留足够的CPU和内存。可以用docker swarm update --task-resource-cpu全局设置，或者部署服务时给业务容器设置--limit-cpu/--limit-memory，把管理进程的资源锁死，绝对不能让业务容器把这些资源抢了。不然哪天业务突发流量，直接把管理进程挤垮，整个集群就瘫了。
• 调度约束要精细配置：别让高负载业务随便跑在所有节点。可以给管理节点打个标签，比如docker node update --label-add role=manager <node-id>，然后部署服务时要么限制高负载服务的实例数，要么给关键业务设置调度规则，避免某个节点被业务占满。比如你可以给大数据服务设置--constraint node.role==manager但同时指定--replicas 2，不让三个节点都跑这个服务。
• 监控要兼顾业务和集群核心：别只盯着业务容器的CPU、内存，一定要重点监控管理节点的Raft日志同步延迟、swarm进程的资源使用率、节点心跳间隔。很多时候业务容器出问题只是表象，根源是管理节点因为资源不够导致状态不同步，这时候光看业务指标根本找不到问题。
• 备份策略不能偷懒：虽然3节点的Raft数据有冗余，但如果两个节点同时挂了（比如机房断电），剩下的节点没法形成quorum（多数派），集群就没法正常工作。所以一定要定期备份：一是保存docker swarm join-token manager的令牌，二是在节点健康时备份/var/lib/docker/swarm目录（这个目录是swarm的核心数据，备份后能在紧急情况下恢复集群）。
• 业务容器的重启策略要合理：如果管理节点因为资源不足重启，上面的业务容器会被调度到其他节点，但如果剩下的节点也扛不住，就会导致容器反复重启失败，反而加剧集群负载。所以给业务设置--restart策略时，别用always，可以用on-failure:5，让容器在失败几次后停止重启，等集群恢复后再手动启动。

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