管理和维护一组 Docker 引擎

当您运行一组 Docker Engine 时，管理器节点是关键组件用于管理 Swarm 和存储 Swarm 状态。重要的是了解 Manager 节点的一些关键功能，以便正确部署和维护 Swarm。

请参阅节点的工作原理，简要概述 Docker Swarm 模式以及 manager 和 manager 之间的区别 worker 节点。

在 swarm 中作管理器节点

Swarm Manager 节点使用 Raft 共识算法来管理 swarm 状态。你只需要了解 Raft 的一些一般概念命令来管理 Swarm。

管理器节点的数量没有限制。决定多少要实现的 Manager 节点是性能和容错。将管理器节点添加到群中会使群更加容错。但是，额外的管理器节点会降低写入性能因为更多的节点必须确认更新 Swarm 状态的提议。这意味着更多的网络往返流量。

Raft 需要大多数 manager（也称为 quorum）来达成一致对 Swarm 的建议更新，例如添加或删除节点。会员作受与 State Replication 相同的约束。

维护经理的仲裁

如果 swarm 失去了 manager 的仲裁，则 swarm 无法执行管理任务。如果您的 Swarm 有多个 Manager，请始终具有两个以上。要保持仲裁，大多数经理必须可用。奇数个建议使用 managers，因为下一个偶数不会构成仲裁更容易保持。例如，无论您有 3 位还是 4 位经理，您仍然可以只失去 1 名经理并保持仲裁。如果您有 5 或 6 位经理，则还是只能输两场。

即使 swarm 失去了 manager 的 quorum，swarm 也会对现有 worker 执行任务节点继续运行。但是，无法添加、更新或已删除，并且无法启动、停止、移动新任务或现有任务，或者更新。

请参阅从丢失仲裁中恢复如果您确实失去了 Manager 的仲裁，则进行故障排除的步骤。

将 Manager 配置为在静态 IP 地址上通告

启动群时，您必须指定--advertise-addrflag 设置为将您的地址公布给 Swarm 中的其他 Manager 节点。了解更多信息，请参阅以 swarm 模式运行 Docker Engine。因为 Manager 节点是为了成为基础设施的稳定组件，您应该使用固定的 IP 地址（IP address）用于通告地址，以防止召集成为计算机重启时不稳定。

如果整个 swarm 重新启动，并且每个 Manager 节点随后都会获得新的 IP address，则任何节点都无法联系现有 Manager。因此当节点尝试通过其旧 IP 地址相互联系时，Swarm 会挂起。

动态 IP 地址可用于 Worker 节点。

添加管理器节点以实现容错

您应该在 swarm 中保持奇数个 manager 以支持 manager 节点故障。具有奇数个 Manager 可确保在 network 分区，则仲裁仍可用于处理的可能性更高如果网络被划分为两组，则请求。保持 quorum 不是如果您遇到两个以上的网络分区，则保证。

群大小	大多数	容错
1	1	0
2	2	0
3	2	1
4	3	1
5	3	2
6	4	2
7	4	3
8	5	3
9	5	4

例如，在具有 5 个节点的 swarm 中，如果丢失了 3 个节点，则没有法定人数。因此，在恢复其中一个不可用的 Manager 节点或通过灾难恢复恢复 Swarm 命令。请参阅从灾难中恢复。

虽然可以将 swarm 缩减到单个管理器节点，但确实如此无法降级最后一个 Manager 节点。这可确保您保持对 swarm 和 swarm 仍然可以处理请求。缩小到单个管理器是不安全的作，不建议使用。如果最后一个节点在降级作期间意外离开集群，则 swarm 将变得不可用，直到您重启节点或使用--force-new-cluster.

您可以使用docker swarm和docker node子系统。有关更多信息，请参阅将节点添加到群介绍如何添加 Worker 节点并将 Worker 节点提升为管理器。

分发管理器节点

除了维护奇数个 Manager 节点外，还要注意放置管理器时的数据中心拓扑。为了实现最佳容错能力，将 Manager 节点，以支持整套计算机或常见维护方案。如果您遇到故障在任何这些区域中，群都应保持管理器节点的仲裁可用于处理请求和再平衡工作负载。

Swarm Manager 节点	重新分区（在 3 个可用区上）
3	1-1-1
5	2-2-1
7	3-2-2
9	3-3-3

运行仅限管理器的节点

默认情况下，管理器节点还充当 worker 节点。这意味着调度程序可以将任务分配给 Manager 节点。适用于小型和非关键集群只要您安排时间，将任务分配给经理的风险相对较低对 CPU 和内存使用资源约束的服务。

但是，由于 Manager 节点使用 Raft 共识算法来复制数据他们始终对资源匮乏敏感。您应该将 Swarm 中的管理器与可能阻止 Swarm 的进程隔离开来 Swarm Heartbeat 或 Leader Elections 等作。

