将所有 Docker Swarm 节点作为 Manager 运行的优缺点？

Question

我正在考虑构建一个 Docker Swarm 集群。为了保持简单和相对容错的目的，我考虑过简单地运行 3 个节点作为管理器。

不使用任何专用工作节点时的权衡是什么？有什么我应该注意的可能不明显的吗？

我发现这个Github issue 提出了类似的问题，但答案对我来说有点模棱两可。它提到性能可能会更差。它还提到，达成共识需要更长的时间。在实践中，哪些功能会更慢？ “需要更长时间才能达成共识”实际上会影响什么？

Answer 1

TL；作为 Swarm 工作人员的所有经理的 DR 利弊：

优点：

• 只有 3 或 5 台服务器的产品级 HA
• 设计/管理简单
• 默认情况下仍然安全（秘密在磁盘上加密，双向 TLS 身份验证和网络加密在控制平面上）
• 任何节点都可以管理 Swarm

缺点：

• 需要对资源进行更严格的管理，以防止经理挨饿
• 较低的安全状态、存储在应用服务器上的机密/密钥
• 受损节点意味着整个 Swarm 很容易被攻破
• 服务器数量限制为奇数，通常为 3 或 5 个

您的问题的完整答案

不使用任何专用工作节点时的权衡是什么？有什么我应该注意的可能不明显的吗？

使用仅工作节点没有硬性要求。如果您正在部署一个解决方案，您知道自己需要什么资源，并且服务/任务的数量通常相同，那么只要您考虑了这三个管理器，只需三个管理器的 Swarm 就可以完成所有工作。受影响的地区：

1. 安全。在一个完美的世界中，您的经理将无法访问互联网，并且只会在后端子网上，只做经理的工作。管理者拥有 Swarm 的所有权限，持有所有加密的秘密，存储加密的 Raft 日志，并且（默认情况下）将加密密钥存储在磁盘上。工人只存储他们需要的秘密，（并且只在内存中）并且无权在 Swarm 中做任何工作，除了领导告诉他们要做的事情。如果一个工人受到损害，你不一定会“失去 Swarm”。这种分权并不是硬性要求，很多环境都接受了这种风险，只是把管理器作为主要的服务器，向公众发布服务。这只是安全性/复杂性与成本的问题。
2. 节点数。冗余管理器的最小数量是 3，而我大多数时候建议使用 3 或 5 个。更多的经理并不等于更多的能力，因为任何时候只有一位经理是领导者，并且唯一一位做经理工作的人。领导者的资源能力决定了它可以同时完成多少工作。如果您的经理也在做应用程序工作，并且您需要更多的资源容量，那么 3 个节点可以处理，那么我建议第 4 个节点和更高的节点只是工作人员。
3. 性能/规模。理想情况下，您的经理拥有快速完成任务所需的所有资源，例如领导者选举、任务调度、运行和响应健康检查等。他们的资源利用率将随着总节点数、总服务数和新节点率的增加而增长他们必须执行的工作（服务/网络创建、任务更改、节点更改、健康检查等）。如果您有少量服务器和少量服务/副本，那么只要您小心（对服务使用资源限制）以防止您的应用程序（尤其是数据库）挨饿，那么您可能会让管理人员也成为工作人员资源的 docker 守护进程太糟糕了，以至于 Swarm 无法完成它的工作。当您开始随机更换领导者或出现错误/故障时，您可能希望在您的故障排除步骤简短列表中“检查经理是否有可用资源”。

其他问题：

在实践中，哪些功能会更慢？ “需要更长时间才能达成共识”实际上会影响什么？

更多经理 = 经理倒台时选举新领导的时间更长。在没有领导者的情况下，Swarm 处于只读状态，无法启动新的副本任务，也不会发生服务更新。任何失败的容器都不会自动恢复，因为 Swarm 管理器无法工作。您正在运行的应用程序、入口路由网格等仍然正常运行。管理器健康和领导者选举的很大一部分性能与所有管理器节点之间的网络延迟有关，与管理器的数量一样多。这就是为什么 Docker 通常建议单个 Swarms 管理器都在同一个区域中，这样它们就可以在彼此之间进行低延迟的往返。这里没有硬性规则。如果您测试管理器之间的 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

Answer 2

这完全取决于构建集群的目的。出于开发目的，您可以将工作节点用作管理器。真正关心的是横向扩展，如果您认为您的微服务基础设施将继续增长，那么请考虑将工作节点和管理器节点分开以便轻松横向扩展。

您的设置的优点是：

• 易于管理

• 设置高度可用 - 3 个节点意味着 1 个故障容限

缺点是：

• 不利于横向扩展，容器计算需求意味着添加更多工作节点。

• 额外的管理器节点会降低写入性能，因为更多的节点必须确认更新 swarm 状态的提议。这意味着更多的网络往返流量会导致您的服务出现性能问题 如果您的 dockerized 应用程序与主机系统发生冲突，这将影响管理器服务。 Swarm 任务将继续运行，但无法添加、更新或删除 swarm 节点，并且无法启动、停止、移动或更新新的或现有的任务。隔离经理和员工服务更安全。