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

Question

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

Kur*_*tis 9 docker-swarm

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

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

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

Answer 1

Bre*_*her 14

TL; DR作为Swarm中的工作者的所有经理的利弊:

优点:

产品质量高,只有3或5台服务器
设计/管理简单
默认情况下仍然安全(秘密在磁盘上加密,相互TLS身份验证和控制平面上的网络加密)
任何节点都可以管理Swarm

缺点:

需要更严格的资源管理,以防止经理人挨饿
降低安全状态,存储在应用服务器上的机密/密钥
受损节点意味着整个Swarm很容易受到攻击
仅限于奇数个服务器,通常为3或5个

您的问题的完整答案

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

使用仅限工作程序的节点没有硬性要求.如果你正在部署一个解决方案,你知道你需要什么资源,并且服务/任务的数量通常是相同的,那么只有三个经理做完所有工作的Swarm都没有错,只要你考虑过这三个受影响的地区:

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

其他问题:

在实践中,哪些功能会更慢？"需要更长时间达成共识"实际上会产生什么影响？

更多的管理人员=更长的经理人在一个人垮台时选出新的领导者.虽然没有领导者,但Swarm处于只读状态,无法启动新的副本任务,也不会发生服务更新.任何失败的容器都不会自动恢复,因为Swarm管理器无法正常工作.您正在运行应用程序,入口路由网格等等仍然可以正常运行.管理者健康和领导者选举的很大一部分性能与所有经理节点之间的网络延迟有关,与管理者的数量一样多.这就是为什么Docker通常建议单个Swarms管理器都在同一个区域,这样他们就可以在彼此之间进行低延迟的往返.这里没有硬盘规则.如果您在管理人员和测试失败之间测试200毫秒的延迟,并且对领导者选举的结果和速度很好,那就很酷.

背景资料:

归档时间：	7 年，11 月前
查看次数：	2718 次
最近记录：	7 年，10 月前