为避免干扰管理器节点作，您可以排空管理器节点要使它们不能作为 Worker 节点：

$ docker node update --availability drain <NODE>

当您耗尽节点时，调度程序会将该节点上运行的任何任务重新分配给 Swarm 中的其他可用 Worker 节点。它还会阻止调度程序将任务分配给节点。

添加 worker 节点以实现负载均衡

向 swarm 添加节点以平衡 swarm 的负荷。复制的服务任务在 Swarm 中均匀分布只要 Worker 节点符合要求，就可以随着时间的推移而实现的服务。当限制服务仅在特定类型的节点上运行时，例如具有特定 CPU 数量或内存量的节点，请记住不满足这些要求的工作节点无法运行这些任务。

监控 swarm 运行状况

您可以通过查询 docker 来监控管理器节点的运行状况nodes应用程序接口以 JSON 格式通过/nodesHTTP 端点。有关更多信息，请参阅 nodes API 文档。

在命令行中，运行docker node inspect <id-node>以查询节点。例如，要以 manager 身份查询节点的可访问性：

$ docker node inspect manager1 --format "{{ .ManagerStatus.Reachability }}"
reachable

要查询作为接受任务的工作程序的节点的状态，请执行以下作：

$ docker node inspect manager1 --format "{{ .Status.State }}"
ready

从这些命令中，我们可以看到manager1都处于reachable作为经理和ready作为工人。

一unreachable运行状况表示此特定管理器节点无法访问从其他 Manager 节点。在这种情况下，您需要采取措施来恢复无法访问的经理：

重新启动守护程序，并查看 manager 是否返回为可访问。
重新启动计算机。
如果重新启动和重新启动都不起作用，则应添加另一个管理器节点或将工作程序提升为管理器节点。您还需要使用docker node demote <NODE>和docker node rm <id-node>.

或者，您也可以从 Manager 那里获得 swarm 运行状况的概览 node 替换为docker node ls:

$ docker node ls
ID                           HOSTNAME  MEMBERSHIP  STATUS  AVAILABILITY  MANAGER STATUS
1mhtdwhvsgr3c26xxbnzdc3yp    node05    Accepted    Ready   Active
516pacagkqp2xc3fk9t1dhjor    node02    Accepted    Ready   Active        Reachable
9ifojw8of78kkusuc4a6c23fx *  node01    Accepted    Ready   Active        Leader
ax11wdpwrrb6db3mfjydscgk7    node04    Accepted    Ready   Active
bb1nrq2cswhtbg4mrsqnlx1ck    node03    Accepted    Ready   Active        Reachable
di9wxgz8dtuh9d2hn089ecqkf    node06    Accepted    Ready   Active

对管理器节点进行故障排除

您绝不应通过复制raft目录中。数据目录对于节点 ID 是唯一的。一个节点只能使用一次节点 ID 加入群。节点 ID 空间应全局唯一。

要将管理器节点完全重新加入集群：

使用docker node demote <NODE>.
使用从 swarm 中删除节点docker node rm <NODE>.
使用docker swarm join.

有关将管理器节点加入群的更多信息，请参阅将节点加入群。

强制删除节点

在大多数情况下，您应该先关闭节点，然后再将其从 swarm 中删除这docker node rm命令。如果节点变得无法访问、无响应或 compromised，您可以通过以下方式强制删除节点而不将其关闭将--force旗。例如，如果node9被入侵：

$ docker node rm node9

Error response from daemon: rpc error: code = 9 desc = node node9 is not down and can't be removed

$ docker node rm --force node9

Node node9 removed from swarm

在强制删除管理器节点之前，必须先将其降级到 worker 角色。如果满足以下条件，请确保您始终具有奇数个管理器节点您将经理降级或移除。

备份 swarm

Docker 管理器节点将 swarm 状态和管理器日志存储在/var/lib/docker/swarm/目录。此数据包括用于加密的密钥 Raft 日志。如果没有这些密钥，则无法恢复 swarm。

您可以使用任何管理器备份 Swarm。使用以下过程。

如果 swarm 启用了自动锁定，则需要解锁密钥从备份中恢复 Swarm。如有必要，检索解锁密钥，然后将其存放在安全的地方。如果您不确定，请阅读 Lock your swarm 以保护其加密密钥。
在备份数据之前，在管理器上停止 Docker，以便没有数据在备份期间被更改。可以在 Manager 正在运行（“热”备份），但不建议这样做，并且您的还原时，结果更难预测。当 Manager 宕机时，其他节点继续生成不属于此备份的 Swarm 数据。
注意
请务必维护 swarm 管理器的仲裁。在当 Manager 关闭时，您的 Swarm 更容易受到如果丢失更多节点，则丢失 quorum。您 run 是一种权衡。如果您定期让 Manager 进行备份，考虑运行一个 5 Manager Swarm，这样你就可以额外失去一个 Manager 的 Manager 进行备份，而不会中断您的服务。
备份整个/var/lib/docker/swarm目录。
重新启动 Manager。

