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

Question

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

不使用任何专用工作节点时有哪些权衡取舍？有什么我应该知道的可能不明显吗？

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

Answer 1

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

优点：

• 只有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

缺点是：

• 不适合扩展，容器计算需求意味着添加更多工作节点。

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