我正在考虑构建一个 Docker Swarm 集群。为了让事情既简单又相对容错，我想简单地运行 3 个节点作为管理器。
不使用任何专用工作节点时有什么权衡？有什么我应该注意的可能不明显的吗？
我找到了这个 Github issue这问了一个类似的问题，但答案对我来说有点模棱两可。它提到性能可能会更糟。它还提到达成共识需要更长的时间。在实践中，哪些功能会更慢？ “需要更长的时间才能达成共识”实际上会影响什么？
TL;DR 作为 Swarm worker 的所有管理者的利弊:
优点:
只有 3 或 5 台服务器的产品质量 HA 设计/管理的简单性 默认情况下仍然安全( secret 在磁盘上加密，双向 TLS 身份验证和控制平面上的网络加密)任何节点都可以管理 Swarm 缺点:
需要更严格的资源管理以防止经理饥饿 较低的安全状态，存储在应用服务器上的 secret / key 被入侵的节点意味着整个 Swarm 很容易被入侵 仅限于奇数服务器，通常为 3 或 5 完整解答您的问题
What are the trade-offs when not using any dedicated worker nodes? Is there anything I should be aware of that might not be obvious?
使用仅工作节点没有硬性要求。如果你正在部署一个解决方案，你知道你需要什么资源，并且服务/任务的数量通常是相同的，那么只要你考虑过这三个，一个只有三个经理做所有工作的 Swarm 没有错受影响的地区:
安全 .在一个完美的世界中，您的经理将无法访问互联网，只能在后端子网上，只做经理的工作。管理者拥有 Swarm 的所有权限，持有所有加密的 secret ，存储加密的 Raft 日志，并且(默认情况下)将加密 key 存储在磁盘上。 worker 只存储他们需要的 secret (并且只在内存中)并且没有权限在 Swarm 中做任何工作，除非领导者告诉他们要做的事情。如果 worker 受到威胁，您不一定“失去了 Swarm”。这种分权不是硬性要求，许多环境接受这种风险，只是将管理器作为向公众发布服务的主要服务器。这只是一个安全/复杂性与成本的问题。 节点数 .冗余管理人员的最小数量是 3，而 3 或 5 是我大多数时候推荐的。更多的经理不等于更多的能力，因为在任何时候只有一位经理是领导者，并且只有一位经理做经理的工作。领导者的资源能力决定了它可以同时完成多少工作。如果您的经理也在做应用程序工作，并且您需要更多的资源容量然后 3 个节点可以处理，那么我建议第 4 个节点和更高的节点只是 worker 。 性能/规模 .理想情况下，您的经理拥有快速完成任务所需的所有资源，例如领导者选举、任务调度、运行和对健康检查使用react等。他们的资源利用率将随着总节点数、总服务数和新更新率的增加而增长他们必须执行的工作(服务/网络创建、任务更改、节点更改、健康检查等)。如果您有少量服务器和少量服务/副本，那么只要您小心(对服务使用资源限制)以防止您的应用程序(尤其是数据库)饿死，您就可能让经理也是 worker 资源的 docker 守护进程非常糟糕，以至于 Swarm 无法完成它的工作。当您开始随机更换领导者或出现错误/失败时，您可能希望在故障排除步骤的简短列表中“检查经理的可用资源”。 其他问题:
In practice, what functionality would be slower? And what does "take longer to reach consensus" actually affect?
更多的管理人员 = 管理人员倒台时选举新领导的时间更长。虽然没有领导者，但 Swarm 处于只读状态，无法启动新的副本任务，也不会发生服务更新。任何失败的容器都不会自动恢复，因为 Swarm 管理器无法工作。您正在运行应用程序、入口路由网格等，所有这些都仍然有效。管理器健康和领导者选举的很大一部分性能与所有管理器节点之间的网络延迟有关，与管理器的数量一样多。这就是为什么 Docker 通常建议单个 Swarm 管理器都在同一个区域中，这样他们之间的往返行程就会低延迟。这里没有硬性规则。如果您测试管理器和测试失败之间的 200 毫秒延迟并且对领导者选举的结果和速度感到满意，那很酷。
背景资料:
Swarm Admin Guide Laura Frank's DockerCon talk on Swarm/Raft internals and recovery My DockerCon talk on Swarm production considerations/design Nico Kabar DockerCon talk on Enterprise Swarm considerations (如果你要大)Running Docker EE at scale