要还原，请参阅从备份还原。

从灾难中恢复

从备份还原

按照备份 swarm 中所述备份 swarm 后，使用以下过程将数据恢复到新的 Swarm。

关闭已还原的 swarm 的目标主机上的 Docker。
删除/var/lib/docker/swarm目录中的群。
恢复/var/lib/docker/swarm目录中包含备份。
注意
新节点对磁盘上使用相同的加密密钥 storage 作为旧的。无法更改磁盘上的存储加密密钥。
对于启用了自动锁定的 swarm，解锁键也是与旧 Swarm 上相同，并且需要解锁密钥来恢复群。
在新节点上启动 Docker。如有必要，解锁 swarm。重新初始化群使用以下命令，以便此节点不会尝试连接到属于旧 Swarm 的节点，并且可能没有更长的存在。
$ docker swarm init --force-new-cluster
验证 swarm 的状态是否符合预期。这可能包括特定于应用程序的测试，或者只是检查docker service ls以确保所有预期的服务都存在。
如果您使用自动锁定，请旋转解锁密钥。
添加 Manager 和 Worker 节点以使您的新 Swarm 开始运行能力。
在新 swarm 上恢复您之前的备份方案。

从丢失仲裁中恢复

Swarm 对故障具有弹性，并且可以从任何数量中恢复临时节点故障（机器重启或重启时崩溃）或其他瞬态错误。但是，如果 swarm 丢失了法定人数。现有 worker 节点上的任务将继续运行，但管理无法执行任务，包括扩展或更新服务以及加入或从 Swarm 中删除节点。找回的最好办法是带上失踪的人 Manager 节点重新联机。如果这是不可能的，请继续阅读一些用于恢复 Swarm 的选项。

在一大群Nmanagers，则 manager 节点的 quorum （大多数）必须始终可用。例如，在具有 5 个 manager 的 swarm 中，必须至少有 3 个 manager 作和通信。换句话说，swarm 可以耐受高达(N-1)/2永久故障，超出此范围的请求涉及无法处理 Swarm 管理。这些类型的失败包括数据损坏或硬件故障。

如果您失去了 manager 的仲裁，则无法管理 swarm。如果你有丢失了仲裁，并且您尝试对 Swarm 执行任何管理作，发生错误：

Error response from daemon: rpc error: code = 4 desc = context deadline exceeded

从丢失仲裁中恢复的最佳方法是恢复失败的节点在线。如果你不能这样做，那么从这种状态中恢复的唯一方法是使用这--force-new-cluster作。这将删除所有管理器但运行命令的 Manager 除外。达到 quorum 是因为现在只有一个 Manager。将节点提升为管理器，直到您拥有所需的经理数。

从要恢复的节点中，运行：

$ docker swarm init --force-new-cluster --advertise-addr node01:2377

当您运行docker swarm init命令与--force-new-cluster标志，则运行命令的 Docker Engine 将成为能够管理和运行服务的单节点 Swarm。经理具有有关服务和任务的所有先前信息，Worker 节点是仍然是 Swarm 的一部分，并且服务仍在运行。您需要添加或重新添加 Manager 节点以实现之前的任务分配，并确保您有足够的管理器来维护高可用性并防止丢失法定人数。

强制 swarm 重新平衡

通常，您不需要强制 Swarm 重新平衡其任务。当您将新节点添加到集群中，或者节点在期间，则 Swarm 不会自动将工作负载分配给空闲节点。这是一个设计决策。如果 swarm 定期转移任务到不同的节点，使用这些任务的客户端将被打乱。目标是避免为了在 Swarm 中保持平衡。当新任务启动时，或者当运行 tasks 变得不可用，这些任务将分配给不太繁忙的节点。目标是最终的平衡，对最终用户的干扰最小。

您可以使用--force或-fflag 替换为docker service update命令强制服务在可用的 worker 节点之间重新分配其任务。这会导致服务任务重新启动。客户端应用程序可能会中断。如果您已配置，则您的服务将使用滚动更新。

如果您使用早期版本，并且希望实现均匀的负载平衡在 worker 中，并且不介意中断正在运行的任务，您可以强制您的 Swarm 通过临时向上扩展服务来重新平衡。用docker service inspect --pretty <servicename>查看配置的比例的服务。当您使用docker service scale，则接收新工作负载的任务数。可能有多个集群中的节点负载不足。您可能需要将服务扩展为递增几次，以实现您想要的所有节点之间的平衡。

当负载均衡到您满意的程度时，您可以缩减服务降低到原始比例。您可以使用docker service ps评估电流跨节点的服务平衡。

另请参阅docker service scale和docker service ps.